My old 680i refused to work with out HPET enabled that was the first time I used it..
Also never used any sleep or power saving on any board.
Also never used any sleep or power saving on any board.
Can we lock this necro? I'm assuming most of the stuff in this thread is out of date or are simply uniformed opinions which leads to misinformation being spread.
@ Jarred, so did you manually enable HPET to get that performance decrease? Or did Windows 10 enable it automatically for you?
Usually the later variants of Windows shouldn't use HPET, unless it's for certain programs that require it. Invariant TSC is the default option, as long as your CPU supports it.
core2 procs and older dont have built in timers, so hpet is the best choice there. core i3 i5 i7 have a better built in timer so windows uses that by default. obviously not everyones situation is the same.I hate to resurrect threads, but this thread is the number one hit on google for "Should I Enable HPET?". So, sorry sorry sorry... Also, Incoming Wall of Text Sorry sorry sorry sorry...
On to what can be gleaned from the Mighty Google.
Let's start with some terms.
PIT is Programmable Interval Timer. This is an old-school timer that can be set to generate an interrupt after a certain number of clocks. This device runs at about 1.2Mhz
HPET is High Precision Event Timer. This is a more advanced clock. It has features which include most of those in PIT, as well as requirements that it must support single event mode as well as periodic event mode. HPET devices support from 3 up to 256 different events simultaneously. Additionally, HPET is usually more than 10 times faster, at a minimum of 10Mhz
Both HPET and PIT require long-ish calls to read (meaning that the time from when you request to check the timer, to the time you get an response back can be quite long) and some implementations suffer from significant drift. A Vmware study apparently indicates this drift can be more than 800 parts per million.
TSC is Time Stamp Counter. This used to be commonly used back in the day as a way of measuring the clock rate of the CPU (against the system clock, like CMOS) to see how fast the CPU was. It's literally a register on the CPU that gets incremented every single clock cycle. Typically the time required to read the TSC is several clock cycles, depending on implementation. I've seen numbers quoted from 12-250 cycles. At modern clock rates, this is significantly shorter than the time it takes to read any of the other system clocks. On really old systems, the performance of certain software was directly based on time estimations made using the TSC.
The reason HPET exists is 2-fold.
First, there's a performance reason. HPET was implemented on low-frequency systems as a way to synchronize hi quality audio. If you think about what computers were like in 2005, most of them had single core processors and only single CPUs. Some of them were very very low performers overall (VIA processors anyone? Remember those?) On busy systems or systems with a low intrinsic clock rate, the HPET provided a steady timer source that could be used to synchronize that 44kHz audio properly.
Secondly, power management was young back then and multi-core CPUs were also very young. The TSC (time stamp counter) on most CPUs and multi-CPU systems suffered from being bound to the CPU's clock rate. So if your CPU had lowered it's power state, the TSC was also running slower. If your processed moved from one processor core or processor package in the system to another, they wouldn't be synchronized either. Early AMD multi-core processors with power management caused lots of trouble with earlier VMware version for just this reason (Virtual machine system clocks would literally run forward, then backward, then forward, playing havoc with time sensitive apps).
If your software depends on the TSC, and expected it to be constant (as early CPUs were, when it was even available) then they would behave unpredictably in these scenarios.
Today, Invariant TSC is common on almost every platform (and certainly all of the particularly relevant ones used for common OSes) and those where it isn't available, the developers will make allowances.
Sadly, all of this doesn't say anything about whether you should or shouldn't have it enabled, and it also doesn't really shine any light on the performance aspects (which is what i was hoping to find when I came here).
I never noticed a difference. I figure 64bit os use 64 32bit os use 32. My motherboard is the same.Is there a difference in terms of the performance hit between 64-bit and 32-bit HPET? I just looked in my Lynnfield machine's BIOS and there is an option to use 64-bit or 32-bit as well as turn it off. I've always had it set to 64-bit and on.