jcschild


Hpet:  in a nut shell so all can understand

You turn that off because it allows the C state changes to happen at a much faster interval. 

Um, perhaps you're confused? (Although, if C-state transitioning is going to be permitted, then faster C-state transitioning probably is desirable for performance anyway.)

The timing (duration) between evaluations of the Windows 7 PPM (processor power management) processor idle state (C-state) algorithm is set in a policy setting called "Processor Idle Time Check"at a value between 1 and  200,000 microseconds (us)). HPET being on or off doesn't change this value or the duration between C-state evaluations.


Transitioning between C-states (demotion/promotion) is based on thresholds of percentage of processor idleness set in other respective PPM policy settings. HPET being on or off does not change those settings.


See: http://msdn.microsoft.com...dows/hardware/gg566941

It also allows Drivers to interrupt the CPU every 1ms instead of 10 ms.

How is that? Which drivers?


HPET being enabled can result in a slight increase in  DPC latency, although this merely reflects that the system is performing more effectively (because of more precise timing), and should not negatively impact performance, but rather should enable enhanced performance (although it can also expose obsolete or poorly written timing routines in application and driver code).


Moreover, merely setting HPET to ON in the BIOS may not mean that the OS is actually even utilizing the HPET for performance/power management but may still be using instead the less precise default ACPI power management timer, especially if HPET was disabled in BIOS when Windows was installed. In order to ensure that the HPET is actually being utilized by the OS, it may be necessary to edit the bcd to set the value for "useplatformclock" to "true".


Unfortunately, even when HPET is utilized, Windows 7 may not be able to perform as well for audio streaming as Vista, since MS have removed performance settings in Windows 7 in favor of reducing power consumption. See for example MMCSS "Clock Rate" here: 
http://msdn.microsoft.com...684247%28VS.85%29.aspx

The PPM policy settings are set in the OS and updated via the Intel management engine. The HPET does effect the clock generation time period that any device, process, or service can interrupt the CPU for processing time. Where do you think the PPM or any Power management policies are outside of this since they are essentially part of the OS threading/interrupts through the HAL. Almost every device out there now including video cards, network adapters, combo controllers on laptops that include card reader controllers, USB controllers, Firewire controllers and storage controllers have power management features with the drivers/firmware. They are now able to interrupt as frequent as the clock generator allows them. The HPET clock generator allows interrupt cycles at a much lower interval which means these devices can interrupt for state change far more often. Whether you think theoretically this should not be the case or not does not change the observable results. When we have the HPET time enabled these devices are constantly interrupting the CPU likely for PPM policy requests. This is easily observable via DPC latency Timer or Latmon and is far more of a problem with Laptops which obviously have far more Power Management. This is how device manufacturers are implementing lower power consumption policies. When HPET can be disabled in the BIOS, many of these DPC issues go away or atleast spike far less frequently. Drivers from J-Micron, Nvidia, and Realtek are the most notorious for this.
 

C-States changes for some CPU state changes may be tied strictly to the time check value but not all of them. The Intel Management Engine is updating constantly from the C State changes and that is causing DPC spikes all over the place depending on the board’s implementation of the IME. If the board has the option to disable the HPET, then those DPC spikes disappear. So once again theoretical is different than implementation. You can also duplicate the same effect by disabling C-States and Turbo in the bios and leave the HPET on. Regardless of what you think, the C-State changes with the CPU are causing the DPC spikes via the HPET allowing the IME to interrupt far to often. This was once again the results of significant testing with latmon and boards that did not work well for audio as the bios was implemented at the time. I also never could get clear responses from the engineers for those boards as to why the IME was interrupting so often. Only the CPU state changes for Turbo would even use that kind of IME update frequency. The only verification I received from the engineers was they were looking at the IME.
 

The comments on HPET may not even be enabled really have no bearing here and I am not sure why you brought these up. Obviously HPET is supported in the OS at the time I am testing if I disable that and the DPC spikes go away. Obviously they are involved with C State changes even if it’s strictly tied to the IME updating if I disable C-States and Turbo and the spikes go away while the HPET is on.

I read all this thread and I don't feel any smarter. I thinkI will just go with set for best performance.
I am reading a Waverley by Sir Walter Scott, it isn't easy reading but it is easier reading than this thread. Maybe I r a dummy.

I follow this rule... if it ain't broke, I don't try to fix it (been there done that, never turns out good)... and it don't seem to be broke here.

Jon makes sense to me. I can understand, "hey, this works".

J

Chuffed?

OK I Googled HPET in BIOS? Maybe I will experiment with it on/off.
 
Thanks Jon!
 
Julien

Patience is a virtue my very childish pedawan. 


And I thought that using more than 1 alias was forbidden by the TOS? What say you Scott Reams?

slartabartfast

So to recap after the testing done when my machine was built (1155) it was decided the best option was to leave core parking, turbo, hyperthreading and speed step alone, and to turn off HPET in BIOS.

Just to be clear leaving something alone means leaving it enabled?

Indeed, it means leaving at it's default which may be enabled or disabled depending on the BIOS and OS.

So to clear Turbo, on, C-States. Speed Step and Hyperthreading enabled in BIOS.  In the OS default 'High Performance' power plan was then used as the basis of a new PP to further tweak stuff like USB, LAN etc. to prevent it going to sleep.

HPET in my case was the only thing that needed changing from all that stuff from it's default of 'On' to 'Off'

"jcschild"
LOL that was my head tech (Eric)

Ah... so ECBowen is your head tech. I like his style btw.

"jcschild"
dont strain your brain reading tech docs in an attempt to reply.. not worth the effort

I don't want to miss an opportunity to entertain. Besides, Eric made an impression on me (a positive one) even though I haven't seen any "before and after" DPC latency charts. It's important for me to make an effort in recognition of his, don't you think?

And I guarantee that I will provide you with some good material to make fun of.

Jonbouy

Moreover, merely setting HPET to ON in the BIOS may not mean that the OS is actually even utilizing the HPET for performance/power management but may still be using instead the less precise default ACPI power management timer, especially if HPET was disabled in BIOS when Windows was installed. In order to ensure that the HPET is actually being utilized by the OS, it may be necessary to edit the bcd to set the value for "useplatformclock" to "true".

Not entirely accurate, if 'useplatformclock' is not set via BCEDIT then if the HPET is on in the BIOS the OS has a choice between the TSC and HPET.  Disabling it BIOS and 'useplatformclock' not set will use LAPIC and TSC.  Setting "usepaltformclock" will merely enforc LAPIC with HPET disabled or HPET if it is enabled in the BIOS. 

Wrong. You've misconstrued (or misunderstood?) what I said (what you've quoted above).  


The timer selection for ACPI power management is done by the Win 7 HAL, and how it is done depends upon the ACPI version (which determines whether/how HPET is exposed to the OS during installation/boot by the ACPI BIOS).  Ideally (since ACPI ver. 3.0, ) the ACPI BIOS explicitly exposes whether HPET is available (ON/enabled)), and if so, then Win 7 will use HPET for power management timing, and otherwise, will use the lower precision PM timer. In earlier ACPI version BIOSes (and even in 3.0+), it is possible to instruct Win 7 (HAL) to implement HPET as the "platform" timer by setting HPET to ON/Enabled in the BIOS and setting the "/useplatformclock true"value in BCD (a similar "/usepmtimer" technique can be employed in boot.ini in earlier (pre-Vista) Windows versions to force the OS to use the PM timer instead of PIT.

The TSC on newer Intel chipsets is quick because the value is derived from the chips register rather than being read from memory it is likely that the near realtime operation required by Audio drivers will mostly use the register based TSC to directly hit the hardware, so if very low-latency is paramount then turn off HPET in the BIOS.  The HP in HPET doesn't mean High Performance remember it means High Precision. Also remember that driver writers are optimising for the hardware not the Windows API.

Using TSC for timing has been problematic for a number of reasons - because processors ran at different frequencies, the TSC could skew due to power management (if the processor clock was varied or duty-cycled, that would effect the count), and different cores/processors had different TSCs which were not aligned. Also, read operations could be handled in strange ways due to out-of-order execution. Although in the latest processors there is now finally an "invariant" TSC being implemented along with a serialized read command which should avoid such problems in future, it will be some time before code is rewritten to make use of this feature  So, in the meantime, the HPET would be employed for PM timing and other timing tasks, and although HPET uses memory mapped I/O addressing rather than on-processor registers, it is direct addressing (not indexed) so does not incur much overhead.


I know very well what HPET is, but I think you misunderstand. 


HPET used to be called "multimedia timer" and its purpose was to offer better timing precision for tasks such as audio streaming. You may find this informative:


http://msdn.microsoft.com...dows/hardware/gg463347


http://msdn.microsoft.com...2877%28v=vs.85%29.aspx


Heh! Audio drivers are only now being rewritten to implement techniques like MMCSS which have already been available for some time, so I wouldn't depend upon developers implementing TSC for timing any time soon. 


Rather, there seem to be a lot of current device drivers still employing obsolete or improper timing techniques (like just counting ticks and not accounting for timer frequency) which become exposed when the platform employs a higher precision timer like HPET.

As you rightly stated the C-states are indeed governed by the 'Processor Idle Time Check' whose duration won't change but the response time from the register based counter is quicker than the one being read from memory.

I don't really think response time is a problem when employing HPET, as there seems to be sufficient granularity available for processor power management operations. And even on-processor time/thermal power management employs some hysteresis (is not instantaneous) by design.


There does seem to be a misconception that HPET somehow makes "time" run faster, when all it does is provide higher resolution (granularity), so that smaller time intervals can be more reliably timed.

So if near realtime latency is a concern then disable HPET, if the driver writers have done their work well.

No, now you misunderstand again the purpose of HPET (and I think also the problem is that a lot of drivers have buggy timing code). 


But you can see and experiment for yourself using some simple free  utilities:


http://technet.microsoft..../sysinternals/bb897568
(run Clock Res in an elevated command prompt)

http://www.nvidia.com/obj...ction_performance.html

http://www.satsignal.eu/software/net.htm
(scroll down for PC Clock Timing - try the MM timer option on plotter page)


Also, fyi, in Prime 95 there are simple options to select which timer is employed (see the "undocumented" features).

ECBowen


The PPM policy settings are set in the OS and updated via the Intel management engine. 

"Intel Management Engine"? That's only a remote management and provisioning utility for business desktops, and while it does allow remote setting of a PM profile and setting in which sleep states the system can be remotely woken and what system events are logged/reported, it has nothing to do with actual power management. I take it you are using it for remote support, but don't understand why you think it is relevant here.

The HPET does effect the clock generation time period that any device, process, or service can interrupt the CPU for processing time. 

No, the HPET does not increase the speed of time passage or shorten intervals, it only increases the precision/granularity. There are ways to shorten the platform clock/PM timer period duration (from 15.6ms or 10ms  to 1ms), but just employing the HPET instead of the lower precision PM timer does not automatically do that. 


If you are seeing shorter time durations under HPET, then it is because timing code in some driver or application is invoking a shorter clock duration or doing its timing improperly. You might be able to see this for yourself. I linked to some utility programs in my reply to jonbuoy above which show the available counters and time durations.

Where do you think the PPM or any Power management policies are outside of this since they are essentially part of the OS threading/interrupts through the HAL. Almost every device out there now including video cards, network adapters, combo controllers on laptops that include card reader controllers, USB controllers, Firewire controllers and storage controllers have power management features with the drivers/firmware. They are now able to interrupt as frequent as the clock generator allows them.

Again, the interrupt timing interval a driver uses does not depend upon HPET, but on what interval the driver sets. Even when HPET is used, the timing interval can (should) still be the same (for example, 10 or 15.6 ms) as when using the lower-precision PM timer, unless something else invokes a lower duration/period or else the timer count is not being evaluated with regard to the counter frequency.

 The HPET clock generator allows interrupt cycles at a much lower interval which means these devices can interrupt for state change far more often. 

The "much lower interval" is not due to HPET but to drivers' interrupt timing routines being improperly coded. Maybe the driver code improperly fails to account for the timer frequency. Or maybe another driver invoked the shorter duration for its own use and then improperly failed to restore the "normal" longer duration when exiting. HPET is not really the cause of these problems, but only exposes their symptoms.

Whether you think theoretically this should not be the case or not does not change the observable results. When we have the HPET time enabled these devices are constantly interrupting the CPU likely for PPM policy requests. This is easily observable via DPC latency Timer or Latmon and is far more of a problem with Laptops which obviously have far more Power Management. This is how device manufacturers are implementing lower power consumption policies. When HPET can be disabled in the BIOS, many of these DPC issues go away or atleast spike far less frequently. Drivers from J-Micron, Nvidia, and Realtek are the most notorious for this.
 

First of all, the OP is using a laptop on AC power, and wants performance, not power saving. And while I agree (and sympathize) with you that the power saving oriented power management policy does raise some performance challenges, especially with mobile platforms, you (and your boss) need to realize that while turning off HPET may avoid what you observe as being caused by HPET, what you are observing is realy being caused by crappy drivers with poorly implemented timing routines which get exposed by HPET (so, as a PC vendor, why don't you guys do something about that?), and that by turning off HPET you are actually lowering the potential platform performance for streaming audio, MIDI, etc.

C-States changes for some CPU state changes may be tied strictly to the time check value but not all of them. The Intel Management Engine is updating constantly from the C State changes and that is causing DPC spikes all over the place depending on the board’s implementation of the IME. If the board has the option to disable the HPET, then those DPC spikes disappear. 

If the "Intel Management Engine" is causing spikes, then disable it instead. Nobody needs IME for a DAW, but HPET is very advantageous for audio.

So once again theoretical is different than implementation. You can also duplicate the same effect by disabling C-States and Turbo in the bios and leave the HPET on. Regardless of what you think, the C-State changes with the CPU are causing the DPC spikes via the HPET allowing the IME to interrupt far to often. This was once again the results of significant testing with latmon and boards that did not work well for audio as the bios was implemented at the time. 

As said. why not just turn off IME? Your customers only need to enable it when they need you to remote into their systems for support.

I also never could get clear responses from the engineers for those boards as to why the IME was interrupting so often. Only the CPU state changes for Turbo would even use that kind of IME update frequency. The only verification I received from the engineers was they were looking at the IME.

Maybe it's buggy MEI firmware (it's happened), or maybe over-aggressive event logging (but then, what what do i know?). 

The comments on HPET may not even be enabled really have no bearing here and I am not sure why you brought these up. Obviously HPET is supported in the OS at the time I am testing if I disable that and the DPC spikes go away. Obviously they are involved with C State changes even if it’s strictly tied to the IME updating if I disable C-States and Turbo and the spikes go away while the HPET is on.

I already responded to jonbuoy about this.


Do you even know what the BIOSes in your systems actually support? Hint: try biosbits.

jcschild


well? no more debate??  thought so..

Had to deal with a spell of inclement weather.


Free tip: best not be too eager to hand someone else their butt, lest you end up showing yours instead.

btw Goddard, thanks for the lecture on AMT, but that's only one aspect of Intel's ME.

I'm running SB Xeon platform with discrete (off-core) graphics, not a consumer SB platform with IGP, so will admit ignorance on that aspect.

I'm aware of the remote management capabilities provided by AMT and like yourself ignorant of the local management stuff that is part of IME, but when a tech is telling me something in relation to whether HPET is enabled or not then I figure he knows something we don't.

I'm interested to learn what that is rather than assume the guy doesn't know what he's talking about like you seemed keen to do.

The bottom line for me is still this:

http://forum.cakewalk.com/fb.ashx?m=2650837

I see. So anyone who doesn't agree with you doesn't know what they are talking about.

Where on earth did I say that?  Don't put words in my mouth fella.

btw I already gave the explanation of why HPET off helps when turbo is enabled.  Actually I even think Wikipedia of all places does too.

This may help you understand the issue with it though when operating at near realtime...

http://git.kernel.org/?p=...04d421b103a89f7becf47c

Here's a much simpler test for the average DAW user to try out.  If you have a project that's just about on the edge as far as pops and clicks go on your setup, try a reboot and disable the HPET, yippee it works swell again.

You don't need to wade through a load of technical bumph or get hypnotised by a load of tests you can do it in a practical environment, the techs have worked it out for us mere mortals.  Good for them I say.

Goddard

Jonbouy


So to recap after the testing done when my machine was built (1155) it was decided the best option was to leave core parking, turbo, hyperthreading and speed step alone, and to turn off HPET in BIOS.

Now I'm not a particularly technical guy but that yeilded the best results for me for Audio Performance and would you look at all the science that's been quoted mean-time and it looks like I pretty much figured it out by looking at the figures I was getting.

I'm quite chuffed about that really as it's an encouragement to go along with the actuals that I see rather than the conflicting theories I hear.

Hold on there, Chuffington. Before you go on patting yourself on the back, consider that you are still settling for a lower performance level than your system and software should be capable of providing. So, adequate to your requirements, okay, how nice for you, but don't think that makes you a genius. Maybe you just got sold a lower performance system because your DAW vendor (and/or their suppliers) couldn't be bothered to make their wares work properly with HPET on.

Please show what data and evidence you have to support this position. I have tested systems with HPET on and they have shown zero, absolutely zero performance gain with Pro Audio applications or Videoediting applications. The testing however has shown considerable performance gain at low latency with Asio with HPET off. Please enlighten all of us where this stance is supported in any way or is this conjecture based on what you are reading about the HPET?

"Goddard"
I'm not ready to take anyone's word for anything without some technically grounded reason being given (so that people can have a reasonable basis to judge for themselves).

Just because Scott says to turn HPET off, and you say your system runs better with HPET off, that to me is far from sufficient reason upon which to conclude without some technical basis, especially if I can get better performance by using HPET (and understand the technical basis for why that is so).

My thoughts exactly and the reason why I did not agree with Scott to begin with. Also, the recent research I've done on this subject simply confirms it without a doubt. HPET OFF is not a tweak nor is it a "one size fits-all" fix for systems having trouble with a high precision external clock. And as mentioned by Goddard...,

"Goddard"
First of all, the OP is using a laptop on AC power, and wants performance, not power saving. And while I agree (and sympathize) with you that the power saving oriented power management policy does raise some performance challenges, especially with mobile platforms, you (and your boss) need to realize that while turning off HPET may avoid what you observe as being caused by HPET, what you are observing is realy being caused by crappy drivers with poorly implemented timing routines which get exposed by HPET (so, as a PC vendor, why don't you guys do something about that?), and that by turning off HPET you are actually lowering the potential platform performance for streaming audio, MIDI, etc.