I'm going to bet that HWBot's claim that this is due to changes to support mobile hardware without RTC is bunk.
Specifically, I believe it is due to the "timer coalescing" feature that was added to save power.
In previous versions of Windows, the RTC interrupt is set to occur at a fixed interval, between 15.125 and 20ms, depending on the OS version (most versions of windows set it to 15.125, meaning 64 times per second). The highest interval for which this hardware timer can be set to occur is 55ms (which it defaults to before the OS loads). When the computer is powered on, the OS updates the "wall clock" whenever that interrupt occurs. So even if your PC is completely idle, and no process has a polling sleep timer that needs to be woken up, your CPU is actually briefly woken up 64 times per second. And BTW, legacy OSes using this RTC counter would
NOT prevent cheating on benchmarks. There are APIs specifically for adjusting the interval of the clock increments in case your clock is running fast or slow used by NTP clients. If you try to make your clock run half speed for a gaming advantage Windows will ignore the attempt, but if you keep it within a sane margin it works.
In Windows 8, in order for tablets to have reasonable battery life, even waking up only every 55ms which would be as little as the RTC hardware would allow would be too much. So the 64 bit counter that wakes the
HPET timer is being used instead of the legacy RTC. Interestingly, unlike the counter whose rollover triggers the RTC interrupt, which always was incrementing at 4.77MHz/4 at a lower level for legacy compatibility reasons, the more modern HPET timer has a frequency that gets discovered by ACPI.
It looks like maybe modern Intel chipsets are tying HPET and BCLK together. And the OS doesn't know to check ACPI to see if something went and changed the HPET frequency dynamically.
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)
Discussion Intel current and future Lakes & Rapids thread
Facebook
Twitter