DPC Latency Checker

If you want to read up... a loooong description HERE.
Here's a part of it:

Quote:

---

Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and better) there is a specific interrupt handling mechanism. A device driver cannot process data immediately in its interrupt routine. It has to schedule a Deferred Procedure Call (DPC) which basically is a callback routine that will be called by the operating system as soon as possible. Any data transfer performed by the device driver takes place in the context of this callback routine, named DPC for short.

---

Quote:

---

Originally Posted by zalbard

Long story short: disable HPET (entirely) and disable C6 State (C3 and other ones are OK).
My DPC is now down to 10-14 µs.

---

Could someone test this for me, please? :) Especially with boards other than EVGA X58.
Just test DPC with a) HPET & C6 both on, b) C6 without HPET, and c) both disabled.
Thank you. :up:

SO... in short..will it benefit me? in everyday performance just doing normal stuff that qualifies as awesome? :)

Quote:

---

Originally Posted by Computurd

SO... in short..will it benefit me? in everyday performance just doing normal stuff that qualifies as awesome? :)

---

I think I've lost quite a bit of jitter while gaming I was attributing to microstuttering (flawless now).

interesting caveat here...I have been doing some testing and i have the HPET disabled on my classified, and some storage benchmarks do not report very accurately with it off. i was also getting a warning from AS SSD that the High Performance timer was crashing possibly due to overclocking. anywho when it is off things like CDM give abnormally low results.

That's interesting.
Looks like it actually does have its uses. Too bad it's causing latency issues on Classified... Hmm.
Regarding crashing... Was it off? Or did you have it enabled, and it actually crashed?

no i had disabled it to get better scores in the DPC thingy.

Starting Firefox (lots of Windows) does this to mine...

http://halk.lyrebird.feralhosting.co...foxlatency.png

Edit : I shoulds say that it does return to that 170-220 latency eventually. I'm on an Asus Crosshair IV Formula, 8GB 1600Mhz, 1090t, Vertex 2, GTX 580. I'm now going hunting for wabbits to disable in the BIOS!

Edit : And if I cut it down from 60 or so Windows to about a dozen opening Firefox seems to have no impact on latency. My best guess is that opening that many Windows causes a great deal of failed or waiting network traffic.

Edit : I don't have the option to disable either of the suggested things. So I'm stuck at the 170 or so latency it seems.

EVGA SR-2, Dual X5680's @ 4.3Ghz, Dual 5870s, Win7 x64 - full crunching load on all CPU threads, as always :) Running Winamp, Outlook, 15 other programs (122 tasks running) - I can live with that ;) Interesting tool though.

By the way, disabling HPET destroys my crunching performance. Or any other performance that relies heavily on mulithreading, for that matter. I would not recommend turning it off. Unless all you do is play single threaded games :p:

Apparently, Windows 8 enables HPET by default (assuming hardware supports it).
Windows 7, on the other hand, uses Time Stamp Counter (TSC), which has lower resolution interval, and thus lower DPC latency.

However, it appears that some devices benefit from enabling HPET in Windows 7. To enable HPET in Windows 7:

1. Enable HPET in BIOS (if it's not enabled by default).
2. Open an elevated command prompt (Start»All Programs»Accessories»Right Click Command Prompt and select Run as Administrator).
3. Type the following command and press enter:

Code:

---

bcdedit /set useplatformclock true

---

4. Restart the computer.

To undo this change, you have to perform the same steps, except for using a different command during step 3:

Code:

---

bcdedit /deletevalue useplatformclock

---

Source: www.ni.com (National Instruments)

How this stuff is going to affect performance in Windows 7, I don't know. I have just found the article.
I suppose that storage, sound and graphics performance may change.

I use hpet.

I use this code, this is the ahk scripting ver of it.

Code:

---

DllCall("ntdll.dll\NtSetTimerResolution", UInt, 1)                ;min allowed setable, much lower then specs say is allowed, but the result is not much lower then 0.500ms supposed min value

---

What that does is essentially cut my dpc latency in half.
It was afterwards when I found out about hpet.
After enabling hpet my dpc latency was on avg around 10-15us lower (using including the script code above I posted).

The reason being, I think, is because hpet is a higher precision timer.
Higher precision means it's possible to set the timer even lower then the norm.

What I mean by that, here's an example:
Say for ex. you're dev'ing your own os...
You set the min hex code for thye normal timer, say it equ's to 1ms.
Now you do the same with hpet, say that equ's to say maybe 0.5ms.

That's the idea and that's how it works out.
I don't know if you guys will understand or not...
Hpet IS faster, at least on my system, but only after I've set the user timer in windows.

There is one more timer mod other then the "ntdll.dll\NtSetTimerResolution".
I think it might of been ExNtSetTimerResolution, it's been a while so I'm not sure.
Anyways to beable to setup that other timer to a diffrent value, one needs to be the kernel it's self to doit.
It means you have to get into ring0 by hacking the kernel irq thingamajigers, and from there you could possibly set the timer.

Prob is, once it's possible, hehe, the system will be unlike most systems.
The clock it's self will run to fast or to slow.
Though I believe it's very possible to patch that code out for the clock to make it right.
Anyways it's not an easy mod, and since I don't have any ring0 code I can't play with it.

There was a program out there that did essentually the same thing, called speedpig.
It was a addon hack for an old dreamcast emulator.
It doesn't work on the later os'es...

You could do some really neat stuff though with it.
By slowing down the main system timer, stuff like dl'ing, instead of say 5k a sec, it would register say 100k a sec lol.
By speeding it up, it would instead say 1k a sec, etc etc.

It was meant for games that needed alot more cpu time then otherwise possible.
Say for example, i slow the timer down by 10x, then esentually my cpu is really proccessing 10x more per sec then normal, thing is that 1sec is really 10secs...
I bet most won't understand that one either lol.

There's also games that don't need the power, that just need to get things done as fast as possible, much like pc games are...
In which case you would probably set the timer to 1.25x or 1.5x or 2x, ext.
So you weren't wasting time processing data that wasn't there...

If your cpu is waiting for the code to finish, it's slow.
If it's able to finish small code faster then then norm, then it's faster.

It's really the holy grail of cpu...
Though on pc, generally you'de want a faster timer.
Unless your cpu wasn't fast enough, in which case you might slow down the timer (I would not recommend this unless benching mem, or unless you had some sort of game that needed 2x the cpu power then you currently have).

There's a big issue though other then just the clock.
Your mem/hd controller timings are all baised off the main pic timers, pic, apic, hpet and etc.
Well actually scratch that, the mem is actually independent of this timer these days.
It's has it's own base clock, each stick does.

Looks like my post has already gotten to long I'm gonna end it.
Anyways that one script code I posted above is ahk script, I think there's a way of doing it via rundll32 on the cmd line.
But there is no way of using the read ver of the cmd on rundll32 as far as I know.

^^ :P

Edit:
Oh and thanks zalbard for bumping the thread, this thread is probably gonna be kinda important for win8.

Interesting stuff, thanks!

Quote:

---

Originally Posted by NEOAethyr

I use hpet.

I use this code, this is the ahk scripting ver of it.

Code:

---

DllCall("ntdll.dll\NtSetTimerResolution", UInt, 1)                ;min allowed setable, much lower then specs say is allowed, but the result is not much lower then 0.500ms supposed min value

---

What that does is essentially cut my dpc latency in half.
It was afterwards when I found out about hpet.
After enabling hpet my dpc latency was on avg around 10-15us lower (using including the script code above I posted).

---

So you basically run the script in the background?
Would be nice to set it permanently, assuming it works.
What does it set HPET resolution to?

Quote:

---

Originally Posted by NEOAethyr

The reason being, I think, is because hpet is a higher precision timer.
Higher precision means it's possible to set the timer even lower then the norm.

---

It is, indeed.
Too bad about HPET generally increasing DPC latency, though. But I guess that's just poor implementation.
Or is it supposed to lock to 1000us like it does in Win 8? Some say it's normal, hence my question about the resolution.
Intel's docs on the matter are a bit hard to follow, but they mention pretty low values.

Quote:

---

Originally Posted by NEOAethyr

There is one more timer mod other then the "ntdll.dll\NtSetTimerResolution".
I think it might of been ExNtSetTimerResolution, it's been a while so I'm not sure.

---

I found your old thread if it helps. :p:

Have you tried enabling HPET in Win 7 the way I described? My DPC latency doesn't seem to be shooting up like in Win 8.

P.S. For those curious, the HPET enable / disable in Win 7 works.

Idle DPC latency stats:
HPET enabled in BIOS & OS: 009 µs min | 015 µs avg | 038 µs max
HPET disabled in BIOS & OS: 080 µs min | 100 µs avg | 120 µs max

So I guess 1000 µs in Win 8 just means that the OS sucks.

I use this method to setup hpet:

Code:

---

bcdedit /set {current} useplatformclock true

---

The current thing is for the current booted up os.
It's just to ensure things don't get goofed up somehow and the setting is applied incorrectly in some way.

The script for the user timer thing, is perm.

Code:

---

;User Timer Max Quantum Slice Resolution
;Quantum timer resolution
Set_User_Timer_QSR_Min:
DllCall("ntdll.dll\NtSetTimerResolution", UInt, 1)                ;min...
return

Set_User_Timer_QSR_Max:
DllCall("ntdll.dll\NtSetTimerResolution", UInt, 999999)                ;max...
return

Set_User_Timer_QSR_05:
DllCall("ntdll.dll\NtSetTimerResolution", UInt, 5000)                ;0.500 ms
return

Set_User_Timer_QSR_1:
DllCall("ntdll.dll\NtSetTimerResolution", UInt, 10000)                ;1.000 ms
return

Set_User_Timer_QSR_10:
DllCall("ntdll.dll\NtSetTimerResolution", UInt, 100000)        ;10.000 ms
return

Set_User_Timer_QSR_156:
DllCall("ntdll.dll\NtSetTimerResolution", UInt, 156000)                ;15.600 ms
return

---

I just call the one I want from the context menu in my network monitor program that I made.
Otherwise you'de just put in a blank file, with an ahk file extention, and ahk (ahk_L I believe is the only one updated these days) installed:
DllCall("ntdll.dll\NtSetTimerResolution", UInt, 156000) ;15.600 ms
That would set it to the default.

There's a way of reading it back, to ensur it was set right.
I don't know where I have that code at the moment though, it was a random test script i have backed up with a bunch of others somewhere.

The script isn't supposed to stay running...
It wouldn't normally unless you made one that did so.

Anyways there were times where some apps had lowered the timer to increase responsiveness.
I don't remember what apps though :\.
I probably should check that out actually... (It's possible it gets increased because of that when I run a certain app..)

I'll brb, gonna make a prog real quick that reads back the value.

Edit:
Err, I found the api, NtQueryTimerResolution.
But I haven't been able to figure it out, I've done it twice before.
So I'm searching my drive for all files containing this string, hopefully I find it...
Oui, in 2-3 hrs I would of been up for 24hrs, I hope I find this thing...

Quote:

---

Originally Posted by NEOAethyr

I'll brb, gonna make a prog real quick that reads back the value.

---

There's already such software. :) ClockRes from MS itself.
My current config, using TSC (without HPET):

Code:

---

Maximum timer interval: 15.625 ms
Minimum timer interval: 0.500 ms
Current timer interval: 0.977 ms

---

Yeah I know, but that software is a tiny bit limit with it's min and max, it doesn't expect certain value's, but it is good enough.
For some reason it's saying some of my value's are 2.5ms..., ohwell i'll figure that out later ;).

Anyways default is 15.6ms.

Some apps I know set it lower.
Apps usually return it to normal after exiting.
But I believe once you've set it to a low value (lower then what the apps would do probably), it stays that way, or so it seems.

The one script cmd with the value of 1 is the fastest, clockres will say it's 0.5ms.
To be honest, when I added the min and max ver's of it, I never did check for error codes ^^, oopsy.

Hmm...
The program may need to stay resident afterall.
Err yeah it does, shoot nuggets.

That and for some reason it's saying my default is 2.5ms on win7, I should restart and find out.
I'm gonna have to check this stuff out after I get some sleep.

Anyways you need autohotkey_l.
And here's a demo script, wokring because i just made it and tested it ;), sets up a loop which does nothing every 10 secs.

Code:

---


#Persistent
#SingleInstance, Force
#MaxMem 1
#MaxThreads 3
SetBatchLines -1
Process, Priority,, BelowNormal

GoSub Init

SetTimer, Burn_Cycle, 10000


Burn_Cycle:
return


Init:
DllCall("ntdll.dll\NtSetTimerResolution", UInt, 5000)                ;0.500 ms
return

---

This works very well on win8, it takes the stock 1000us dpc latency and makes it around 400-500us.
Try it and check again with clockres to ensure it set, and with dpc latency (leave this one running bg so you can see the difference)


Edit:
Your timer is way lower then normal... :)
That's neat...
Anyways you can get it a little lower, but it's not quite the same comming from 15.6ms lol.

Looks like one of the web pages had something on it that brought the interval down, probably Flash based.
Anyway... HPET's on now.
Without any applications running at all:

Code:

---

Maximum timer interval: 15.600 ms
Minimum timer interval: 0.500 ms
Current timer interval: 15.600 ms

---

On Youtube, no videos running:

Code:

---

Maximum timer interval: 15.600 ms
Minimum timer interval: 0.500 ms
Current timer interval: 1.000 ms

---

Note how it's gone from 0.977 ms to 1.000 ms, obviously more accurate.

I'll give your script a go. Someone wants 10 AUD for similar software, lol.
Why don't developers build something like this into their drivers?..

Quote:

---

Originally Posted by NEOAethyr

But I believe once you've set it to a low value (lower then what the apps would do probably), it stays that way, or so it seems.

---

That sounds nice. Assuming it doesn't get stuck or bugged out. Not a fan of running extra stuff in the background...

I don't like things running in the bg either.
Unless it has some use.
In this case I can understand wanting it to exit after setting the timer.
And keeping the timer at 0.5ms... (which runs fine)

Maybe it could be done by starting explorer from the script then exiting, as long as that instance of explorer is still running it may work.
I gotta try something...

Edit:
I just made a script to test a theory, unfortunately the results meant it needs to stay resident :(.
I bugged it with the runwait but that worked out to my advantage for testing it.

Code:

---

;#Persistent
;#SingleInstance, Force
;#MaxMem 1
;#MaxThreads 3
SetBatchLines -1
;Process, Priority,, BelowNormal

GoSub Init

;SetTimer, Burn_Cycle, 10000
;Burn_Cycle:
sleep 3000
return

Init:
DllCall("ntdll.dll\NtSetTimerResolution", UInt, 5000)                ;0.500 ms
RunWait %ComSpec% /C "explorer",,
return

---

My default timer is back at 15.6ms after starting back up.
So I supposed I could get some more testing done later (to check for errorlevels when setting below 0.5ms) :).

Right now I have it set to 0.5ms on startup of my networking tray icon script.
I haven't updated the code that I posted on the forum for that yet...
That's how I doit.
I made it do something...
But this sucks, now that I think about it, not being able to keep that timer setting unless the program that set it is still running :\.
Darn windows... :rolleyes:


One more edit: :)
I've been thinking a little.
One could make an asm ver of it.
Then disasm explorer.exe.
Find a function that only runs once, or better patch out the entry ptr or something simuler.
The checksums would not matter on my rig, but may on others, not a biggy to fix.
The function to patch out an how would need to be found on both 32 and 64bit os'es, both would simuler.
So everytime time explorer runs and stays running (a single instance of explorer is the norm), then it would stay at 0.5ms :).

This is up to anyone if you want me to check it out I guess.
That's if ah people want to go around hacking there explorer.exe...
I doit to keep the timer consistent and windows snappy as it can be(not quite yet..., but a step towards that).


What I'm really interested is other tweaks for dpc latency ;)
There's always the power management cpl reg tweaks and all (adding tons of settings), and disabling power management stuff in the bios and windows...
There's gotta be more then that.

My dpc latency is around 112us right now with opera in the bg and a single wallpaper on my desktop.
It goes lower then 100us, but it's no 20us and so on.

I've also noticed, not sure if I'm right.
Some boards seem to have different amounts of latency.
For ex., say you upgraded and the new board had higher latency then the old one.