Helpful ReplyCore Parking

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

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.


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.

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.

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

HTH

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.

The comments on HPET may not even be enabled really have no bearing here and I am not sure why you brought these up.

I'm taking it you are talking to 'Goddard' here as I already explained why it has no bearing here.

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

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.

Chuffed?

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

well? no more debate??  thought so..

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?

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?

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'

Alegria


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?

LOL that was my head tech (Eric) and Scott Reams? lol not even close man only time i ever used dual personality was on FB for stupid games.. glad i am over that nonsense.
 
pretty sure no matter what name i posted under it would be VERY obviously its me..
 
dont strain your brain reading tech docs in an attempt to reply.. not worth the effort

"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.

jcschild

Alegria


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?

LOL that was my head tech (Eric) and Scott Reams? lol not even close man only time i ever used dual personality was on FB for stupid games.. glad i am over that nonsense.
 
pretty sure no matter what name i posted under it would be VERY obviously its me..
 
dont strain your brain reading tech docs in an attempt to reply.. not worth the effort

LOL

The funny thing is that same guy that makes all these baseless inferences about other people whilst crying when he gets called something as harsh as a smart alec, will be imposing his vast knowledge on unsuspecting new arrivals on this forum impressing everyone with the very things he has learned on this thread over the next few months.

Just watch.  It's all quite sad really.

I'm gonna skip the music making part from now on I'm going to dedicate my machine to running DPC latency checker so I can impress everyone with my single figure charts.  That DAW software just messes up the figures when you start using it.  I'm going to uninstall all my audio software it's a low latency DPC killer...

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).

What you will find, however many pages are put here or worse however many read-outs from DPC latency checker that anyone else insists on quoting, is that your audio performance will scale better under heavy loads and smaller buffer sizes with HPET disabled.

That is what we are after.  There are many benefits from employing HPET for various applications, high speed audio doesn't seem to be one of them.

There are all sorts of tests and utilities that make all this fun to look at in respect of pretty graphs and charts to fuel all manner of theories but it's when you load up your favourite DAW software with your current Audio driver to the point of stalling is where you'll show up the good stuff.

The improvements gained by having HPET disabled in BIOS though are marginal until you factor in the idea here that the biggest single gain we are making in all of this is by having 'Turbo' enabled, leaving on Core Parking and everything else that's come up in this thread including HPET is pretty much in support of making that work as efficiently as possible.

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.

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.

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.

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.

No, you got it wrong again, I worked with a vendor and their techie to arrive at a low price point box.  I wasn't the genius here.  It was just nice to hear the techie from a high spec DAW builder say exactly the same things.

My system works fine with HPET on btw, it just works better as a DAW environment making all them 1000's of transitions that are going on happen more consistently glitch free.  Having all that Core Parking, Turbo and stuff turned off already takes around 12% off your stock performance, getting it all working as smooth as possible is a free-gift before going near any clock-multiplier.

I could turn HPET on at any time and everything would be swell but I know that I'm going to give myself a few pops and clicks before they are really necessary during a production by doing that.

Try it yourself in a working environment if you get a bit of time in-between reading 'white papers'.

Turning HPET off is one part of the key to the reasons we don't have to worry about turning off Core Parking anymore post 1155 boards (or should I say post B3 revision chipsets...), period.

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

Jonbouy


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

Oh really, what pray tell are the other aspects? Or were you thinking of the ability to remotely disable a system ala stolen mobile phone remote "kill switch"?

After reading what Eric was reporting, the only aspect of IME which concerns me is the ability to disable it. Can this no longer be done? Used to be possible to "stop state" it so it didn't put any traffic on its interface buses (iirc, ctrl-p).

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. Although I find the ability to remote into systems comes in handy sometimes, especially with servers, am absolutely not a fan of anything that allows remote access which can't be turned off completely.

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

No, I don't know if the SB/IB consumer platforms (perhaps especially mobile ones) are using the IME/PCH for temp monitoring and fan control (which, if so, might help explain the spiking being seen). 

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

I never said or assumed anyone didn't know what they were talking about. If I think something which someone has said is wrong, I explain why. I simply don't think people, even those with a lot of empirical experience, should make blanket recommendations (such as, to turn off HPET) without giving an adequate explanation of why. 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).

You seemed pretty adamant in dismissing and downplaying any technical merits of HPET until I posited that perhaps you'd settled for a lesser performing system due to not being able to use HPET, whereupon you said that you could use it but chose not to. Seems to me Chuffington that you're only interested in learning what people have to say so long as it reinforces what you already think (or think you know).

I linked to technical explanations of why HPET is advantageous for audio, and also to several simple free utilities which can enable anyone to test and judge for themselves how HPET works. So nobody need take my word (or yours, or Scott's) for anything, they have the tools to see and decide for themselves on their own system if they care to do so.

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.

"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.
"
 
You might want to update your reading on this subject. I would recommend that you start here with the link below. VPro was started as separate Intel technology that used the IME. The IME was not designed for VPro by itself.
http://download.intel.com/technology/product/DCMI/DCMI-HI_1_0.pdf
 
So lets get this straight. We should spend countless hours convincing different manufacturers to adjust their drivers that effect less than 5% of the IT industry versus disabling HPET which resolves the matter immediately without further time and expenditure? Further we should ignore all testing/observations that show the HPET having negative impact on asio devices and asio engine in general. Asio has the capability to interrupt at a far faster interval than the HPET with WDM drivers and was around well before the HPET was even designed. No offence but I  would be out of a job and someone else would be posting here in my place if I followed that line of thinking. Scott is forgiving but I dont believe incompetance on my part will get me very far with him.
 
Eric
ADK

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?

"Jonbouy"
LOL

The funny thing is that same guy that makes all these baseless inferences about other people whilst crying when he gets called something as harsh as a smart alec, will be imposing his vast knowledge on unsuspecting new arrivals on this forum impressing everyone with the very things he has learned on this thread over the next few months.

Just watch. It's all quite sad really.

 I'm gonna skip the music making part from now on I'm going to dedicate my machine to running DPC latency checker so I can impress everyone with my single figure charts. That DAW software just messes up the figures when you start using it. I'm going to uninstall all my audio software it's a low latency DPC killer...

Great job in ignoring me bouy. And an even better job in making a complete fool of yourself.

"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.

Of course you won't see any benefit of having HPET disabled being as you are not even getting the up to 12% gain in stock performance from having turbo enabled.

You've already spent 3 pages of insisting that having core parking turned on is the way to go on your dedicated DAW remember?

There's absolutely no point in having HPET disabled when you've already nobbled your machine to that extent anyway... 

If you think I look a complete fool I'd suggest turning the mirror around.

Alegria



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...,
"

 
[size=4 font="times new roman"]What research? Please show me anywhere with data that shows the HPET increases performance with anything. I have seen the opposite every time with Pro Audio. Boards that were unusable for audio below a 256 Buffer could now handle a 64 Buffer with the same interfaces. Laptops by default do not have the option to disable HPET in the bios so that is something we still have to convince the manufacturer to do when needed. What I can say is when I have shown the systemboard engineers the DPC screen pics and the links to the programs we use to get those, the first bios I get back is the option to turn off the HPET. I wonder why that is?
 
BTW please dont look at White Papers from 2006 to 2008 and think the evolution of that technology ends there. How do you think they are implementing live bios changes to EFI bios's without using the IME/AMT. They are integral to those as well as updating Firmware level power management that comes with laptops on the keyboard firmware as well as system bios. The Intel Management Engine was actually introduced first on laptops in the Core2 days. Intel and the laptop manufacturers stated the IME driver used was modified and specific to the laptop manufacturers as they required. Intel creates guidelines with the IME and then allows the manufacturers to change as required. That is definitely how it's done currently as EFI bios features expand. Dont assume 1 white paper from years before the platform tells you exactly how that technology is implemented now.
 
Eric
ADK

ok now that we got all this technical crap posted and out of the way..

Fact: accross MULTIPLE motherboards from varied manufacturers, and with both socket 2011 and 1155
and every processor that can go into them..

HPET OFF = less DPC
HPET ON= more DPC, and in fact can be very detrimental with certain video cards.. also has much to do with PCI cards working particularly Lynx on P67

period end of discussion, on each and every combo.
unless someone here who has tested this accross mulitple platforms like we have and in the thousands of systems count..
time to put this to bed.

Core parking: please with this crap.. Sonar was and is the only software this ever effected (well ok Logic but that totally out of topic in this forum)
it was extremely user dependant and rarely did it ever fix anything for the majority of our clients or in our testing.
that was 2 yrs ago not now.. its long done and gone and over.

"jcschild"
ok now that we got all this technical crap posted and out of the way..

Fact: accross MULTIPLE motherboards from varied manufacturers, and with both socket 2011 and 1155
and every processor that can go into them..

HPET OFF = less DPC
HPET ON = more DPC, and in fact can be very detrimental with certain video cards.. also has much to do with PCI cards working particularly Lynx on P67 

period end of discussion, on each and every combo.

No, this is not the end of the discussion because you say so. And you certainly don't take into account all system configurations such as dedicated DAWS (audio only). HPET adds a minute amount of latency simply because it's an external clock. This is well documented and also applicable to LAPIC. But on the order of what magnitude? This is something that I can answer confidently. Can you?

such as dedicated DAWS (audio only)

Is there a definition for this?

What is a 'dedicated DAW (audio only)'?

HPET adds a minute amount of latency simply because it's an external clock. This is well documented and also applicable to LAPIC. But on the order of what magnitude?

 
 
There is a inherent increase in DPC activity just from the HPET. That latency fluctuates on average between 350us and 150us higher than it is when turned off. This also varies by board, platform, and desktop versus mobile because of further firmware implemented on mobile. Normally this activity is not enough to cause issues with audio accept at a buffer below 64 on most interfaces or 128 on some. The real problems are any spikes that increase the activity more then 350us and often those are hardware effected by the HPET. The boards that show these issues have spikes upwards of 21,000us often replicating every second to 5 seconds. Disabling the HPET reduces these either to sub 5000us or often eliminates them completely depending on the driver/bios. That is how much activity HPET is initiating with those devices while it's active. On those same boards, the DPC activity would also completely go away down to sub 20us if the C-States and Turbo was disabled. All of this is far more than the original DPC activity HPET initiated alone.
 
Eric
ADK

""And you certainly don't take into account all system configurations such as dedicated DAWS (audio only). ""

what the heck do you think i am talking about goober? for audio only. dpc is not much of an issue for video editing as its technically not real time processing. or any other uses.

DPC only matters for audio
the lower you set buffer for audio the closer you are to real time (system time)

again unless you have the database we do which i know you dont, subject closed.. feel free to debate with yourself no one trust me no one will be listening.

pretty sure i can guess as to who people will listen to.

Ah, I just found the definition of a dedicated DAW for professional Audio use.

They seem to have a wide range, I wonder if they come with HPET on or off.  I also wonder if they have core parking enabled.

http://adkproaudio.com/

ECBowen

HPET adds a minute amount of latency simply because it's an external clock. This is well documented and also applicable to LAPIC. But on the order of what magnitude?

 
 
There is a inherent increase in DPC activity just from the HPET. That latency fluctuates on average between 350us and 150us higher than it is when turned off. This also varies by board, platform, and desktop versus mobile because of further firmware implemented on mobile. Normally this activity is not enough to cause issues with audio accept at a buffer below 64 on most interfaces or 128 on some. The real problems are any spikes that increase the activity more then 350us and often those are hardware effected by the HPET. The boards that show these issues have spikes upwards of 21,000us often replicating every second to 5 seconds. Disabling the HPET reduces these either to sub 5000us or often eliminates them completely depending on the driver/bios. That is how much activity HPET is initiating with those devices while it's active. On those same boards, the DPC activity would also completely go away down to sub 20us if the C-States and Turbo was disabled. All of this is far more than the original DPC activity HPET initiated alone.
 
Eric
ADK

In plain terms it enables me to use a 48 sample buffer size on my interface whereas with HPET enabled I can't without that regular 5 second 'click'.

I normally have my buffer size set to 64 anyway but there are times I enjoy the slightly beter RTL.

Funnily enough HPET on or off doesn't affect my baseline background DPC latency at all it's when things start rolling that it shows up, which is why I'm always suspicious of those claiming they've got their baseline figure down to ridiculously low levels when nothing is happening.  I want to run my audio software without glitches not have a machine that's optimized to run DPC latency checker like some here enjoy doing.

Thanks for the insight on IME as well btw.  I've often wondered if there is any benefit from installing the IME software package for my board but it seems to install all manner of components so currently I just install the driver from that package to silence the 'unknown device' in device manage rather than install all the other stuff.  So is there any benefit to installing any of the other components or is just the HECI driver adequate?

"ECBowen"
There is a inherent increase in DPC activity just from the HPET. That latency fluctuates on average between 350us and 150us higher than it is when turned off.

In my case, it's no more than approx. 15us. Quite the discrepancy. 

"Jonbouy"
I want to run my audio software without glitches not have a machine that's optimized to run DPC latency checker like some here enjoy doing.

I run my audio software without glitches and HPET on. I actually run demanding libraries (24 bit) in real time with HPET on. And the ensued smoothness is..., well it needs to be experienced. But as I've mentioned before, this is not something you can do..., simply because of the nature of your multi-purpose machine and the insane amount of overhead created by the greenness of it. To each his own.

The "DPC latency checker" btw. is not a benchmarking tool but rather a diagnostic tool that display spikes in real time. Along with the "Latency Monitor" which goes many steps further in identifying processes that may be causing these spikes, they are tools to help you in this regard, no more no less.

Good day gentlemen. 

We normally just use the standard IME install for the specific model. We only change it to driver only if we run into a problem. Lately I have not seen issues with the installed IME. However the manufacturers dont include information on what is implemented with the install so you never know. The safest method is just manually update and select the driver.
 
Eric
ADK

In my case, it's no more than approx. 15us. Quite the discrepancy

 
Then you must have C-States and Turbo disabled. The numbers I gave were with Turbo active. I stated before you will get similar DPC activity with the current platforms with C-States and turbo off.
 
Eric
ADK

ECBowen


We normally just use the standard IME install for the specific model. We only change it to driver only if we run into a problem. Lately I have not seen issues with the installed IME. However the manufacturers dont include information on what is implemented with the install so you never know. The safest method is just manually update and select the driver.
 
Eric
ADK

Thanks Eric, much appreciated.

That's how I'm approaching it just now, I download the bundle unzip it and just point the update driver procedure to the location of the unzipped files.

I'd never had issues with it but wasn't sure if I was denying myself some benefit by not installing the entire package.

"ECBowen"
Then you must have C-States and Turbo disabled.

Of course, and then some..., and then some more. I don't even have my DVD drive on at all times, disabled in computer management along with "cdrom.sys" which is disabled with the help of SysInternals "Autoruns". And I could go on and on, but I think you get the idea.

"jcschild"
again unless you have the database we do which i know you dont, subject closed.. feel free to debate with yourself no one trust me no one will be listening.

pretty sure i can guess as to who people will listen to.

Again, you're missing the point Scott. HPET off is not a tweak and certainly not for everyone, it's a workaround at best (and I don't discourage its use, especially for laptop users for example). But for those who are really serious about a non-oc'ed, non-green, non-internet'ed no nonsense dedicated DAW for audio only, HPET on is my recommendation. And I certainly don't have any problems with people listening to whoever they want to listen to.

jcschild

Core parking: please with this crap.. Sonar was and is the only software this ever effected (well ok Logic but that totally out of topic in this forum)

 it was extremely user dependant and rarely did it ever fix anything for the majority of our clients or in our testing. that was 2 yrs ago not now.. its long done and gone and over.

That probably summarizes the OP's question as well as the rest of the 4 pages does.

Alegria

But as I've mentioned before, this is not something you can do..., simply because of the nature of your multi-purpose machine and the insane amount of overhead created by the greenness of it. To each his own.

Not to mention upwards of an extra .4Ghz on CPU speed without an O/C...

Nothing green about this machine except when it's not in use, not to mention the fact that I can collaborate on it without having to re-configure the thing from it's user crippled state in order to do so.

That probably wouldn't concern you though as usually you'd need freinds or colleagues in order to partake in a collaboration...

I never reach the point where I have to disable the network nor CD rom for that matter, if I did I probably will be due to upgrade.

Alegria

And I could go on and on, but I think you get the idea.

I got the idea ages ago, I think several others have by now too...

Alegria

But for those who are really serious about a non-oc'ed, non-green, non-internet'ed no nonsense dedicated DAW for audio only, HPET on is my recommendation.

So you are saying that Scott and Eric don't produce hardware for the serious dedicated DAW user?  And you are the serious one?

I'm not offering any recommendation but if you want to leverage the best low latency performance out of your machine and have it running at it's full potential, you'll likely find you are much better with it off.

Jon,
at this point youre feeding the troll..
while i normally like a good debate and dont usually mind Als err antics..
when one refutes an obscene amount of evidence to the contrary and yet still sticks to his errored thinking..
its time to dust off your shoes and move on.. <--- wonders if anyone will catch that and no its not from a movie

You are right of course Scott.

I just know how much damage these type of self-appointed 'experts' can cause.  Like I said earlier he will likely be employing every bit of knowledge gained here and passing it all off as his own 'genuis' further down the line.

It just made me gag this time and I've already engaged far more than I'd wanted to.

at this point youre feeding the troll..
 
Are you folks still discussing this?

Hilarious bull Jonbouy!

I installed a new motherboard on Wednesday, and am having various annoyances with the windows 8 partition.

Using the verifier, and some minidump readers, I find a bit about an HPET error. But I have hpet off in bios. So doing the searching this morning I find this:

[link=http://www.neowin.net/forum/topic/1075781-tweak-enable-hpet-in-bios-and-os-for-better-performance-and-fps/]http://www.neowin.net/for...r-performance-and-fps/[/link]

"tis about how windows must be forced to use ONLY hpet and performance is best. The dude claims it is the need for windows to sync hpet and the other timers that degrades performance.

j

and am having various annoyances with the windows 8 partition.

Windows 8 may well be another issue altogether with HPET.  I noticed somewhere that LAPIC has been dropped altogether so some changes have certainly been made.

What's the official release date on 8 now?  It must be pretty soon.

I'm likely to take your approach and put it on another partition for testing until I can get it performing as least as well as 7 currently is.  I'm not in a rush to migrate when stuff is already working great.  LOL I've only just relinquished my last little dependencies on XP so I'll probably put 8 on that partition now.

"jm24"
"tis about how windows must be forced to use ONLY hpet and performance is best. The dude claims it is the need for windows to sync hpet and the other timers that degrades performance.

There are many divergent opinions about HPET on the net..., and how it can be detrimental/beneficial in a multimedia context (audio/video). This thread confirms this without a doubt. There's a small utility I used during my testing that can quickly confirm which clock is in effect. You can find it here:

WinTimerTester 1.1

No installation needed and it is virus free as per my scans.

What you're looking for when using it is the "QueryPerformanceFrequency" value.

1] HPET ON in the bios & useplatformclock true = HPET = QPF of 14.31818 MHz (constant value)
2] HPET OFF in the bios & useplatformclock true = LAPICs = QPF of 3.57955 MH (constant value)

Any thing else is going to be  a combination of TSC + LAPICs or HPET.

that thread is just like this thread..

1 guy who thinks he has an answer and everyone else saying nope made it worse... hmmm.
not to mention its about gaming. there are tweaks i would do for gaming i would NOT do for audio/video..

last post in this 4 pages of useless thread..

Promise? 

I support windows comps for a bunch of small companies, organizations and individuals.

Got a mix of wXP, wV, w7, and soon to be w8. So am getting ready for what will come: new installs, upgrades, new hardware,....

On my music computer I have 3 partitions on the OS disk: w7-32, w7-64, and w8-64.


I have attempted to follow the various ideas/approaches in this thread.

The idea that drivers interfere with each other seems to be key to clarifying the differences experienced with the various tweaks used by us all. The linked thread interates the problem with stuff interacting.

Fur shur there are hundreds of thousands of processes happening when a computer is running. All kinds of stupid **** occurs because of the thousands of combinations of hardware and drivers. Very complex. Way underestimated by most people.

I want anything that is not of use to not be started/running.

New computers' speed can make many tweaks of the past irrelevant. 
And mask issues that only head-their-ugly-rears when least appreciated.

But I still do some tweaks just for grins.

The link has an interesting description of the need for HPET to be the lone timer.  

As usual some confuse startup speed with application performance.

No doubt the conflict caused by multiple timers is a clue for some annoyances.

j 

"jm24"
I want anything that is not of use to not be started/running.

It's nice to see that I'm not the only one thinking this way, even though we may have a different approach in accomplishing this. In the end, it's how you're satisfied with the performance of your machine and how it enhances your productivity without getting in the way, IMHO.