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.
good discussion and good info.
for what it is worth. during my last sutter fest with 680 tri-sli and bf4. turning "off" HPET in bios did "slightly" reduce my stutter. perfoverlay.drawgraph was apparently smoother and my feel for reduce stutter was noticeable.
definitely not a placebo effect. turning HPET back "on" in bios. the increase stutter came right back.
so - unless someone can give a real normal everyday reason for keeping HPET on (please keep it in lamen terms). HPET can stay off permanently.
on i7 n win8.1 n bf4.
for what it is worth. during my last sutter fest with 680 tri-sli and bf4. turning "off" HPET in bios did "slightly" reduce my stutter. perfoverlay.drawgraph was apparently smoother and my feel for reduce stutter was noticeable.
definitely not a placebo effect. turning HPET back "on" in bios. the increase stutter came right back.
so - unless someone can give a real normal everyday reason for keeping HPET on (please keep it in lamen terms). HPET can stay off permanently.
on i7 n win8.1 n bf4.
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).
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 know this is an old thread but it helped me this week in May 2016.
I've used Juno.com for my email for over a decade and do not want to abandon my Juno account. For the last many months there has been a tremendous lag in any time I had my email pulled up. There are 3 video ads loading and/or running all the time. I have changed many OS and settings on my NVIDIA graphics which has 1Gb of ram trying to correct this lag to no avail.
Last resort is if I don't fix this this week I will change from Juno to Yahoo or Gmail.
(Hope a Juno admin sees this)
Just decided to see about my BIOS last week and realized I don't know what HPET is and I found this thread. After reading I disable the setting on my MSI G41M-P33 which is running 8G of DDR3 and Core2Quad.
The difference was amazing. I didn't notice anything else lagging before other than when I had Juno opened in a browser, but now email runs much better. Not perfect by a long shot, but the lag was cut by 75%. Sometimes I don't even have to wait to click on a message now.
I hope anyone else using Juno for their email disables HPET before abandoning their email account like I nearly did.
Thank you for all the info provided.
I've used Juno.com for my email for over a decade and do not want to abandon my Juno account. For the last many months there has been a tremendous lag in any time I had my email pulled up. There are 3 video ads loading and/or running all the time. I have changed many OS and settings on my NVIDIA graphics which has 1Gb of ram trying to correct this lag to no avail.
Last resort is if I don't fix this this week I will change from Juno to Yahoo or Gmail.
(Hope a Juno admin sees this)
Just decided to see about my BIOS last week and realized I don't know what HPET is and I found this thread. After reading I disable the setting on my MSI G41M-P33 which is running 8G of DDR3 and Core2Quad.
The difference was amazing. I didn't notice anything else lagging before other than when I had Juno opened in a browser, but now email runs much better. Not perfect by a long shot, but the lag was cut by 75%. Sometimes I don't even have to wait to click on a message now.
I hope anyone else using Juno for their email disables HPET before abandoning their email account like I nearly did.
Thank you for all the info provided.
Last edited:
William Gaatjes
Lifer
- May 11, 2008
- 21,538
- 1,271
- 126
Just read about it, if i can believe the wiki page, the HPET is a good idea for an event timer but badly implemented.
256 down counters with selectable prescalers and one shot or periodic interrupts would have been better.
https://en.wikipedia.org/wiki/High_Precision_Event_Timer
256 down counters with selectable prescalers and one shot or periodic interrupts would have been better.
https://en.wikipedia.org/wiki/High_Precision_Event_Timer
Adding my data point FWIW, back in 2014 when this thread was new and I read it first, I tried disabling HPET on my i5 2500k in Windows 7 and I didn't notice anything.
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.
Modern Windows versions will automatically use the best available combination of timers. This has been the case since Windows 7. No tweaking or changing boot settings required, just ensure that HPET is enabled in the bios, that's it, full stop.
Modern Windows versions will automatically use the best available combination of timers. This has been the case since Windows 7. No tweaking or changing boot settings required, just ensure that HPET is enabled in the bios, that's it, full stop.
Last edited:
+1. And I'm the OP of this thread
It shows up in Google search, which is why it is resurrected so frequently.
I'm going to post a response, even though this thread is so old, because I have some hard numbers for you. Depending on the system, enabling the HPET can have drastic consequences on performance. I don't know why it only affects certain motherboards (BIOS programming most likely), but I have never encountered issues with HPET until the past week, when it absolutely drove me crazy and I couldn't figure out what had gone wrong. Two videos for you:
With HPET (useplatformclock): https://www.youtube.com/watch?v=CXQ18hMRIO0
Without HPET: https://www.youtube.com/watch?v=r73Bky0i9so
The 'bad' results varied from as high as 65 fps average down to as low as 30 fps average. Yeah, that's a pretty insane drop, though it was with a GTX 1080. It also happened on other GPUs, though the effect wasn't necessarily as pronounced, but on a GTX 980 using the Low preset in FC Primal, I scored 65 fps average while a friend (Gordon Mah Ung at PC World) with a similar setup was getting 90 fps or so. Also, it can affect the Windows desktop:
Sluggish: https://www.youtube.com/watch?v=yKnVMB9H_SI
Normal: https://www.youtube.com/watch?v=Qa6dXyXsjlY
With HPET (useplatformclock): https://www.youtube.com/watch?v=CXQ18hMRIO0
Without HPET: https://www.youtube.com/watch?v=r73Bky0i9so
The 'bad' results varied from as high as 65 fps average down to as low as 30 fps average. Yeah, that's a pretty insane drop, though it was with a GTX 1080. It also happened on other GPUs, though the effect wasn't necessarily as pronounced, but on a GTX 980 using the Low preset in FC Primal, I scored 65 fps average while a friend (Gordon Mah Ung at PC World) with a similar setup was getting 90 fps or so. Also, it can affect the Windows desktop:
Sluggish: https://www.youtube.com/watch?v=yKnVMB9H_SI
Normal: https://www.youtube.com/watch?v=Qa6dXyXsjlY
Last edited:
@ 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.
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.
I suppose I should have noted that I had to enable useplatformclock in order to run the HWBOT x265 benchmark, which I was including as a CPU performance benchmark. The crazy thing is that apparently system restore does not revert changes to 'useplatformclock' so while I was testing, everything initially had useplatformclock off, but I would at some point turn it on so I could run the x265 benchmark. Often I would set it but continue benchmarking. Then I would at some point restart, and suddenly performance was noticeably worse.
This happened on two different motherboards, both Z170 chipset: Asus Z170A and Gigabyte GA-Z170X-Gaming G1. I cannot find an HPET setting on the Asus BIOS, but it might be in the Gigabyte BIOS -- it's not currently in a working PC so I can't check. Anyway, halfway through benchmarking, after a reboot, HPET would become active and if I did any additional tests, other than x265, performance would be lowered -- and drastically so on games.
On many other systems I've tested, useplatformclock does not appear to have an impact on performance. I assume it's probably an issue specifically with certain BIOS implementations, unless it's a general thing on Z170, but unless otherwise needed I would leave it off -- or at the very least, check performance before and after enabling it, with at least one graphics test included! CPU utilization with HPET enabled on the Asus board at least is significantly higher on many mundane tasks, like just scrolling a web browser window could hit 80% load on an i5-6600K. With HPET off, it's like 10-15% load.
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
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).
superstition
Platinum Member
- Feb 2, 2008
- 2,219
- 221
- 101
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.
I never noticed a difference. I figure 64bit os use 64 32bit os use 32. My motherboard is the same.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 19K
-
-
-
Facebook
Twitter