An Observation with DPC Latency Checker

So for giggles, I was running DPC Lat on Win 7 DAW.
 
With nothing running I was getting ambient latency of ~150 microsecs and the occasional spike at 300-350.
With Sonar or iTunes running I was getting the same sort of latency.
 
However, if I left DPC Latency Checker on when shutting down Sonar or iTunes (i.e. nothing running again) my latecy would spike to 14,000 microsecs (big ugly tall red bars.)  If I fired up the software again, the latency went back down to prior levels.  If I opened up the audio interface utility, the latency would go back down to prior levels.
 
Anybody seen this before?  It is not contributing to a performance issue, but it seems really strange that the latency would sky rocket when exiting audio software.

I've noticed it and always assumed it was a bug with the latency checker.  Just restarting the latency checker is unlikely to change actual DPC latency.

Sycraft
The DPC latency checker program isn't really a very good program at what it does. Better to have a look at LatencyMon. More complex and reports on more things, but far more accurate and useful. Also works right in Windows 8.

 
The DPC Latency Checker doesn't give any information about what is specifically causing high DPC Latency, but it is accurate under Win7x64.
 
The OP's DPC Latency can be reduced by changing settings in the BIOS.
 
Also, the OP should check to see if anything significant is running in the background (like backup software scheduling services, etc).

Just to note, I am not experiencing any issues.  I thought it was odd that when running Sonar (and prior to running any software) latency was in the 180 microsec range, but when Sonar was stopped (or iTunes for that matter) latency spiked.  When I fired up Sonar again it returned to the low levels.
 
Again, I don't experience any issues when running Sonar, so I am inclined not to change anything, but I observed something strange (to me) and wanted to report it.

It's to bad the DPCLAT latency monitor doesn't work in Windows 8. You see that it gives a false reading of 1,000 ms steady. 
 I have always kept it on my desktop. I would randomly check whats going on. For my live performance XP laptop it was indispensable as it would tell me it's time to clean things up or remind me I left the battery managment or wireless on. 
 
I too like fireberd have yet to totally decipher Latency Monitor. I am using it on my new W8.1 DAW now. That Hard Paging bar graph just keeps growing as time goes by, but it still tells me everything is OK. I think the other bars are telling me I'm under 100ms so all seems fine. 
 
 
An interesting ( to some?)  note on running DPCLAT latency checker. As an experiment once I thought I'd run it as I re installed a fresh OS and software. This was a 2004 Acer Laptop. 
The first thing I did once Windows XP 32 bit booted was run the DPCLAT.  
Processes running 23. 
It was under 50ms and steady. 
OK, installed the chipset, wi Lan, Lan and video drivers. Hmm, up to 400ms? 
Disabled battery management, back to 100ms 
Disable Wi Fi back to 50 ms. 
Note nothing else was changed from windows default install. 
Processes running 26
As I continued to install software I'd leave it running and start it again after re boots
Lots of red and orange Spikes now but of course that's normal when ever you use the CPU. 
But when idle it stayed steady at 50-80 ms. 
Here's the weird one and if you dig way back in the hardware forum you'll see my screen shots. 
 
Installed my Tascam us1641 drivers and now we are up around 200 ms?? 
Turn off the Tascam back to 50ms? 
What was interesting is this was the behavior on all XP computers. On windows 7 64 bit it only would go up about 20-40 ms. 
 
So to the OP, you can expect a change in the DPCLAT readings as you open and close programs. This is why it's a good idea to test your DPC latency while running your DAW. 

One-time or short-term spikes are nothing to be concerned about, just as one-time CPU or paging spikes are not an indication of a problem.
 
As a program starts up or shuts down, it's likely performing some time-consuming task that's temporarily preventing other deferred procedures from executing, resulting in a short-term latency spike.
 
What you're interested in is the average latency while SONAR is running, and any periodic (recurring) spikes that might be caused by some non-audio interface activity such as a wireless network adapter continually broadcasting its presence.

Elffin
Cpu throtolling? ive had a look at bios and my uguru setting and the cpu clock speed is set at default speed.. still get these messages using both latmon and dpc checker.

I'm I missing something??

There are numerous settings in the BIOS that affect CPU throttling.  
 
Note:
Some pre-configured machines have motherboards with very few BIOS parameters exposed to end-users.
This is done to keep less savvy users from fouling up their machine.  Of course, if the parameters aren't exposed, you won't be able to disable them.

That's right Dave,  I've never been to concerned with spikes that happen when I'm opening and closing other apps, Things seem to work fine as long as all is in the low green when idle etc.
And yes Jim it was determined that Tascam's drivers were terrible. That's why I switched to a Focusrite. But now I suffer from pre amp issues. The Tascam had much better pre's. Hopefully the new line up has improved on the driver side. Craig seems optimistic.  We are talking budget interfaces anyhow so I really don't expect top shelf performance form any of them. I know what a good interface is but I just can't afford that right now. My system is working with no DPCLT issues. I don't use the laptop anymore and would never buy one for recording anyhow.