• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

DPC Latency problem

BTRY B 529th FA BN

BTRY B 529th FA BN

Lifer
So upon booting into my game rig, I see ~ 5us latency. Without doing anything, a little while later it jumps to around 100us. This has to be from a staggered start of some service or something.

Any idea on what it is or how to trace it?
 
Last edited:
The way to track down something causing DPC latency spikes is to start with as few services/drivers enabled as possible.

Then you slowly enable one thing at a time until it starts spiking.
It could be a number of issues. One could simply be a bad mobo BIOS.
Otherwise, a friend of mine had DPC issues with one of his eSATA drivers. Disabling it completely made it go away, but obviously, he can't use his eSATA anymore.

I assume you've run the DPC Latency checker already. Maybe you should try LatencyMon, it seems to be quite a lot more detailed.
 
Lower is definitely better, depending on what you are doing. Zero would be true real-time, but lower latency means you can generally use a smaller buffer.

100us should be fine; I don't believe I was ever at single digits.
According to http://www.thesycon.de/deu/latency_check.shtml 500us would be a good point between 'okay' and 'you might have problems.'

My usage hasn't been critical nor sensitive enough where I needed to get it down to absolute lowest latency. What are you doing that requires it?
 
I am trying to figure out why it jumps basically. I also run it while I game and while it does stay often in the double digits it seems to jump with lots of sound being processed. Just an unscientific observation. Absolute zero or single digits is my goal if possible but I imagine if I can't, getting there could produce fruits of the labor.
 
Single digit DPC latencies are obscenely low, Anandtech hasn't tested a board in recent memory (perhaps ever) that could even get down into even the double digits. I'd suspect that you're seeing some sort of measurement error.
 
I'm using DPC Latency Checker v 1.3.0 from thesycon. This is normally upon boot till about 10-15 minutes into the OS without touching a thing. Then it jumps to 100s for about 5-10 minutes then falls back down to some really low numbers. Again with out doing anything cept running the checker. But it does jump alot while in UT3 sometimes fairly high then back to 20s n teens... :hmm:
 
Last edited:
Ok. I'm back. I'm now hovering in the teens occasionally seeing 10, 8, 9, looks like it was a driver problem.

Using an EVGA 760.
 
Last edited:
Yeah, it usually is a problem with drivers.

Glad you got it fixed.

That said, unless you're doing live audio/video recording or streaming, it shouldn't matter too much whether it's 10us or 100us. Simple audio playback relies on huge buffers to overcome the occasional blip. DPC latency only becomes a real concern when it exceeds 500-1000us anyway, at which point it starts becoming obvious that the buffer is not enough.

For anyone else wanting to track down DPC latency issues, besides the thesycon link I posted earlier, you can also use LatencyMon from http://www.resplendence.com/latencymon

It's more comprehensive and useful for tracking down offenders causing the latency issues. However, the thesycon tool is much easier to run, and does not require installation, so it's useful to have as a quick preliminary test before you use latencymon.
 
The single digit latency numbers.

EDIT: i mean could it be reporting the wrong numbers? it now seems to consistently report single and low double digit numbers until like I said before it will jump to the 100s for about 10 min then back down.. :hmm:
 
Sorry for the delay.

I don't believe there would be any reason for the numbers to be horribly off, but it's possible, since it's basically polling repeatedly. But again, unless you're doing real-time recording, it shouldn't matter too much whether it's 10us or 100us.

100 should be fine, if it's just the occasional spike. If you really wanted to get rid of it, you'd have to figure out what triggers it by finding out what's happening to the system at the points it spikes. LatencyMon would be helpful, as it lists how many calls each driver has made.

One analogy I can make is if your ping rides around 10ms, but occasionally spikes to 50ms. Unless you're in a heavy firefight and/or sniping, it wouldn't matter too much.
 
BTRY B 529th FA BN said:
The single digit latency numbers.

EDIT: i mean could it be reporting the wrong numbers? it now seems to consistently report single and low double digit numbers until like I said before it will jump to the 100s for about 10 min then back down.. :hmm:
Click to expand...

Have you done any specific optimizations? I'm not doubting what the tool says, I'm just wondering if the tool is wrong. From some reading that I've been doing, the biggest way that people were able to get down into even the low teens was by disabling as many devices as possible. Single digits on an unoptimized machine just seems unreal.
 
I wouldn't say it's "unoptimized" but rather bare-bones.

That's just how it works though; drivers need to schedule requests, and that introduces some latency, which would affect audio and video streaming. This is why we usually have huge buffers, so that when latency spikes and it's unable to stream data quickly enough, it pulls it from the buffer instead.

This is why the usual culprits are drivers, and the way to find DPC issues is by disabling drivers and services.

But when recording, you want as little latency and as small a buffer as possible, because even just a few ms of lag will throw you off. Essentially, what you're playing/singing/etc is not what you're hearing.
 
mfenn said:
Have you done any specific optimizations? I'm not doubting what the tool says, I'm just wondering if the tool is wrong. From some reading that I've been doing, the biggest way that people were able to get down into even the low teens was by disabling as many devices as possible. Single digits on an unoptimized machine just seems unreal.
Click to expand...

Just the usual recommendations I've been reading.

There is nothing un-needed on the machine (rig2 in sig) just Unreal Tournament III
 
Tomorrow I'm going to test all day on my other drive that has Latency Monitor installed on it to see where it's coming from. There are a few other things installed on that drive but I'm thinking of wiping it, and doing just like my SSD drive is = nothing except Unreal Tournament III and what is needed.
 
DarkRogue said:
I wouldn't say it's "unoptimized" but rather bare-bones.

That's just how it works though; drivers need to schedule requests, and that introduces some latency, which would affect audio and video streaming. This is why we usually have huge buffers, so that when latency spikes and it's unable to stream data quickly enough, it pulls it from the buffer instead.

This is why the usual culprits are drivers, and the way to find DPC issues is by disabling drivers and services.

But when recording, you want as little latency and as small a buffer as possible, because even just a few ms of lag will throw you off. Essentially, what you're playing/singing/etc is not what you're hearing.
Click to expand...


Can the buffer parameter be optimized?
 
Depends on the software, lol.

I'm by no means an expert on this; I'm just speaking from what I've heard and what I know from experience.

I believe the windows audio stack has some built-in buffer, and I'm not sure that can be changed. If you use ASIO or WASAPI, then you can change the audio buffers on the devices or their control panels. (Or you should be able to anyway.) I have no idea about video, though.

For playback, the only real difference is that the audio begins playing a fraction of a second sooner, since there's less time needed to fill a smaller buffer. However, if the buffer is too small, then you'll hear audible skips and pauses while the system runs out of buffered data and needs to stream. Similar things happen with recording, except that if the delay between your input and the PC's output is too great, it gets very distracting.
 
kazaam said:
For my laptop it was intel matrix storage manager (now rapid restore or whatever).
Click to expand...

Rapid Storage Technology (RST)

But yeah, any hardware monitoring tools that continuously poll devices in the system are notoriously bad about creating DPC latency spikes. A *while* ago I had an issue when playing audio in WMP. Every so often there would be an audible pop. Drove me crazy until I figured out that it was CPU-Z running in the background.
 
While 100s are good, single digits are great 😎

There are two possibilities. The single digit reports are accurate, or they are being reported wrong. I'd like to take the time to find out if I can maintain single digits or low numbers and or if this is an error. I still am getting sustained 100s for ten minutes or so then a drop back into low numbers. What I'm thinking about doing is wiping out a drive and installing just the OS (Win7 64) with all the updates and then monitoring the DPC Latency Checker V1.3.0 I don't have any PS/2 keyboards or mice to test with so :hmm: wonder if this will be an issue. Then I'll test in single change increments e.g. when I install the driver for the R.A.T. 7 mouse and etc etc I'm not 100% sure on LatencyMon and if it is finding the needle in the hay-stack.

cool
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top