Forcing HPET On, Plus Spectre and Meltdown Patches

Based on my extreme overclocking roots back in the day, my automated benchmark scripts for the past year or so have forced HPET through the OS. Given that AMD’s guidance is now that it doesn’t matter for performance, and Intel hasn’t even mentioned the issue relating to a CPU review, having HPET enabled was the immediate way to ensure that every benchmark result was consistent, and would not be interfered with by clock drift on special motherboard manufacturer in-OS tweaks. This was a fundamental part of my overclocking roots – if I want to test a CPU, I want to make certainly sure that the motherboard is not causing any issues. It really gets up my nose when after a series of CPU testing, it turns out that the motherboard had an issue – keeping HPET on was designed to stop any timing issues should they arise.

From our results over that time, if HPET was having any effect, it was unnoticed: our results were broadly similar to others, and each of the products fell in line with where they were expected. Over the several review cycles we had, there were a couple of issues that cropped up that we couldn’t explain, such as our Skylake-X gaming numbers that were low, or the first batch of Ryzen gaming tests, where the data was thrown out for being obviously wrong however we never managed to narrow down the issue.

Enter our Ryzen 2000 series numbers in the review last week, and what had changed was the order of results. The way that forcing HPET was affecting results was seemingly adjusted when we bundle in the Spectre and Meltdown patches that also come with their own performance decrease on some systems. Pulling one set of results down further than expected started some alarm bells and needed closer examination.

HPET, by the way it is invoked, is programmed by a memory mapped IO window through the ACPI into the circuit found on the chipset. Accessing it is very much an IO command, and one of the types of commands that fall under the realm of those affected by the Spectre and Meltdown patches. This would imply that any software that required HPET access (or all timing software if HPET is forced) would have the performance reduced even further when these patches are applied, further compounding the issue.

It Affects AMD and Intel Differently: Productivity

So far we have done some quick initial re-testing on the two key processors in this debate, the Ryzen 7 2700X and Intel Core i7-8700K. These are the two most talked about processors at this time, due to the fact that they are closely matched in performance and price, with each one having benefits in certain areas over the other. For our new tests, we have enabled the Spectre/Meltdown patches on both systems – HPET is ‘on’ in the BIOS, but left as ‘default’ in the operating system.

For our productivity tests, on the Intel system, there was an overall +3.3% gain when un-forcing HPET in the OS:

The biggest gains here were in the web tests, a couple of the renderers, WinRAR (memory bound), and PCMark 10. Everything else was pretty much identical. Our compile tests gave us three very odd consecutive numbers, so we are looking at those results separately.

On the AMD system, the productivity tests difference was an overall +0.3% gain when un-forcing HPET in the OS:

This is a lower gain, with the biggest rise coming from PCMark10’s video conference test to the tune of +16%. The compile test results were identical, and a lot of tests were with 1-2%.

If Affects AMD and Intel Differently: Gaming

The bigger changes happen with the gaming results, which is the reason why we embarked on this audit to decipher our initial results. Games rely on timers to ensure data and pacing and tick rates are all sufficient for frames to be delivered in the correct manner – the balance here is between waiting on timers to make sure everything is correct, or merely processing the data and hoping it comes out in more or less the right order: having too fine a control might cause performance delays. In fact, this is what we observe.

With our GTX 1080 and AMD’s Ryzen 7 2700X, we saw minor gains across the board, however it was clear that 1080p was the main beneficiary over 4K. The 10%+ adjustments came in only Civilization 6 and Rise of the Tomb Raider.

Including the 99th percentile data, removing HPET gave an overall boost of around 4%, however the most gains were limited to specific titles at the smaller resolutions, which would be important for any user relying on fast frame rates at lower resolutions.

The Intel side of the equation is where it gets particularly messy. We rechecked these results several times, but the data was quite clear.

As with the AMD results, the biggest beneficiaries of disabling HPET were the 1080p tests. Civilization 6 and Rise of the Tomb Raider had substantial performance boosts (also in 4K testing), with Grand Theft Auto observing an additional +27%. By comparison, Shadow of Morder was ‘only’ +6%.

Given that the difference between the two sets of data is related to the timer, one could postulate that the more granular the timer, the more the effect it can have: on both of our systems, the QPC timer is set for 3.61 MHz as a baseline, but the HPET frequencies are quite different. The AMD system has a HPET timer at 14.32 MHz (~4x), while the Intel system has a HPET timer at 24.00 MHz (~6.6x). It is clear that the higher granularity of the Intel timer is causing substantially more pipeline delays – moving from a tick-to-tick delay of 277 nanoseconds to 70 nanoseconds to 41.7 nanoseconds is crossing the boundary from being slower than a CPU-to-DRAM access to almost encroaching on a CPU-to-L3 cache access, which could be one of the reasons for the results we are seeing, along with the nature of how the HPET timer works.

There is also another aspect to gaming that does not appear with standard CPU tests: depending on how the engine is programmed, some game developers like to keep track of a lot of the functions in flight in order to either adjust features on the fly, or for internal metrics. For anyone that has worked extensively on a debug mode and had to churn through the output, it is basically this. If a title had shipped with a number of those internal metrics still running in the background, this is exactly the sort of issue that having HPET enabled could stumble upon - if there is a timing mismatch (based on the way HPET works) and delays are introduced due to these mismatches, it could easily slow down the system and reduce the frame rate.

AMD and Intel Have Different HPET Guidance Why This Matters
POST A COMMENT

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.EXE Reply
  • Maxiking - 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. Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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...
    Reply
  • 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.
    Reply
  • eddman - Thursday, April 26, 2018 - link

    Some rather interesting info on timers from MS: https://msdn.microsoft.com/en-us/library/windows/d... Reply

Log in

Don't have an account? Sign up now