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
BillyONeal - Wednesday, April 25, 2018 - link
The TSC is *clock cycle* accurate but not *real time* accurate. It speeds up and slows down relative to real time with changes in CPU clock speed; such as what CPUs do on their own when system power state changes.That is, when a hypothetical 1.6GHz chip downclocks to 800MHz, the TSC's rate relative to real time is cut in half.
mczak - Wednesday, April 25, 2018 - link
No, that was true maybe 10+ years ago.There's several flags to indicate TSC properties:
- constant (fixed clock rate, but may be halted depending on C-State)
- invariant (runs the same independent from C-State)
All intel cpus since at least Nehalem (the first Core-i chips) should support these features (not entirely sure about AMD, probably since Bulldozer or thereabouts).
The TSCs are also usually in-sync for all cpu cores (on single socket systems at least), albeit I've seen BIOSes screwing this up majorly (TSC reg is allowed to be written, but this will destroy the synchronization and it is impossible to (accurately) resync them between cores - unless your cpu supports tsc_adjust meaning you can write an offset reg instead of tsc directly), causing the linux kernel to drop tsc as a clock source even and using hpet instead (at least at that time the kernel made no attempt to resync the TSCs for different cores).
So on all "modern" x86 systems, usually tsc based timing data should be used. It is far more accurate and has far lower cost than anything else. If you need a timer (to generate an interrupt) instead of just reading the timing data, new cpus actually support a tsc_deadline mode, where the local apic will generate an interrupt when the TSC reaches a programmed value.
mczak - Wednesday, April 25, 2018 - link
FWIW I think the reason Ryzen Master (and some other software for OC) requires HPET is because, while the TSC frequency is invariant, it might not be as invariant as you'd like it to be when overclocking (though Ryzen Master has the HPET requirement fixed a while ago).Ryzen PPR manual (https://support.amd.com/TechDocs/54945_PPR_Family_... says that the TSC invariant clock corresponds to P0 P-State - this would be cpu base clock. So then naturally from that follows if you were to change the base clock for overclocking, the TSC clock would change too, causing all sort of mayhem since likely the OS is going to rely on TSC being really invariant (as it's announced as such).
That said, this manual says (for MSRC001_0015) there's a "LockTscToCurrentP0: lock the TSC to the current P0 frequency" bit. It does just what the doctor asked for:
"LockTscToCurrentP0: lock the TSC to the current P0 frequency. Read-write. Reset: 0. 0=The TSC will count at the P0 frequency. 1=The TSC frequency is locked to the current P0 frequency at the time this bit is set and remains fixed regardless of future changes to the P0 frequency."
So maybe they are now setting this (or maybe they always set this and requiring HPET had other reasons...).
BillyONeal - Wednesday, April 25, 2018 - link
Because Intel has mitigated Spectre microcode available, and no such thing is available for AMD yet. Intel is paying that context switching overhead and AMD isn't (yet).Spunjji - Thursday, April 26, 2018 - link
Factually incorrect here:https://arstechnica.com/gadgets/2018/04/latest-win...
Given AT are running brand-new AMD CPUs with the latest version of Windows 10, I'm pretty sure they have this code active.
Nutty667 - Thursday, April 26, 2018 - link
It's nothing todo with the accuracy of HPET, but the cost in reading HPET.Reading HPET is an IO operation and system call, which means you hit the Meltdown mitigation penalty, something that AMD does not suffer from.
chrcoluk - Wednesday, April 25, 2018 - link
no forcing HPET is a very unusual config, no modern OS has it as the default time on modern hardware. Not only is it slower but also things like msi-x require LAPIC to work.In short what anandtech did here is "very bad".
patrickjp93 - Wednesday, April 25, 2018 - link
Well, for every OS but the BSD variety.Ratman6161 - Friday, April 27, 2018 - link
"forcing HPET is a very unusual config,"Actually I think it may be very common. For example, based on what I read, in the article my system will have it forced and I never even knew it (will check it as soon as I get home). See, I always do my overclocking from the bios/uefi stings. But a while back, just for grins I decided to try out Ryzen Master. I messed around with it for a while, didn't really like it, and uninstalled it. But the story says when I installed it and rebooted, then it was forced on and that setting did not go away when I uninstalled Ryzen Master. So, essentially anyone who has ever used Ryzen Master or a similar tool will be forced on unless they knew enough to turn it off. I certainly had no clue how this worked and I'm betting that most other people were as clueless as me.
Ratman6161 - Friday, April 27, 2018 - link
"In short what anandtech did here is "very bad"."Or you could interpret it as very good because all of us who had no clue have now learned something :)