AMD and Intel Have Different HPET Guidance

A standard modern machine, with a default BIOS and a fresh Windows operating system, will sit on the first situation in the table listed above: the BIOS has HPET enabled, however it is not explicitly forced in the operating system. If a user sets up their machine with no overclocking or monitoring software, which is the majority case, then this is the implementation you would expect for a desktop.

AMD

We reached out to AMD and Intel about their guidance on HPET, because in the past it has both been unclear as well as it has been changed. We also reached out to motherboard manufacturers for their input.

For those that remember the Ryzen 7 1000-series launch, about a year ago from now, one point that was lightly mentioned among the media was that in AMD’s press decks, it was recommended that for best performance, HPET should be disabled in the BIOS. Specifically it was stated that:

Make sure the system has Windows High Precision Event Timer (HPET) disabled. HPET can often be disabled in the BIOS. [T]his can improve performance by 5-8%.

The reasons at the time were unclear as to why, but it was a minor part in the big story of the Zen launch so it was not discussed in detail. However, by the Ryzen 5 1000-series launch, that suggestion was no longer part of the reviewer guide. By the time we hit the Ryzen-2000 series launched last week, the option to adjust HPET in the BIOS was not even in the motherboards we were testing. We cycled back to AMD about this, and they gave the following:

The short of it is that we resolved the issues that caused a performance difference between on/off. Now that there is no need to disable HPET, there is no need for a toggle [in the BIOS].

Interestingly enough, with our ASUS X470 motherboard, we did eventually find the setting for HPET – it was not in any of the drop down menus, but it could be found using their rather nice ‘search’ function. I probed ASUS about whether the option was enabled in the BIOS by default, given that these options were not immediately visible, and was told:

It's enabled and never disabled, since the OS will ignore it by default. But if you enable it, then the OS will use it – it’s always enabled, that way if its needed it is there, as there would be no point in pulling it otherwise.

So from an AMD/ASUS perspective, the BIOS is now going to always be enabled, and it needs to be forced in the OS to be used, however the previous guidance about disabling it in the BIOS has now gone, as AMD expects performance parity.

It is worth noting that AMD’s tool, Ryzen Master, requires a system restart when the user first loads it up. This is because Ryzen Master, the overclocking and monitoring tool, requires HPET to be forced in order to do what it needs to do. In fact, back at the Ryzen 7 launch in 2017, we were told:

AMD Ryzen Master’s accurate measurements present require HPET. Therefore it is important to disable HPET if you already installed and used Ryzen Master prior to game benchmarking.

Ultimately if any AMD user has Ryzen Master installed and has been run at any point, HPET is enabled, even if the software is not running or uninstalled. The only way to stop it being forced in the OS is with a command to chance the value in the BCD, as noted above.

For the Ryzen 2000-series launch last week, Ryzen Master still requires HPET to be enabled to run as intended. So with the new guidance that HPET should have minimal effect on benchmarks, the previous guidance no longer applies.

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. Unfortunately it is not easy to generate a list, as commands and methods may change from version to version, but it can apply to CPU and GPU overclocking.

Intel

The response we had from Intel was a little cryptic:

[The engineers recommend that] as far as benchmarking is concerned, it should not matter whether or not HPET is enabled or not. There may be some applications that may not function as advertised if HPET is disabled, so to be safe, keep it enabled, across all platforms. Whatever you decide, be consistent across platforms.

A cold reading of this reply would seem to suggest that Intel is recommended HPET to be forced and enabled, however my gut told me that Intel might have confused ‘on’ in the BIOS with ‘forced’ through the OS, and I have asked them to confirm.

Looking back at our coverage of Intel platforms overall, HPET has not been mentioned to any sizeable degree. I had two emails back in 2013 from a single motherboard manufacturer stating that disabling HPET in the BIOS can minimise DPC latency on their motherboard, however no comment was made about general performance. I cannot find anything explicitly from Intel though.

A Timely Re-Discovery Forcing HPET On, Plus Spectre and Meltdown Patches
POST A COMMENT

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.
    Reply
  • 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.
    Reply
  • 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...).
    Reply
  • 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). Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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".
    Reply
  • patrickjp93 - Wednesday, April 25, 2018 - link

    Well, for every OS but the BSD variety. Reply
  • 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.
    Reply
  • 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 :)
    Reply

Log in

Don't have an account? Sign up now