The No.1 Website for Pro Audio
What is your DPC Latency?
Old 14th January 2015
  #61
Gear Addict
 
Pollo's Avatar
 

Bringing an old thread back to life. It's almost one year since my last post.
Within that time I now moved from Window XP (32 bit) to Windows 7 (64 bit).
I am still using the same hardware I had a year ago. A short while ago I made great progress in the performance of my system, simply by updating my BIOS and other drivers. However, I still don't trust the performance of my system 100%.

As I'm writing this my computer is playing back audio via an ASIO application with a buffer size of 48 samples. There are no noticable glitches, apart from when I started my web browser, at which time I think I heard what could have been a crackle. So that is probably pretty good?

But, if I am to believe DPC Latency Checker and LatencyMon, my system is still having problems with real time audio. There are occasional DPC latency spikes.
I would like to get rid of them completely but I am out of options what to do.
I am starting to think it's impossible with Windows 7.

Reading through this thread and reading the low latency figures people were having 6 years ago makes me wonder. I remember that too when I was still on XP and one hardware generation earlier. My latency on an idle system was 5 -7us. Spikes above 1000 us did not occur. Never. No matter how much stress I put on my system.
Now my idle latency is about 22us, after much tweaking. I can't playback a Reaper project without having at least one DPC spike, which, if I'm very lucky, stays below 1000 us. Many times it doesn't, causing the two afore-mentioned programs to flag my system as suspect.

Maybe I shouldn't worry about it. The system seems quite usuable. I am just worried that one of those DPC spikes ruins a perfect recording.
So what is your experience with Windows 7 (64 bit). Did anybody manage to tweak it such that DPCLat and LatencyMon are happy?
Old 15th January 2015
  #62
Lives for gear
 

If this helps any, Windows 7 (64 bit), Intel 3770K CPU, Asus P8Z68-V LX motherboard, I use the onboard graphics, it's overclocked, lean and mean DAW only rig. Each guy is going to have a different configuration so it's just a matter of tuning up whatever you have.

--------------------------------------------------------------

DPC Latency Checker v1.30 app ----- Current Latency: 2us to 5us mostly shifting between 2us and 3us. Absolute Maximum: 14us which happens when you start the app running, if you hit the reset button and let run for a while then Maximum is 7us.

---------------------------------------------------------------

Latency Mon (Home Edition) v6.0 -----

Current Measured Interupt to Process Latency: 28us to 33us average
Highest Measured Interupt to Process Latency: 44.17us
Highest Reported ISR Routine Execution Time: 13.28us
Highest Reported DPC Routine Execution Time: 18.90us

In Depth Tight Loop Tests /
- High Level IRQL: One Core 1.15us, other 7 Cores 0.86us
- Clock Level IRQL: One Core 1.15us, other 7 Cores 0.86us
- Dispatch Level: CPU#0 14.06us, other 7 cores 1.43us

-----------------------------------------------------------------

One thing that helped get me from a 15us average to 3us average with the DPC Latency Checker app was turning off the "High Precision Timer" in the Bios (it might be listed as HPET in your bios). Given that parameter is used for video and DAW only rigs are not using 3D video like game rigs I've seen no adverse effects from disabling it.
Old 16th January 2015
  #63
Gear Addict
 
Pollo's Avatar
 

I already have HPET disabled in my BIOS and it lowered the dpc latency by maybe 20 us. But still I'm nowhere near your numbers.

Also I disabled EIST which made a huge difference. I have no tray applications running, except for the Eject media and internet access thingies.
I disabled as much services as I could. I created a script that further disables some services that I don't need when working with my DAW.

While I'm writing this I kept DPC Latency Checker and LatencyMon running. My numbers are:

DPCLat v1.30

Current latency: 45 - 55 us
Absolute Maximum: 122 us

LatencyMon v6.0

Current Measured Interupt to Process Latency: 33us to 37us average
Highest Measured Interupt to Process Latency: 163.52 us
Highest Reported ISR Routine Execution Time: 64.61us
Highest Reported DPC Routine Execution Time: 74.17us


I noticed that DPC Latency Checker is more positive than LatencyMon about my system. I also noticed that all interrupts are being handled by one CPU (I have 4 cores). I thought that was normal but I've seen other reports where this is not the case. Does this have to do with the type of processor (it's a Haswell i5) or are there ways to configure this? I couldn't find any useful information about that topic with Google.

Final check of LatencyMon. Highest Measured Interupt to Process Latency is now 536.31 us! I'm not doing anything. Why is this happening?
Old 16th January 2015
  #64
Lives for gear
 
gravyface's Avatar
Quote:
Originally Posted by Pollo View Post
I already have HPET disabled in my BIOS and it lowered the dpc latency by maybe 20 us. But still I'm nowhere near your numbers.

Also I disabled EIST which made a huge difference. I have no tray applications running, except for the Eject media and internet access thingies.
I disabled as much services as I could. I created a script that further disables some services that I don't need when working with my DAW.

While I'm writing this I kept DPC Latency Checker and LatencyMon running. My numbers are:

DPCLat v1.30

Current latency: 45 - 55 us
Absolute Maximum: 122 us

LatencyMon v6.0

Current Measured Interupt to Process Latency: 33us to 37us average
Highest Measured Interupt to Process Latency: 163.52 us
Highest Reported ISR Routine Execution Time: 64.61us
Highest Reported DPC Routine Execution Time: 74.17us


I noticed that DPC Latency Checker is more positive than LatencyMon about my system. I also noticed that all interrupts are being handled by one CPU (I have 4 cores). I thought that was normal but I've seen other reports where this is not the case. Does this have to do with the type of processor (it's a Haswell i5) or are there ways to configure this? I couldn't find any useful information about that topic with Google.

Final check of LatencyMon. Highest Measured Interupt to Process Latency is now 536.31 us! I'm not doing anything. Why is this happening?
What are the hardware specs on your machine?
Old 16th January 2015
  #65
Lives for gear
 

Pollo, since you have this box hooked up to the net . . . what happens when you disconnect it from the net (pull the ethernet cable out), turn off it's antivirus app, and in the bios turn off it's network card (often a parameter to load the Network/NIC rom), and re-run the latency apps? If that helps you can easily turn that stuff back when you need to go online. What about hyperthreading, do you have it with your CPU and is it turned on?

By listing your full configuration it may point out other things to check, a common high latency culprit is a video card driver (nVidia seemed to be the worst for hogging the CPU).
Old 16th January 2015
  #66
Here for the gear
 

Quote:
Originally Posted by Bassmankr View Post
One thing that helped get me from a 15us average to 3us average with the DPC Latency Checker app was turning off the "High Precision Timer" in the Bios (it might be listed as HPET in your bios). Given that parameter is used for video and DAW only rigs are not using 3D video like game rigs I've seen no adverse effects from disabling it.
HPET provides an accurate real time clock for precise measurements, so I would imagine that turning this off would decrease the granularity in your results (less accurate clock readings). I can't see that enabling it would have a negative impact on performance, instead anything that relies on a clock signal would have a positive impact when it is enabled.

Just my 0.2c
Old 16th January 2015
  #67
Gear Addict
 
Pollo's Avatar
 

Quote:
Originally Posted by gravyface View Post
What are the hardware specs on your machine?
OS: Windows 7 Professional x64 Service Pack 1
CPU: i5-4570 CPU @ 3.20GHz
MB: MSI, H87-G41 PC Mate(MS-7850)
8 GB of RAM, supposed to be 1600 MHz DDR3 but my MB keeps insisting that it's 1333 MHz. I forced it to 1600 for a long time without problems. I now set it to 'auto' but it makes no difference.
I'm using on-board graphics, ethernet and audio (only for non-DAW sound).
I have 2 PCi sound cards: Echo Audio Mona and ESI [email protected]
I have 1 UAD Solo PCIe card.

The DCP spikes seem to be related to harddisk access. I did a couple of tests with Windows Performance Monitor. When LatencyMon reports a spike, performance monitor shows a disk access spike of 60%. The culprit is svchost.exe (PID 1000) which for some reason thinks it is a good idea to start accessing a whole bunch of seemingly random files in my Windows folder while I am trying to playback my DAW project.
File indexing is disabled for all drives, I have no virus scanner running. Why is this happening?

Svchost.exe (PID 1000) runs a number of services:
- Desktop Window Manager Session Manager
- Diagnostic System Host
- Distributed Link Tracking Client
- Human Interface Device Access
- Network Connections
- Program Compatibility Assistant Service
- Superfetch
- Windows Audio Endpoint Builder
- Windows Driver Foundation - User-mode Driver Framework

So any of these could be the problem. By the way, did I mention what a brilliant idea it was to combine all these services into one process?

So could it be Superfetch? Should I disable that?

Last edited by Pollo; 16th January 2015 at 07:05 PM..
Old 16th January 2015
  #68
Lives for gear
 

Jay, it's my understanding that the High Precision Event Timer is mostly for 3D video and thus given a DAW's 2D video it has no effect other than using up resourses. Given for DAW tuning you are trying to accomplish as much as you can within the finite limitations of real time operations (hense looking for lowest latency), any resources devoted to non-DAW activities (like 3D video) then lower the potential output of that DAW box. Maybe others reading this with in-depth knowledge of real time computer internals can also chime in to enrich this discussion.
Old 16th January 2015
  #69
Lives for gear
 
gravyface's Avatar
Quote:
Originally Posted by Pollo View Post
OS: Windows 7 x64 Service Pack 1
CPU: i5-4570 CPU @ 3.20GHz
MB: MSI, H87-G41 PC Mate(MS-7850)
8 GB of RAM, supposed to be 1600 MHz DDR3 but my MB keeps insisting that it's 1333 MHz. I forced it to 1600 for a long time without problems. I now set it to 'auto' but it makes no difference.
I'm using on-board graphics, ethernet and audio (only for non-DAW sound).
I have 2 PCi sound cards: Echo Audio Mona and ESI [email protected]
I have 1 UAD Solo PCIe card.

The DCP spikes seem to be related to harddisk access. I did a couple of tests with Windows Performance Monitor. When LatencyMon reports a spike, performance monitor shows a disk access spike of 60%. The culprit is svchost.exe (PID 1000) which for some reason thinks it is a good idea to start accessing a whole bunch of seemingly random files in my Windows folder while I am trying to playback my DAW project.
File indexing is disabled for all drives, I have no virus scanner running. Why is this happening?

Svchost.exe (PID 1000) runs a number of services:
- Desktop Window Manager Session Manager
- Diagnostic System Host
- Distributed Link Tracking Client
- Human Interface Device Access
- Network Connections
- Program Compatibility Assistant Service
- Superfetch
- Windows Audio Endpoint Builder
- Windows Driver Foundation - User-mode Driver Framework

So any of these could be the problem. By the way, did I mention what a brilliant idea it was to combine all these services into one process?

So could it be Superfetch? Should I disable that?
How fast are your disks? SATA 7.2K?
Old 16th January 2015
  #70
Lives for gear
 

And are those disks hooked up to a SATA 3G or 6G port? If 6G are you using a 6G SATA cable?
Old 16th January 2015
  #71
Lives for gear
 
gravyface's Avatar
Quote:
Originally Posted by Bassmankr View Post
And are those disks hooked up to a SATA 3G or 6G port? If 6G are you using a 6G SATA cable?


Yup and how many disks? You could put your OS and applications on a separate SSD drive, move project files to your big SATA drive, and depending on how dependent you are on sample libraries and how many you have, those could either go on the SATA drive or another SSD drive.

Last edited by gravyface; 16th January 2015 at 08:30 PM..
Old 16th January 2015
  #72
Quote:
Originally Posted by Pollo View Post
DPCLat v1.30
Most current is v1.4.0. Just a heads-up.
Old 16th January 2015
  #73
Gear Addict
 
Pollo's Avatar
 

Quote:
Originally Posted by Metrik View Post
Most current is v1.4.0. Just a heads-up.
Really? Does it fix the Windows 8 problems? I'll check it out.


Anyway. My current status. I added superfetch to my script of services to disable before doing any DAW activity.
Now DCP latency checker is completely happy. Absolute maximum 125 us.
But LatencyMon does not agree. Maximum interrupt to process latency there is 1700 us, which it is not happy about. Also I see frequent spikes in activity there which are totally invisible for DPCLat.
So whom am I to believe? I think I am going to go with DPCLat. I don't know what LatencyMon is doing that is different from what DPCLat does, but in the past I have always trusted DPCLat and it never failed me.
Also, and that is probably the most important, I don't hear any pops, clicks or crackles. So DPCLat is telling me what my ears are telling me as well.

Thanks for all the other tips and hints. My disks and DVD are all SATA and the BIOS is set for AHCI. I have the OS on a separate disk, my audio files on another.
I don't experience any bottleneck with disk speed per se.

I have no anti-virus software running (of course not ). Also I actually need ethernet since some of the MIDI is routed through that.
Old 16th January 2015
  #74
Here for the gear
 

I'll have an audio interface at the end of the month so I'll send the time between now and then cleaning my system up.

I'm running
windows 8.1 professional
16 core Xeon (dual 8 core)
64 gig RAM
4 SATA drives (1Tb each)

Hopefully I can get latency down to the minimum
Old 17th January 2015
  #75
Here for the gear
 

It's definitely worth having a separate user account on your windows machine solely for using a DAW. Of you use chrome as a browser, disable it from autostartas that will save vital memory and CPU cycles
Old 17th January 2015
  #76
Do you know of a one-stop guide or site where I can go for a full Windows 7 optimization?
I always optimize Win7 to some degree, to run audio the best, but I'm sure I could go deeper. I used to go to this site called Black Viper or something. Still good or do you have something better / deeper?
Old 17th January 2015
  #77
Lives for gear
 
valis's Avatar
Disabling HPET is a 'tweak' that goes back to people who were still running XP on machines meant for later OSes. It's not just that it provides higher granularity, but many things will behave entirely differently off RTC instead of HPET. It's not 'just for 3d graphics' by any means, but your GPU is indeed one of the things that tends to 'consume' the most time when measuring DPC Latencies. Given that the entire desktop (unless Aero is off) is composited on the GPU, and that most current DAWs are built with this in mind (Cubase 8 certainly is now), this may not be a bad thing. But you can find drivers that are less 'gaming optimized' and play better with other system components. WDM drivers (the ones Windows gives you by default) and the Quadro/FireGL drivers tend to be much better behaved in this regard. Sadly, it's a driver by driver thing.

SATA & ethernet are going to be dependent on the chipset & driver both as well, if you're running in a legacy mode (non-AHCI) or relying on SATA ports that use a 3rd party chipset things may be especially poor. Windows' default AHCI driver seems to be much 'better behaved' than the AMD & Intel specific ones as well, when I've had systems experiencing issues with power & RAM I've noticed the Windows AHCI/SATA drivers rarely led to corrupt drive data, the Intel & AMD ones (sadly) almost always did. This is due to very aggressive caching imho...

Btw both of my DAWs get down to the lowest buffer on my RME cards with relatively high CPU loads just fine, and neither measure terribly low on DPC statistics. However neither has *massive* spikes either. Keep in mind these are benchmarks for troubleshooting, to help isolate problematic drivers & hardware that can conflict with your audio card. They're NOT benchmarks for competing over who can get the lowest DPC statistics, like running Furmark or Futuremark or OC'ing competitions etc.
Old 17th January 2015
  #78
Gear Addict
 
Pollo's Avatar
 

Quote:
Originally Posted by valis View Post
Disabling HPET is a 'tweak' that goes back to people who were still running XP on machines meant for later OSes. It's not just that it provides higher granularity, but many things will behave entirely differently off RTC instead of HPET. It's not 'just for 3d graphics' by any means, but your GPU is indeed one of the things that tends to 'consume' the most time when measuring DPC Latencies. Given that the entire desktop (unless Aero is off) is composited on the GPU, and that most current DAWs are built with this in mind (Cubase 8 certainly is now), this may not be a bad thing.
I don't notice much difference between HPET off or on. Except that when it's off my average DPC latency is somewhat lower.
Frankly, this whole HPET thing doesn't make much sense. Some people say you have to enable it in your BIOS and enable it in your OS with some command. If that is true then it means that probably 99% of users are not having it enabled anyway. What exactly is Microsoft's master plan behind that?

On my system the graphics virtually don't use any CPU. That's probably because the graphics are on the CPU itself.
Also I don't use Aero.


Quote:
Originally Posted by valis View Post
But you can find drivers that are less 'gaming optimized' and play better with other system components. WDM drivers (the ones Windows gives you by default) and the Quadro/FireGL drivers tend to be much better behaved in this regard. Sadly, it's a driver by driver thing.
I assume you are talking about graphics dirvers here. Of all the drivers in my system, the ones that take a lot of CPU time are all made by Microsoft.


Quote:
Originally Posted by valis View Post
SATA & ethernet are going to be dependent on the chipset & driver both as well, if you're running in a legacy mode (non-AHCI) or relying on SATA ports that use a 3rd party chipset things may be especially poor. Windows' default AHCI driver seems to be much 'better behaved' than the AMD & Intel specific ones as well, when I've had systems experiencing issues with power & RAM I've noticed the Windows AHCI/SATA drivers rarely led to corrupt drive data, the Intel & AMD ones (sadly) almost always did. This is due to very aggressive caching imho...
The SATA driver shows up as 'Standard AHCI 1.0 Serial ATA controller' in device manager. Driver provider is Microsoft. Most problems seem to originate here (on my system). Maybe there is a better driver? But I updated all of them.

Quote:
Originally Posted by valis View Post
Btw both of my DAWs get down to the lowest buffer on my RME cards with relatively high CPU loads just fine, and neither measure terribly low on DPC statistics. However neither has *massive* spikes either. Keep in mind these are benchmarks for troubleshooting, to help isolate problematic drivers & hardware that can conflict with your audio card. They're NOT benchmarks for competing over who can get the lowest DPC statistics, like running Furmark or Futuremark or OC'ing competitions etc.
Low DPC latency figures and good audio performance are not two separate issues. I would think that low average DPC latency decreases the chance of unacceptably high spikes. That's why we try to attain the low figures.
Old 17th January 2015
  #79
Here for the gear
 

Quote:
Originally Posted by Pollo View Post
If that is true then it means that probably 99% of users are not having it enabled anyway. What exactly is Microsoft's master plan behind that?
There are two clock systems available to developers HPET and RTC. RTC is the real time clock which has a lower resolution than HPET. Developers have access to functions that access these clocks, and if the developer only uses RTC then the benefits of HPET are lost. I would imagine that DAW developers are now using HPET if it is available, and if not falling back to RTC.

Quote:
Originally Posted by Pollo View Post
On my system the graphics virtually don't use any CPU. That's probably because the graphics are on the CPU itself.
Also I don't use Aero.
Graphics are usually farmed out to the onboard graphics chip (GPU) freeing up vital CPU cycles.

Quote:
Originally Posted by Pollo View Post
Low DPC latency figures and good audio performance are not two separate issues. I would think that low average DPC latency decreases the chance of unacceptably high spikes. That's why we try to attain the low figures.
I would take the output of latency values with a pinch of salt, your ears are the best judge of latency. See my top comment about RTC/HPET, if the values reported with HPET disabled, then the timing is based on RTC which is less accurate.

Hope this helps
Old 18th January 2015
  #80
Lives for gear
 

Interesting read in this overclocker's thread about the High Precison Event Timer (HPET) since we are off on this tangent. I agree it's not a contest with low latency, it's just tuning your particular configuration for best performance / stability.

Do you have HPET enabled or disabled? - AnandTech Forums
Old 18th January 2015
  #81
Gear Addict
 
Pollo's Avatar
 

Quote:
Originally Posted by Bassmankr View Post
Interesting read in this overclocker's thread about the High Precison Event Timer (HPET) since we are off on this tangent. I agree it's not a contest with low latency, it's just tuning your particular configuration for best performance / stability.

Do you have HPET enabled or disabled? - AnandTech Forums
Interesting read. What I get from reading it is that disabling HPET in the BIOS is a wise thing. Reasoning as follows: Windows is NOT using it, unless specifically told to do so using the bcdedit command. Windows will use invariable TSC if it is available on the CPU (my CPU has it). Enabling HPET in the BIOS will have one effect, the timer will start generating interrupts which will need to be serviced by the CPU, regardless of whether it's doing anything with the timer information. Now the HPET generates a LOT of interrupts per second and from my measurements with LatencyMon I noticed that the ISR can take considerable time to finish.
I am leaving it off.
Old 18th January 2015
  #82
Lives for gear
 
valis's Avatar
Quote:
Originally Posted by Pollo View Post
Low DPC latency figures and good audio performance are not two separate issues. I would think that low average DPC latency decreases the chance of unacceptably high spikes. That's why we try to attain the low figures.
I never said they were separate, that's putting words into my mouth. I said that DPC Latency values were ONE method of troubleshooting a system when it's having issues. Since this practice came about I time and time again see people putting great effort into getting the absolute lowest possible DPC Latency figures regardless of what effect that may or may not have on their system. I rarely (if ever) actually see this correlated to any of the many benchmarks floating around (the database DAW Plus maintains for instance) in any meaningful way. Ie, at 95% usage I get 8 more tracks of audio or 2 more instances of this plugin etc...when used with THIS hardware combination and THIS audio driver/hardware...etc.

Simply focusing on a single metric to 'maximize performance' is the user's choice, and I have no dog to hunt in a battle against user choice. I'm just here to remind people that *troubleshooting metrics* are not a race...
Old 18th January 2015
  #83
Lives for gear
 
valis's Avatar
First, the 'enabling' in Win7 isn't 'enabling' it, it's FORCING windows to use it as a base timer. But if I found myself having problems with audio performance with HPET simply enabled in BIOS, I'd start wondering about other aspects of my system. If on a budget and I had no other choice than to commit to this particular hardware combination, then sure go for whatever means you may deem necessary to fix things and achieve acceptable performance. However I tend to choose hardware that works over forcing sub-par hardware (and/or drivers) to work, unless I have no other choice. Maybe that's just me...

The info you're seeing in in that anandtech thread, and several of the posters in fact, are duplicating what has long been discussed in THIS THREAD over at the guru3d forums. Same ideas, same discussion, same relevance to GPU and Gaming performance (and same irrelevance to us). You'll note even without that registry setting that it does *show up* as a timer that's available if it's not disabled in the BIOS. That means that drivers and applications can *choose* their timing method. Forcing it just makes all timers inherit everything from HPET, which may or may not be ideal. It's going to depend entirely on the device in question, how it chooses to derive its clocking and interrupts, and your driver stack and hardware.

IF your motherboard or a device in your system has issues clocking off HPET, then it might help performance. But keep in mind again these fellows are judging performance by how Battlefied4 and Borderlands2 perform, and are discussing whether SLI and custom TDP settings are affected adversely. Only ONE of these issues has any bearing for us (TDP for people who don't run at stock settings). And if a board has a problem (either at the driver or APIC level) then there's probably more than one way to crack that egg.
Old 20th January 2015
  #84
Gear Addict
 
Pollo's Avatar
 

Quote:
Originally Posted by valis View Post
I never said they were separate, that's putting words into my mouth.
I never said that you said that

One thing I'd still like to add. I am not interested in performance as in squeezing the maximum number of tracks/plugins out of my machine. My only concern is the reliability, no pops or clicks in normal use.
In my mind DPC latency is a pretty good metric for that purpose, in fact I don't know of any other.
Old 21st January 2015
  #85
Lives for gear
 
valis's Avatar
Quote:
Originally Posted by Pollo View Post
I never said that you said that
No problem then

Quote:
Originally Posted by Pollo View Post
One thing I'd still like to add. I am not interested in performance as in squeezing the maximum number of tracks/plugins out of my machine. My only concern is the reliability, no pops or clicks in normal use.
Pops & clicks in normal use is easy to test just with some benchtesting & load under projects. DPC Latency checker obviously enables targeting more than just that, but imho you can go beyond this alone...

Quote:
Originally Posted by Pollo View Post
In my mind DPC latency is a pretty good metric for that purpose, in fact I don't know of any other.
Well let's go there then. First, it's helpful at first to look at why Deferred Procedure Calls are monitored to help troubleshoot systems:

A Deferred Procedure Call (DPC) is a high priority call that cannot be pre-empted by the OS or applications and must run to completion, which is obviously a problem if it competes with your DAW or delivering your audio buffer to the hardware. However it's only ONE of TWO types of calls that can do this, the other being Hardware interrupt service routines (ISR's). DPC's are scheduled calls (run regularly to poll hardware or etc) and generate Interrupt calls from the software side, ISR's are triggered events from the *hardware* side and will pre-empt other tasks while that hardware is polled. Note only one of these two events is even being monitored by the DPC checkers we're discussing here (and it's not ISR's).

Now let's look at why ISRs and DPCs cause problems, specifically for these reasons:

- The OS (and thus the user) has no control over their execution. ISR's are triggered by physical hardware signals telling the CPU that it needs attention, and the CPU immediately jumps to the driver's interrupt service routine. DPCs are scheduled by interrupt handlers and run at a priority which is ONLY exceeded by these hardware interrupt service routines (ISR's)

- ISR and DPC activity actually increases with system activity, which means simply testing with a DPC Checking utility at idle doesn't tell the whole picture. As a system becomes more active, interrupts and DPCs will generally start taking up more CPU time. This may eventually visibly (or audibly) affect system performance. In these cases, no single ISR or DPC routine is the problem - it is their cumulative usage of CPU time. Identifying the major culprits of course DOES help get this CPU usage time down, which is where the simpler DPC Latency tools we have do indeed help.

- It is rarely obvious to a casual user that ISRs and DPCs are causing performance problems. Before the DPC Latency utilities became common, the only place information about them was visible was in the performance monitor. This UI is really useful, but a little hard to get to. However it's still one of the BEST utilities on Windows to monitor numerous system statistics...

Performance Monitor can be run as a System Management Console "snap-in" (inside MMC.exe) but the easiest way to run it is to simply type Perfmon into your Run dialog (on the start menu or Winkey+R). Alternatively you can go under the Administrative Tools and find the "Computer Management" application. A little confusing at first, you must 'add' (Plus sign) the metric(s) to be able to monitor them. The ones that correlate the best to DPC's and ISR's are % Interrupt Time, % DPC Time, Interrupts/Sec, DPC Rate, and DPCs Queued/Sec. However much like the DPC Latency tools we have here, even monitoring this way only tells PART of the story. You can 'see' an issue, but you can't easily tell WHAT CAUSES it.

The best way to get a clear picture of the CPU time spent in ISRs and DPCs is to use the kernel's ETW events which can be enabled and analyzed using ETW based performance tools. Better yet, if you have any of the SDK's or (or the WDK, Windows Development Kit) installed that Microsoft offers (VisStudio etc) you can simply use Tracelog:

- Run this an elevated command prompt window: tracelog -start "NT Kernel Logger" -f krnl.etl -dpcisr -nodisk -nonet -b 1024 -min 4 -max 16 -ft 10 –UsePerfCounter
- Start, run then stop your test
- Stop the kernel logger and save the data to 'krnl.etl': tracelog –stop
- Generate a nicely formatted report of the ISR and DPC activity during the test: trcerpt krnl.etl -report isrdpc.xml

isrdpc.xml now has a nicely formatted report that lists the % utilization, counts, and histograms of the ISR and DPC execution time by system module (driver or etc). This data is really helpful in finding problematic ISR and DPC activity, as it actually LISTS what causes each datapoint. However running DPC Latency Checker or etc certainly is simpler

------

Obviously using test projects to test load would be another way. For instance Logic users have a handy benchmark setup to test CPU loading. The DAWBench guys have several projects available as well for a variety of DAW applications... Or even better use test projects in parallel to the above procedures as an ideal way to generate the most useful reports. Hint, when I build a system and benchtest it, I do a fair amount of 'pushing things' to isolate issues before I deploy that system...

Checking 'absolute' round trip values of your interface is a good idea too if it's new and not being carried over from a previous build (not all ASIO drivers correctly report safety buffers and/or AD/DA buffers): https://centrance.com/downloads/ltu/

Last edited by valis; 22nd January 2015 at 01:46 PM..
Old 22nd January 2015
  #86
Lives for gear
 
valis's Avatar
^ cleaned up the above a bit, hopefully someone finds it useful buried on page 3
Old 22nd January 2015
  #87
Quote:
Originally Posted by valis View Post
No problem then


Pops & clicks in normal use is easy to test just with some benchtesting & load under projects. DPC Latency checker obviously enables targeting more than just that, but imho you can go beyond this alone...



Well let's go there then. First, it's helpful at first to look at why Deferred Procedure Calls are monitored to help troubleshoot systems:

A Deferred Procedure Call (DPC) is a high priority call that cannot be pre-empted by the OS or applications and must run to completion, which is obviously a problem if it competes with your DAW or delivering your audio buffer to the hardware. However it's only ONE of TWO types of calls that can do this, the other being Hardware interrupt service routines (ISR's). DPC's are scheduled calls (run regularly to poll hardware or etc) and generate Interrupt calls from the software side, ISR's are triggered events from the *hardware* side and will pre-empt other tasks while that hardware is polled. Note only one of these two events is even being monitored by the DPC checkers we're discussing here (and it's not ISR's).

Now let's look at why ISRs and DPCs cause problems, specifically for these reasons:

- The OS (and thus the user) has no control over their execution. ISR's are triggered by physical hardware signals telling the CPU that it needs attention, and the CPU immediately jumps to the driver's interrupt service routine. DPCs are scheduled by interrupt handlers and run at a priority which is ONLY exceeded by these hardware interrupt service routines (ISR's)

- ISR and DPC activity actually increases with system activity, which means simply testing with a DPC Checking utility at idle doesn't tell the whole picture. As a system becomes more active, interrupts and DPCs will generally start taking up more CPU time. This may eventually visibly (or audibly) affect system performance. In these cases, no single ISR or DPC routine is the problem - it is their cumulative usage of CPU time. Identifying the major culprits of course DOES help get this CPU usage time down, which is where the simpler DPC Latency tools we have do indeed help.

- It is rarely obvious to a casual user that ISRs and DPCs are causing performance problems. Before the DPC Latency utilities became common, the only place information about them was visible was in the performance monitor. This UI is really useful, but a little hard to get to. However it's still one of the BEST utilities on Windows to monitor numerous system statistics...

Performance Monitor can be run as a System Management Console "snap-in" (inside MMC.exe) but the easiest way to run it is to simply type Perfmon into your Run dialog (on the start menu or Winkey+R). Alternatively you can go under the Administrative Tools and find the "Computer Management" application. A little confusing at first, you must 'add' (Plus sign) the metric(s) to be able to monitor them. The ones that correlate the best to DPC's and ISR's are % Interrupt Time, % DPC Time, Interrupts/Sec, DPC Rate, and DPCs Queued/Sec. However much like the DPC Latency tools we have here, even monitoring this way only tells PART of the story. You can 'see' an issue, but you can't easily tell WHAT CAUSES it.

The best way to get a clear picture of the CPU time spent in ISRs and DPCs is to use the kernel's ETW events which can be enabled and analyzed using ETW based performance tools. Better yet, if you have any of the SDK's or (or the WDK, Windows Development Kit) installed that Microsoft offers (VisStudio etc) you can simply use Tracelog:

- Run this an elevated command prompt window: tracelog -start "NT Kernel Logger" -f krnl.etl -dpcisr -nodisk -nonet -b 1024 -min 4 -max 16 -ft 10 –UsePerfCounter
- Start, run then stop your test
- Stop the kernel logger and save the data to 'krnl.etl': tracelog –stop
- Generate a nicely formatted report of the ISR and DPC activity during the test: trcerpt krnl.etl -report isrdpc.xml

isrdpc.xml now has a nicely formatted report that lists the % utilization, counts, and histograms of the ISR and DPC execution time by system module (driver or etc). This data is really helpful in finding problematic ISR and DPC activity, as it actually LISTS what causes each datapoint. However running DPC Latency Checker or etc certainly is simpler

------

Obviously using test projects to test load would be another way. For instance Logic users have a handy benchmark setup to test CPU loading. The DAWBench guys have several projects available as well for a variety of DAW applications... Or even better use test projects in parallel to the above procedures as an ideal way to generate the most useful reports. Hint, when I build a system and benchtest it, I do a fair amount of 'pushing things' to isolate issues before I deploy that system...

Checking 'absolute' round trip values of your interface is a good idea too if it's new and not being carried over from a previous build (not all ASIO drivers correctly report safety buffers and/or AD/DA buffers): https://centrance.com/downloads/ltu/
Excellent post, once again.
I agree that lowest DPC is not something to focus on, rather a stable level without spikes and without a major raise when the DAW is active.
Especially GFX and some SSDs increase DPC calls when under heavy load, in the audio world it still is pretty low for most available products.

DPC values do not show all issues (as Valis mentioned before), as HPET (with PropHead Balance), RAM speed issues (ASUS...) etc. may cause dropout issues without them being visible in latencymon or DPC checker.
Old 22nd January 2015
  #88
Lives for gear
 

Valis, thanks for the detailed post on getting a detailed log of what your configuration is actually doing. Very useful for those who want to go the extra mile in tuning or troubleshooting. While it's buried on page three I'll remember to bring it up in future threads where needed (I'm sure others will mentally bookmark it too).

In regards to turning off the HPET, as pointed out in the link of my above post, it's one of those things that certain configurations benefit from where I'm sure others it won't. In my case I'm using a newer Windows OS (Win 7) with a newer CPU (Intel 3770k 4 core) both of which don't need it / use it other than possibly for initial calibration of it's other timer. Additionally my motherboard (an Asus) performs better with it off (looks like from that linked discussion Asus benefits quite a lot where with Gigabyte boards it has little effect).

Bottom line from all who have contributed to this thread is to get the best from your particular configuration you have to employ some monitering tools, do a bit of detective work, and experimentation for best tuning. Having low DPC without spikes along with knowing it's peak value is only an indicator to getting the tuning dialed in.
Old 22nd January 2015
  #89
Lives for gear
 
Arksun's Avatar
Quote:
Originally Posted by valis View Post
- ISR and DPC activity actually increases with system activity, which means simply testing with a DPC Checking utility at idle doesn't tell the whole picture.
Though it should also be stated that with regards to LatencyMon specifically, that checking utility IS designed to run at idle and not whilst the DAW is running.
Old 23rd January 2015
  #90
Lives for gear
 
valis's Avatar
Quote:
Originally Posted by Arksun View Post
Though it should also be stated that with regards to LatencyMon specifically, that checking utility IS designed to run at idle and not whilst the DAW is running.
Correct it does say that. My guess would be because you're comparing errant drivers to a 'baseline' rather than looking for them in a busy mess.
📝 Reply
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
🖨️ Show Printable Version
✉️ Email this Page
🔍 Search thread
♾️ Similar Threads
🎙️ View mentioned gear