PiersJH
Well-Known Member
Straight to the point: Since Zen 3 (and to a lesser extend, Zen 2) is known for basing performance on hundreds of internal sensor readings and AMD isn't entirely open about the exact workings, this can easily cause a 15°C increase within one polling cycle (default 2000ms in HWiNFO). Ryzen Master appears to average the temperature reported so these sub-one second spikes are ignored to give a more representative picture, albeit with a slight delay.
I realise the impracticalities of Integrating AMD's SDK and that makes sense, but a possible alternative is to have a separate option where HWiNFO only reports a high value if it's present for more than X polling cycles.
Example 1 (current behaviour): A user boots into Windows, opens HWiNFO, and opens a directory. This causes a very brief spike in voltage to 1.49V, which increases the temperature by 15°C for one or two polling cycles. This 15°C is reported as the maximum temperature within HWiNFO.
Example 2 (proposal): A user boots into Windows, opens HWiNFO, and opens a directory. This causes the same spike in voltage as above, leading to a brief increase in temperature as above, except this time the 15°C increase is only reported in HWiNFO if it's sustained for X cycles (let's say a reasonable value would be 3 polling cycles or 6,000ms - whichever is lower). In this example, since the bursty workload caused a very brief temperature increase, it would not be reported as the maximum, which would provide a more representative overview and similar reporting to Ryzen Master. I'm not suggesting this as a replacement, but merely an option.
PS: Sorry about the title - couldn't think of a better way of putting it.
I realise the impracticalities of Integrating AMD's SDK and that makes sense, but a possible alternative is to have a separate option where HWiNFO only reports a high value if it's present for more than X polling cycles.
Example 1 (current behaviour): A user boots into Windows, opens HWiNFO, and opens a directory. This causes a very brief spike in voltage to 1.49V, which increases the temperature by 15°C for one or two polling cycles. This 15°C is reported as the maximum temperature within HWiNFO.
Example 2 (proposal): A user boots into Windows, opens HWiNFO, and opens a directory. This causes the same spike in voltage as above, leading to a brief increase in temperature as above, except this time the 15°C increase is only reported in HWiNFO if it's sustained for X cycles (let's say a reasonable value would be 3 polling cycles or 6,000ms - whichever is lower). In this example, since the bursty workload caused a very brief temperature increase, it would not be reported as the maximum, which would provide a more representative overview and similar reporting to Ryzen Master. I'm not suggesting this as a replacement, but merely an option.
- I believe this is a straight forward way to provide readings closer to Ryzen Master, but without the hassle of integrating AMD's kernel driver and DLLs.
- The downsides would be a 4 polling cycle delay in reporting the maximum temperature for CPU CCD1 (Tdie) and CPU CCD2 (Tdie), and HWiNFO saving 4 polling cycles worth of data (if the 4th polling cycle shows the same temperature increase, that is the value that's reported as after 6,000ms, that should be classed as sustained) to check against the preceding 3 polling cycle values. There would be no need to add this feature to Tctl/Tdie or the die average.
- Ideally, this would be an optional tickbox in the Sensors Setting menu and called something like 'Maximum Temperature Averaging'. What do you think?
PS: Sorry about the title - couldn't think of a better way of putting it.
