ECBowen


"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

Hi Eric, back now from paying some bills.  

Ah, ok, I understand now to what you were referring regarding the "Intel Management Engine", in respect of the firmware embedded controller functionality in the PCH. IOW, I assume you were referring to activity of the "meci" driver (formerly the "heci") driver? I knew that Intel had expanded the capabilties/functionality of their embedded controller from its earlier southbridge incarnation in the newer PCHs.

I am at somewhat of a loss here, in that I am not using a current laptop running Windows 7 (for audio, a Macbook just works, gave up on the crappy crippled BIOSes in PC laptops years ago) and the SB/IB DAWs here are on Supermicro and Intel mobo's with discrete embedded controllers (Nuvoton chips) and not the IME/MECI, so maybe I missed seeing what you were referring to. I only checked out an HTPC desktop box in a shop, not a laptop or a fully loaded DAW, and only ran Latency Monitor, not any other diagnostics.

However, I did not see where IME/MECI was updating anything except for the telemetry on temp, fan speed, etc. although it may have also been originating PMEs/SMIs which I was not in a position to check for.


Look, I wasn't disputing what you were witnessing wrt what you said about seeing increased DPC latency and more  frequent interrupts. But I am still seriously questioning whether that is down to the HPET (which when enabled does not in any way change the system interrupt interval, as may be confirmed with the timer utilities to which I had linked previously).

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? 

No, what I am saying is that, were I in your position as a system vendor/integrator, I might look further into why the effects you are witnessing are occurring when HPET (which has been a Windows hardware logo/certification requirement for years now) is enabled, rather than simply disabling it and recommending that everyone else do so also.

Have you even bothered testing with the /useplatformclock switch, or do you still not understand why I had mentioned it earlier?

Have you run powercfg with the -energy parameter to investigate what was going on? 

Have you tried stopping IME from loading, to see what happened?

Or maybe run xperf or process explorer? Or checked the BIOS out with biosbits? 

I mean, I just build and use my own DAWs, but have long tested and troubleshot them with the tools I have available. Now, if I were in the PC biz and was seeing anomalous behavior as you have with HPET enabled, I think I'd investigate, and if I couldn't find out why, maybe send a system to MS and have them investigate why. I'm fairly certain MS do care enough about 5% of their market to find out why hardware they are requiring in all Windows systems is causing performance problems and do something to rectify the situation.

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. 

I think what you appear to be saying in regard to ASIO, which uses the legacy Windows MM Timer (now obsolete and deprecated), is that it does cause the system timer resolution to be increased to 1ms, having the effect of globally decreasing the system interrupt interval to 1ms (from the usual 10 or 15.6ms), causing all other interrupt/timer intervals to occur/expire faster and thus putting a greater load on the cpu and impacting overall system responsiveness. If so, yes, this has been well known for years.

[EDIT: Hmm, maybe that didn't come out the way I'd intended. I did not mean to knock ASIO per se (it was a real boon to PC-based audio back when and still remains so, and I doubt MS would have ever bothered to implement KS without Steinberg having shown the way with ASIO), but only meant to point out that ASIO has not been kept updated in line with developments in the PC platform and Windows kernel. As for why you are seeing deleterious effects manifested with ASIO when HPET is enabled, well that's a good question and one which I, were I in your position, would be asking of MS and Steinberg (and Intel as well as the interface makers whose Windows ASIO drivers are being affected).]

As for  ASIO, the problem I (and many others) have is with MIDI syncing (or rather, not syncing) with audio and even with itself, due to timestamping respectively using different system clocks. Steinberg and Cakewalk (and RME and other s/w and h/w mfrs) are well aware of these problems, which have gone on for years without being resolved on the PC platform (and have probably accounted for a lot of MIDI musicians moving to Macs). ASIO 2.0 is still using TimeGetTime calls to the MM timer for timing and is rather low precision today, and hasn't really improved since the 95/98 days of ASIO 1.0. And MS haven't helped in this regard either, what with dropping/ screwing up support for MIDI in Vista and putting in worse performing emulation.

[EDIT: That didn't come out entirely right either. I meant to say that ASIO driver implementations (ok, certainly not all, but perhaps many) have not been updated in line with platform/OS developments, and still carry legacy baggage in the way they are implemented. That is hardly all down to Steinberg, as there were some rather advanced and forward-looking implementation options (e.g. single buffering, event notification, prefetch, DMA, etc.) made available to ASIO developers in anticipation of pre-emptive multi-tasking on multiprocessor systems and asynchronous processing becoming the norm (and well before MS implemented its wavert driver model at that). But still, although timestamping with nanosecond resolution and timed buffer switch call interrupts are fine, referencing a system timer with a resolution of 1ms (and which timer impacts upon system performance) while it might have been of practical necessity back when should really imo have been updated in view of platform changes.]

HPET offers some significant advantages over the Win MM timer wrt reducing DPC latency and system loading if event-based notification routines are employed. Maybe ASIO 3.0...

Now, please be so kind as to try setting HPET to enabled and set /useplatformclock and try a WDM-KS MIDI driver. And maybe a WDM audio driver too. Better now?

 
I've tried it.  It doesn't work as well disabling HPET for ASIO at least, and my interface just sucks under WDM.
 
I've also tried bypassing IME and various other combinations.
 
HPET does indeed provide benefits for timing and no doubt at some point everything else will catch up to that fact, but with what we are using today, enabling Turbo and disabling HPET in order to get maximum low-latency ASIO performance as of now certainly yeilds the best results I've managed to produce.
 
The issue is compounded by the fact the consumer led drivers for video and networking, etc. take advantage of HPET to overly 'pester' the CPU for green reasons, turning off HPET also moderates this clamour for interrupts.
 
Kudos due though at least YOU seem to be aware of what the issues actually are.
 
It's all compromise basically because a dedicated DAW in it's true sense doesn't exist, and what may be the best compromise today will not be the best in 12 months, much like the Core Parking issue that was posed in the OP, that will mitigate the timing issue but at over 10% of the cost of your processing power.

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. 

Ok, this agrees basically with what I have seen, slightly higher DPC latency with HPET enabled, but not really excessive and not problematic. Disabling some graphics features (especially DWM) seems to reduce this activity, particularly with nVidia cards.

The real problems are any spikes that increase the activity more then 350us and often those are hardware effected by the HPET.

Can you be more specific? Exactly what hardware is being affected by HPET? I take it you are referring to drivers, in which case I ask, which drivers? Is this the "MECI" driver?

 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. 

Again, I presume were you seeing these spikes from drivers, and if so, I ask which drivers specifically? Did you attempt to disable these drivers to isolate the cause of the spiking with HPET enabled?

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.
 

If I am understanding you correctly, disabling C-state transitioning and turbo boost reduced DPC latency?

Jonbouy


Windows 7, Turbo enabled, HPET disabled test project running for 12 hours at 32 buffers.  Maximum DPC latency spike overnight 438us.

Same test project, same test settings HPET enabled.  Would not run at 32 buffers, minor crackling at 48 so run at 64 buffers.  Maximum DPC spike 2,600 + us after 45 minutes.  Retested 2308 us reported again after a few minutes, final try also ended in me not bothering further.

Which would you choose?

32 buffers on the Quad comes out at 3.52 ms @44,100k RTL measured by Centrance over USB 2, 5.1 ms reported in Sonar.

Who said the Quad wasn't low latency?...

I think Vin (DAWBench) did, over in another forum, in reference to the Octa under review in yet another forum. Big brouhaha that was...


But really Chuffington, you must be right chuffed with a 32 buffer. I'm rather amazed, seeing as how Roland only advertise a 48 sample minimum for the Quad/Octa VS stream ASIO drivers, and most folks seem to need 64 or higher.

Chuffington...lol I even quite like that.
 
The midi is fine enough, if I was really picky though I'd be using a dedicated clock outboard and sync everything with that.  I'm only using one in port which is handled by the stock windows driver so I don't use the Quad's facility. 
 
And yes the spec for the Quad is 48 buffers, just goes to show what can happens with a bit of judicious tweaking to get the best out of your setup.
 
The interesting thing is that with the 1.5 driver as opposed to the initial release driver there is a switch which is supposedly to reduce CPU usage, with HPET turned off the background DPC figure actually increases by around 150 micro seconds but enables the 32 buffers, the DPC stays constant and perfectly usable even though it looks high at around 230us overall.
 
With HPET turned on the background DPC stays lower on average but peaks every few seconds and sometimes beyond the threshold of acceptable.
 
I think there must be some kind of pre-allocation going on with what Roland call VS streaming but whatever it is in practice I could run a few instances of a major sampling package, a big drum sampler whilst being Rewired without getting any sign of glitching @32 buffers.
 
I tend to run it 64 samples and do everything set that way though sometimes I'll use the 32 sample capability for a bit of tracking monitoring through the app.

This doesn't work with any set up that differs from the one described here with HPET off and turbo on.

So what should I be changing?
 
If I leave HPET on the audio still works but not under any load at all, and midi craps out as soon as you move a mod wheel or bend pitch, HPET off midi is fine, audio is fine and under reasonable loads.
 
Simple as that.

"Goddard"
Well documented where?

One of many articles I reviewed is found here:

Performance by Design

"Goddard"
And no, it does not add any significant latency (very low overhead).

I agree and as previously stated...,

"Alegria"
In my case, it's no more than approx. 15us.

So what's your peak DPC over a 12 period with your ASIO driver running @32 samples under load?  How often do those peaks occur? What's your RTL figure with that?
 
As I keep saying which you would construe as an OT personal attack is that having a really low DPC figure, it's meaningless on its own.
 
Perhaps also you can explain where the performance of my machine WRT to audio production is lacking compared to your proudly declared 'Dedicated' one which we already know is underperforming currently by around 12%.

I'm just using an M-Audio keyboard via USB with the standard Windows driver.  I am using the Octa's midi out for a vintage module.  I also use a fair bit of Virtual Midi routing ITB using loopMidi.
 
I'll get the figures from Aud.ini later only I'm not on my DAW partition just now.
Here ya go.
 
UseHardwareSamplePosition=1
 
Queue buffers are at default of 2