TR Forums

Read all about it here.

Basically, due to forcing HPET to be activated as the system timer on all platforms (even when the platform did not default to using HPET) Anand managed to give RyZen a noticeable relative performance boost compared to the Intel systems in its review. That wasn't because RyZen was inherently faster, but because forcing HPET on slowed down the Intel systems artificially.

There were performance penalties to this misconfiguration that negatively affected Intel while having little to no effect on AMD (less than 1% either way). Some of the performance penalties were relatively small but others were massive:



So, for all the people who were claiming that Anand was the only source of the "truth" about RyZen gaming performance online and that everybody else was some kind of pro-Intel idiot (TR included) you might want to backtrack. Once again, TR shows that it is the gold-standard for proper hardware reviews. I will give props to Anandtech for being honest and posting a detailed account of what happened to its review though.

This is interesting to me because I'd always forced HPET to be enabled on all my systems in the past. I don't currently have an Intel system, but it seems like I was potentially hamstringing performance. Also it's interesting because it fixed Anandtech's review to match all the others, and now we know why.

derFunkenstein wrote:

This is interesting to me because I'd always forced HPET to be enabled on all my systems in the past.

Why?

The name confused me. High precision. Well I want highly precise events. And that's a wrap, I never thought about it again.

I am not ashamed to say I don't know everything about every BIOS tweak on the planet.

derFunkenstein wrote:

The name confused me. High precision. Well I want highly precise events. And that's a wrap, I never thought about it again.

I am not ashamed to say I don't know everything about every BIOS tweak on the planet.

It's OK, timer source configurations are a giant PITA and what was once the new-shiny technology (HPET) can become obsolete and actually harmful to performance over a few iterations of hardware.

Anand's problem was in forcing HPET on even when the default platform went out of its way to avoid doing so. I'm not expecting Anand to performance-tweak in anybody's favor, but it's a two-way street in also avoiding negative performance-tweaks.

It's also their job to know which BIOS settings do what. So I understand being less forgiving of them.

What is really surprising is the difference in impact between AMD and Intel.

What benefit does HPET have in everyday life? Is it important for servers? Sorry, haven't been able to read the entire write up yet.

derFunkenstein wrote:

This is interesting to me because I'd always forced HPET to be enabled on all my systems in the past. I don't currently have an Intel system, but it seems like I was potentially hamstringing performance. Also it's interesting because it fixed Anandtech's review to match all the others, and now we know why.

Did something better come out while I wasn't paying attention? I never turn it off, but I'm usually fond of the default options.

Even the tiniest thing can come back and bite you.

I find it interesting that timers are not exactly the same across all mainboards and processor types.

I actually thought the HEPT was a STANDARD it only ran at one speed (14.33mhz) and this had been the standard since Pentium 3/4 days.
I guess it is NOT a standard in that way, it's just another available clock timer.

The more interesting graphs, academically, are the ones you neglected to show: the AMD version of that graph, or the graph from the following pages where the "unforced" results for both platforms are shown normalised to the AMD results.

They show that both systems were affected in the same contexts, and only the magnitude of the effect was different; firstly, it makes me wonder what exactly those programs are doing that causes such a discrepancy, but it also makes me wonder how much different the results would be if the HPET for both systems was running at the same frequency - given that the Intel platform's was running at, what, 5 / 3rds the AMD's.

Interesting read! I learned something new today.

We actually had a thread about this sort of issue years ago:

viewtopic.php?f=4&t=89149

There difference there was that people would mess with their clock-rate behind the OS's back, so the OS timer routines using RDTSC would calculate wrong.

Here, the problem is that somehow Anandtech was testing with the OS using HPET, which breaks apples-to-apples (implementations can vary).

DerFunkenstein wrote:

This is interesting to me because I'd always forced HPET to be enabled on all my systems in the past.

The BIOS option by itself can't do it, Windows has to decide to exclusively use it. As in, the BIOS can make it available or not, but it has absolutely no way of forcing Microsoft to NOT use RDTSC.

We talked about that in the thread above, but there were some BCD options that Ryu Connor indicated were not a good idea.

I don't know, but I'm guessing that Anandtech found out why.

More generally, properly handled RDTSC-based methods are always superior--solely CPU stuff, not ACPI etc... which is also interrupt-based.

As Ryu Connor said in the thread I cited, there's no way Microsoft defaults to HPET only.

This is some odd OS configuration that Anandtech did deliberately without realizing that they shouldn't have.

Is there a way to check if HPET is being Forced in the OS?
What is the command to disable OS-Forced HPET?

I'm sure I could google these answers up, but thought it might be helpful to others to have the instructions in this thread. Either someone can chime in, or I will update later this evening when I do my research.

Oh I read the article.



Not at Anandtech though, but at this:

Anandtech wrote:

Ryzen Master is not the only piece of software that requires HPET to be forced in order to do what it needs to do. For any of our readers that have used overclocking software and tools before, or even monitoring tools such as fan speed adjusters – if those tools have requested a restart before being used properly, there is a good chance that in that reboot the command has been run to enable HPET.

Every time people go all "EVIL M$!!!1" with how Bad-Daddy Bill Gates "DELETED MY SOFTWARE HOW DARE THEY UTTERLY UNCONSCIONABLE! ARGHHH", yeah--THAT'S WHY.

Your "software" is doing something stupid and wrong mucking with the internals of the OS in a way that it absolutely shouldn't. PRIME EXAMPLE: This garbage, which shouldn't be FORCING your OS timer because, that one time years ago, someone noticed that if you manipulate, at RUNTIME, the base clock and multiplier, you can (SURPRISE SURPRISE) make the computer clock slower than the wall clock and then get "better" OC benchmarks.

I can't even

---

Look, I'm basically a Linux guy now, I have a windows gaming computer that is basically a glorified Xbox, a HTPC in the basement I never turn on these days, and a cheapo 90 dollar windows tablet for reading/watching. That's it.

Microsoft is doing god's work, it's all these clowns screwing with things they don't understand for ill-conceived purposes that you should be mad at.

DPete27 wrote:

Is there a way to check if HPET is being Forced in the OS?
What is the command to disable OS-Forced HPET?

Windows 10 defaults to NOT exclusively using HPET.

You can force it to use HPET by adding through Command Prompt/PowerShell (Admin privileges required?) - bcdedit /set useplatformclock true (then reboot) enable HPET
revert to default - bcdedit /deletevalue useplatformclock (then reboot) disables only using HPET

Glorious wrote:

DerFunkenstein wrote:

This is interesting to me because I'd always forced HPET to be enabled on all my systems in the past.

The BIOS option by itself can't do it, Windows has to decide to exclusively use it. As in, the BIOS can make it available or not, but it has absolutely no way of forcing Microsoft to NOT use RDTSC.

We talked about that in the thread above, but there were some BCD options that Ryu Connor indicated were not a good idea.

I don't know, but I'm guessing that Anandtech found out why.

More generally, properly handled RDTSC-based methods are always superior--solely CPU stuff, not ACPI etc... which is also interrupt-based.

As Ryu Connor said in the thread I cited, there's no way Microsoft defaults to HPET only.

This is some odd OS configuration that Anandtech did deliberately without realizing that they shouldn't have.

I only ever heard about it because going a decade back will show you lots of Google results for enabling HPET for Hackintosh systems. So I just (out of habit) turned in on with every new motherboard I got. In fact, I found one from the days of the Sierra public beta still recommending it. That's pretty recent (link not provided).

All I ever did was set the BIOS option, so maybe I wasn't losing out

Yeah it sounds like a corner case for sure. Neither AMD or Intel sounded very concerned about it in the statements that Anandtech posted. It seems like this is really just more for the sake of explanation on why their initial numbers were weird than a story about the HPET timer its self.

Under Linux I performed this command to check my current clock source [your exact path may vary a little starting at the "clocksource0" directory]:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

the result was: tsc

Interestingly enough, in my dmesg history there are several messages indicating that HPET is enabled and is acting as a clock source, so something must be changing the clock source at a later point during operation of the system.

Edit: and here we go. See the timestamps on the left side:



and later

Glorious wrote:

Oh I read the article.

Anandtech wrote:

Ryzen Master is not the only piece of software that requires HPET to be forced in order to do what it needs to do. For any of our readers that have used overclocking software and tools before, or even monitoring tools such as fan speed adjusters – if those tools have requested a restart before being used properly, there is a good chance that in that reboot the command has been run to enable HPET.

Your "software" is doing something stupid and wrong mucking with the internals of the OS in a way that it absolutely shouldn't. PRIME EXAMPLE: This garbage, which shouldn't be FORCING your OS timer because, that one time years ago, someone noticed that if you manipulate, at RUNTIME, the base clock and multiplier, you can (SURPRISE SURPRISE) make the computer clock slower than the wall clock and then get "better" OC benchmarks.

I believe the current version of Ryzen Master does not require HPET events. See this AMD blog post:

https://community.amd.com/community/gam ... y-update-2

derfunkenstein wrote:

I only ever heard about it because going a decade back will show you lots of Google results for enabling HPET for Hackintosh systems. So I just (out of habit) turned in on with every new motherboard I got. In fact, I found one from the days of the Sierra public beta still recommending it. That's pretty recent (link not provided).

I know like nothing about MacOS, but given Apple's complete control of hardware, the lack of such a feature which *SHOULD* have be there might cause Hackintosh attempts to completely fail. You know, even if they don't use it (as opposed to using it in some ancient deprecated timer API), if it isn't there some check just might cause the whole thing to crash or die.

Basically, enabling it in the BIOS should never be a problem. Windows knows better. Now, with what I learned? Well, if some software configures your system to force it and you don't realize that, jeez, turning it off in the BIOS might be a like a defensive measure...

I've always enabled it too, because it shouldn't ever hurt anything. If you are even using some sort of hypervisor, I'd have to assume they'd know better too...?

Redocbew wrote:

Yeah it sounds like a corner case for sure. Neither AMD or Intel sounded very concerned about it in the statements that Anandtech posted.

Because nothing is "wrong".

If people (like Anandtech) are installing software that, unbeknownst to them, deliberately configures Windows to *ONLY* use the HPET, yes, that has performance (and power efficiency) implications.

That's not AMD or Intel's problem. Their chip isn't malfunctioning, or running slower.

And, phew, Microsoft. Well, if they try to do anything about this, THEY WILL BE SCREAMED AT. By the very people Microsoft is trying to help!

Because, obviously, any random Overclocking/Monitoring software isn't the problem, nooooooo, it's Microsoft which is running some evil conspiracy when it "breaks" or "removes" those programs.

The real problem is that fan monitoring software etc... shouldn't be forcing this. Ryu Connor wisely said, when this whole thing started in 2013, that mucking around with BCD to do this was a VERY BAD, NO GOOD, UGLY idea.

Well yeah, there's a million and one things that can make an otherwise decent machine run poorly, and it's usually best to leave things deep in the system like this well enough alone. I'm sure some people will take away from this story that "HPET = bad", but that's not the whole picture at all.

Ahh heh. That's what this is about. I used to force it in Windows a long time ago because I didn't know any better.

What system clock do extreme overclockers now have to use to submit a valid benchmark?

Ideally any testing shouldn't trust the system clock at all. For really accurate results the variances shown here even with AMD's HPET seem too big to be trusting an internal timer which is being affected by the machine's thermals and clock swings.

This might be the next big shakeup when it comes to PC reviews, the last being frametimes.

Mr Bill wrote:

What system clock do extreme overclockers now have to use to submit a valid benchmark?

For the unfamiliar, Hwbot is the primary database/rule making authority for competitive overclocking.

Windows 8 and Windows 10 have an issue with RTC time-drift on some platforms. As a result, most platforms and benchmarks cannot be run on either version of Windows. On the few benchmarks that can be run on Windows 8/10 regardless of platform, HPET must be used. But none of that matters. Windows 8/10 is not the most efficient (fastest) OS for any 2D benchmark and accordingly doesn't get used for any benching. RTC is pretty much used on all the time as a result.

http://hwbot.org/news/9824_breaking_win ... _at_hwbot/
http://hwbot.org/news/12505_application_175_rules/
https://imgur.com/a/Jgq3FOU

DrDominodog51 wrote:

Windows 8 and Windows 10 have an issue with RTC time-drift on some platforms.

No they don't.

This kind of "understanding" is not even wrong:

http://hwbot.org/newsflash/2684_windows ... ed_for_now

That's not a bug. It's not a bug that if I type 7x7 into Windows Calculator as opposed to 7x6 that I get 42 as opposed to 49.

Which is precisely what we are talking about here: changing the inputs to a program will always get you answer that is correct for *THOSE* inputs, not the inputs you wanted.

I mean, this is actually an ABSOLUTELY ANCIENT COMPUTER SCIENCE ANECDOTE:

Passages from the Life of a Philosopher wrote:

On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

That's last sentence is pretty much my response to these hwbot people, I can't even

DrDominodog51 wrote:

As a result, most platforms and benchmarks cannot be run on either version of Windows.

Because of make-believe security in which they think that since they've crudely worked around one method of easily cheating, that other related methods don't exist.

That is really silly.

DrDominodog51 wrote:

On the few benchmarks that can be run on Windows 8/10 regardless of platform, HPET must be used. But none of that matters. Windows 8/10 is not the most efficient (fastest) OS for any 2D benchmark and accordingly doesn't get used for any benching. RTC is pretty much used on all the time as a result.

So, what, everyone does this on Windows 7?

What happens in a few years?

DragonDaddyBear wrote:

What is really surprising is the difference in impact between AMD and Intel.

It might be an interrupt overhead thing, possibly exacerbated by Meltdown mitigation. IIRC HPET generates an interrupt at every "tick".

DragonDaddyBear wrote:

What benefit does HPET have in everyday life? Is it important for servers? Sorry, haven't been able to read the entire write up yet.

When it was introduced, it allowed intervals to be timed more accurately and/or with lower overhead than previous methods. In the "bad old days" (DOS and early Windows systems) all we had was the 55ms timer tick. Then came the 1ms multimedia timer, ACPI timer, and HPET.

x86 CPUs also have something called the Time Stamp Counter (TSC), which is typically the highest resolution and lowest overhead source available (since it ticks at the rate of the base CPU clock and only requires reading a value out of a machine register to access it). Although present since the Pentium days, older implementations suffered from various issues (tick rate varying with power management clock scaling, TSC not being synchronized across cores, etc...), but AFAIK all recent x86 designs provide a TSC that ticks at a constant rate, and is synchronized across all cores in the CPU package.

just brew it! wrote:

DragonDaddyBear wrote:

What is really surprising is the difference in impact between AMD and Intel.

It might be an interrupt overhead thing, possibly exacerbated by Meltdown mitigation. IIRC HPET generates an interrupt at every "tick".

DragonDaddyBear wrote:

What benefit does HPET have in everyday life? Is it important for servers? Sorry, haven't been able to read the entire write up yet.

When it was introduced, it allowed intervals to be timed more accurately and/or with lower overhead than previous methods. In the "bad old days" (DOS and early Windows systems) all we had was the 55ms timer tick. Then came the 1ms multimedia timer, ACPI timer, and HPET.

x86 CPUs also have something called the Time Stamp Counter (TSC), which is typically the highest resolution and lowest overhead source available (since it ticks at the rate of the base CPU clock and only requires reading a value out of a machine register to access it). Although present since the Pentium days, older implementations suffered from various issues (tick rate varying with power management clock scaling, TSC not being synchronized across cores, etc...), but AFAIK all recent x86 designs provide a TSC that ticks at a constant rate, and is synchronized across all cores in the CPU package.

My Linux systems are defaulting to TSC even though they list HPET as being an "available" clock source.

chuckula wrote:

My Linux systems are defaulting to TSC even though they list HPET as being an "available" clock source.

Same. Most distros on modern hardware seem to list tsc, hpet, and acpi_pm as available sources, and default to tsc.

IIRC the only time I've needed to force it on Linux was several years ago on some older hardware (Socket AM2?), where I had to force the use of acpi_pm. I don't even remember what issue it was I was trying to fix, but I do recall that empirically acpi_pm was the only choice that seemed to address it. Since then, I just let the system choose, and haven't had any issues with it.

Chuck and JBI, thank you for the explanation. If you don't mind me asking, what kinds of applications would such a counter be needed for? Could you not run into race conditions if incorrectly used this? Sorry for the probably silly question, not a programmer.