A Timely Discovery: Examining Our AMD 2nd Gen Ryzen Results
by Ian Cutress & Ryan Smith on April 25, 2018 11:15 AM EST
Last week, we published our AMD 2nd Gen Ryzen Deep Dive, covering our testing and analysis of the latest generation of processors to come out from AMD. Highlights of the new products included better cache latencies, faster memory support, an increase in IPC, an overall performance gain over the first generation products, new power management methods for turbo frequencies, and very competitive pricing.
In our review, we had a change in some of the testing. The big differences in our testing for this review was two-fold: the jump from Windows 10 Pro RS2 to Windows 10 Pro RS3, and the inclusion of the Spectre and Meltdown patches to mitigate the potential security issues. These patches are still being rolled out by motherboard manufacturers, with the latest platforms being first in that queue. For our review, we tested the new processors with the latest OS updates and microcode updates, as well as re-testing the Intel Coffee Lake processors as well. Due to time restrictions, the older Ryzen 1000-series results were used.
Due to the tight deadline of our testing and results, we pushed both our CPU and gaming tests live without as much formal analysis as we typically like to do. All the parts were competitive, however it quickly became clear that some of our results were not aligned with those from other media. Initially we were under the impression that this was as a result of the Spectre and Meltdown (or Smeltdown) updates, as we were one of the few media outlets to go back and perform retesting under the new standard.
Nonetheless, we decided to take an extensive internal audit of our testing to ensure that our results were accurate and completely reproducible. Or, failing that, understanding why our results differed. No stone was left un-turned: hardware, software, firmware, tweaks, and code. As a result of that process we believe we have found the reason for our testing being so different from the results of others, and interestingly it opened a sizable can of worms we were not expecting.
An extract from our Power testing script
What our testing identified is that the source of the issue is actually down to timers. Windows uses timers for many things, such as synchronization or ensuring linearity, and there are sets of software relating to monitoring and overclocking that require the timer with the most granularity - specifically they often require the High Precision Event Timer (HPET). HPET is very important, especially when it comes to determining if 'one second' of PC time is the equivalent to 'one second' of real-world time - the way that Windows 8 and Windows 10 implements their timing strategy, compared to Windows 7, means that in rare circumstances the system time can be liable to clock shift over time. This is often highly dependent on how the motherboard manufacturer implements certain settings. HPET is a motherboard-level timer that, as the name implies, offers a very high level of timer precision beyond what other PC timers can provide, and can mitigate this issue. This timer has been shipping in PCs for over a decade, and under normal circumstances it should not be anything but a boon to Windows.
However, it sadly appears that reality diverges from theory – sometimes extensively so – and that our CPU benchmarks for the Ryzen 2000-series review were caught in the middle. Instead of being a benefit to testing, what our investigation found is that when HPET is forced as the sole system timer, it can sometimes a hindrance to system performance, particularly gaming performance. Worse, because HPET is implemented differently on different platforms, the actual impact of enabling it isn't even consistent across vendors. Meaning that the effects of using HPET can vary from system to system, as well as the implementation.
And that brings us to the state HPET, our Ryzen 2000-series review, and CPU benchmarking in general. As we'll cover in the next few pages, HPET plays a very necessary and often very beneficial role in system timer accuracy; a role important enough that it's not desirable to completely disable HPET – and indeed in many systems this isn't even possible – all the while certain classes of software such as overclocking & monitoring software may even require it. However for a few different reasons it can also be a drain on system performance, and as a result HPET shouldn't always be used. So let's dive into the subject of hardware timers, precision, Smeltdown, and how it all came together to make a perfect storm of volatility for our Ryzen 2000-series review.
Facebook
Twitter
RSS
242 Comments
View All Comments
Lord of the Bored - Thursday, April 26, 2018 - link
Not just nVidia. AMD's graphics division has been known to do it too, going back to when it was still an independent company. See: QUAFF3.EXEMaxiking - Saturday, April 28, 2018 - link
Yeah like AMD was using less demanding tessellation to boost their score in benchmarks or less demanding AF ignoring completely what an application set. . Oh yeah, I forgot, when the same thing happened to AMD, it was a bug, when to Nvidia, cheating. Those double standards are hilarious.Fallen Kell - Wednesday, April 25, 2018 - link
The overhead of HPET causes the Intel CPUs to effectively slow down with the combination of the Meltdown+Spectre fixes. HPET is a system call which results in the harshest penalty of the fixes for Meltdown+Spectre. Add to the fact that Intel's implementation of HPET is higher fidelity (i.e. higher speed clock rate) than the specification requires, and then combine that higher fidelity with creating an even larger load on the CPU (due to Meltdown+Spectre), and it creates the large performance degradation.The other timers (TSC + lapic) do not incur as high a penalty, as these do not result in system calls which need to be protected from Meltdown/Spectre exploitation.
mczak - Wednesday, April 25, 2018 - link
The higher clock the HPET runs at for intel should make absolutely no difference - it's the cost of reading the timer which counts, the rate it's running at should not be relevant. (Although I higher frequency may have higher hw implementation cost.).For this kind of slowdown as shown in some games though there have to be LOTS of timer queries. But I suppose it's definitely possible (I suspect nowadays everyone uses the TSC based queries and forget to test without them being available), which are much faster in hw and don't require syscalls. Meltdown (and probably to a lesser degree Spectre) could indeed have a big impact on performance with HPET (if there's that many timing queries). I'd like to see some data with HPET but without these patches.
looncraz - Wednesday, April 25, 2018 - link
I believe, from my own testing, that it's merely a factor of reporting. HPET has always resulted in a smoother, faster, system with less stutters when I enable it.I also use SetTimerResolutionService to great effect.
tamalero - Thursday, April 26, 2018 - link
Its interesting how it is very different from person to person.I usually had HPET on with my intel Quadcores..
But once I got my Threadripper I had to disable and remove HPET. If not I would get horrible stuttering.
GreenReaper - Friday, April 27, 2018 - link
It may be more *responsive*, yet able to do less work. In fact, speed and latency can be opposites - if you never pick your head up while doing a task, you'll probably execute it in the fastest possible time, at the expense of anything else that you might have wanted to do during that time. Most interactive users don't appreciate the computer not paying attention to them, so desktop computers tradeoff for speed for reduced latency - although with multi-core systems the impact is small.In the past when the TSC was not present, HPET also moved the system more towards being a real-time system, and the cost of that the overhead of the more frequent timer checks. Nowadays, especially with nonstop TSC (not impacted by power management), I'm not sure that is the case, but using it might still change latency - for good or ill.
Enabling HPET does not mandate forcing its use over the alternatives, but mandating it with 'bcdedit /set useplatformclock true' does. You can do the equivalent on Linux. And clearly, there is a cost, although that cost varies greatly depending on the platform and what you are doing.
Over the years I've seen numerous cases of people trying to reduce the number of gettimeofday calls to increase performance, and the cost of checking the HPET is probably one of the reasons.
Ryan Smith - Thursday, April 26, 2018 - link
"But is there a 'real' performance impact or does default HPET behavior simply introduce a fudge factor that alters how the tools report the numbers? Is there a way to verify the results externally?"Yes, you can compare the clocks with various applications, including the Timers applications. Which in our case shows that neither the ACPI nor QPC timers are drifting versus the HPET timer. So the performance difference really is a performance difference, and not a loss of timer accuracy.
https://images.anandtech.com/doci/12678/TimerBench...
chrcoluk - Wednesday, April 25, 2018 - link
Disabling TSC is a big nono.Forced HPET as an example will disable optimised interrupts for network cards, the AMD and intel review support staff probably dont have the knowledge to correctly advise you. I suggest you contact microsoft.
Also your cpu's tested, what decides what cpu's you decided to compare to? the AMD review guide or something else? Was a lot of omitted CPU's and noticeably no manual overclocked intel cpu's in your data.
See my first reply, if AMD software is forcing HPET and especially if they not informing the user the consequences of doing this then thats very irresponsible.
eddman - Thursday, April 26, 2018 - link
Some rather interesting info on timers from MS: https://msdn.microsoft.com/en-us/library/windows/d...