I'm the dude that was interviewed for the article. I'd like to answer your questions and chime in.
I do very much think that the title is misleading and the whole article is hung up on Zen 2 too much. The use of "Clock Bug" in the title adds to the confusion and is mistaken for the "Boost Clock Bug" a few times in the comments on Facebook.
That said the core of the article was actually about trust in benchmark results. We assume that a platform returns valid results, when we actually shouldn't. The "RTC bug" is one of the reasons why we can't. We see a screen in some forum or a number in a vendor ad and the truth is that we can't rely on that. We might know from our own systems, that we haven't fiddled with the base clock or weren't cheating, but we have no clue what somebody else was doing.
This applies to reviewers a well. Anandtech for example had a wrong timer configuration and all result were skewed due to its performance impact (not skewing!) on the benches. We all saw the numbers there, but had no clue that the author had HPET enabled in Windows. Here is the article about what happened: https://www.anandtech.com/show/12678/a-timely-discovery-examining-amd-2nd-gen-ryzen-results
That's what BenchMate does. It gives you the information to verify for yourself that this score is trustworthy, reliable and repeatable.
On the other hand, AMD can alter their design of their platform to maintain two bus clocks. A single one that's stuck to exactly 100 MHz and a second one that drives memory and CPU. Intel did that with Skylake and I'd like to think intentionally removed that flaw. It might still be there for non-Z mainboards though, as it seems that they only have one bus clock to reduce costs. My guess is that modded H boards should be prone to the same timer skewing as well.
If you have any questions regarding all this, just let me know.
That's exactly what the article is saying. It needs to be enabled in BIOS, afterwards enabled in Windows (bcdedit) then rebooted. The system will use HPET as the System Clock Interrupt and for the often used QueryPerformanceCounter (WIN32 API function).The article is neither wrong nor 100%. Its actually both. You have to verify the BIOS supports it and make sure its enabled then you have to force Windows to use it:
Try changing HPET settings to improve your PC's performance - gHacks Tech News
Find out how to detect timer settings on a Windows PC, to change them to improve performance, and to measure the performance using benchmarks.www.ghacks.net
No, Linux is affected as well on the before-mentioned platforms, if the OS is configured to use the LAPIC timer as time source (which normally is the case) and depended timer functions or the RDTSC(P) instruction is used. But Linux doesn't allow to change the bus frequency easily and it's not used for overclocking much, so it's not really a relevant issue.
The article was heavily edited and prematurely released by accident. My interview was pretty much slashed from 14,000 chars to a few lines.
I do very much think that the title is misleading and the whole article is hung up on Zen 2 too much. The use of "Clock Bug" in the title adds to the confusion and is mistaken for the "Boost Clock Bug" a few times in the comments on Facebook.
That said the core of the article was actually about trust in benchmark results. We assume that a platform returns valid results, when we actually shouldn't. The "RTC bug" is one of the reasons why we can't. We see a screen in some forum or a number in a vendor ad and the truth is that we can't rely on that. We might know from our own systems, that we haven't fiddled with the base clock or weren't cheating, but we have no clue what somebody else was doing.
This applies to reviewers a well. Anandtech for example had a wrong timer configuration and all result were skewed due to its performance impact (not skewing!) on the benches. We all saw the numbers there, but had no clue that the author had HPET enabled in Windows. Here is the article about what happened: https://www.anandtech.com/show/12678/a-timely-discovery-examining-amd-2nd-gen-ryzen-results
That's what BenchMate does. It gives you the information to verify for yourself that this score is trustworthy, reliable and repeatable.
You are right, Microsoft could detect Ryzen and change the time source for the System Clock Interrupt to something else (like RTC in Windows 7). But let's not forget about the requirements of tickless kernels as I've tried to answer in the article. I'd like to think that there was a reason for switching to the flawed LAPIC timer.
On the other hand, AMD can alter their design of their platform to maintain two bus clocks. A single one that's stuck to exactly 100 MHz and a second one that drives memory and CPU. Intel did that with Skylake and I'd like to think intentionally removed that flaw. It might still be there for non-Z mainboards though, as it seems that they only have one bus clock to reduce costs. My guess is that modded H boards should be prone to the same timer skewing as well.
If you have any questions regarding all this, just let me know.
Facebook
Twitter
Instagram