Personal computing discussed
Moderators: renee, Flying Fox, morphine
derFunkenstein wrote:This is interesting to me because I'd always forced HPET to be enabled on all my systems in the past.
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.
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.
DerFunkenstein wrote:This is interesting to me because I'd always forced HPET to be enabled on all my systems in the past.
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.
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?
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.
[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[ 0.000000] hpet clockevent registered
[ 0.030907] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[ 0.212288] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[ 0.212288] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[ 0.220005] clocksource: Switched to clocksource hpet
[ 1.430085] tsc: Refined TSC clocksource calibration: 2998.261 MHz
[ 1.430098] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b37da91e36, max_idle_ns: 440795264323 ns
[ 2.440123] clocksource: Switched to clocksource tsc
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.
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).
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.
Mr Bill wrote:What system clock do extreme overclockers now have to use to submit a valid benchmark?
DrDominodog51 wrote:Windows 8 and Windows 10 have an issue with RTC time-drift on some platforms.
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.
DrDominodog51 wrote:As a result, most platforms and benchmarks cannot be run on either version of Windows.
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.
DragonDaddyBear wrote:What is really surprising is the difference in impact between AMD and Intel.
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.
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.
chuckula wrote:My Linux systems are defaulting to TSC even though they list HPET as being an "available" clock source.