Windows 8 High DPC latency Fix

Btw did you check all page of CPUID? In my localized AIDA64 'Invariant TSC' is almost at the bottom. And if your CPU does not support it the checkbox is there but unchecked.

 

Vista tries to use HPET without testing anything (invariant TSCs were not available then)
Windows 8 uses the same procedure as Windows 7, and besides allowing you to set useplatformclock, also allows you to explicitly set tscsyncpolicy and useplatformtick. Shall we open even more Pandora's Box? :roll:

Very good questions! But I'm really settled on bcdedit /deletevalue useplatformclock

 

yes its constant, but it shows 3.682Ghz instead of 2.66ghz?, while my Oc is 3.632Ghz, this is with dynamic tick off and hpet on (bios) and useplatformclock true atm.

Although that time for query perf. call is ~ 520us.


Edit: Im gonna try this delete value one more time

Ok now it looks like windows HPET is off, primary timer is ~ 3.54mhz and that time for query perf. call ~ 14us.

 

Ok well Im gona give ago with the Hpet on in the bios and bcdedit /set useplatformclock false

As of now only difference I See with True and False is With True Time For QueryPerformanceCounter is 750ns VS about 11ns with False.

Other then the Hpet on and off in Bios and TRue and False in windows all show the same Clock speed of 2653 give or take a mhz or .

 

Folks, you don`t need to bother about that stuff because you don`t do real-time tasks at you rigs, right? Main thing is well-synced timers...

750 microseconds is less the 1 millisecond...

Edit: Wait... milliseconds? Mine shows nanoseconds - time for QueryPerformanceCounter() call...

 

well i did that and was getting 1500+ us interupt process spikes in latencymon

So i just went back to Hpet 64bit + True in Win 7 pc been working fine so just gona leave it as it is. In all honestly common person should never have to touch or play with these settings.

Unless I rebuild my pc with all new Mobo and CPU im just gona leave setting as is as this is how it works best for me

True=750ns give or take
False= 11 ns give or take

But like I said when I did False or Delete of that value I was getting 1500us interupt process latency in latency mon

 

But are we common persons here? :nerd:

 

here? haha hell no ever one here to point is extremist me to much less extent of most people here. but ya

 

You realize that second sentence does undo first one, right?

Edit: Oops... Never mind - I just misinterpreted the 'leave setting'...

 

I Found the best combo is HPET on Bios and HEPT off On windows but that's just my set up.

 

Bottom line fine what works best and leave it be, every machine is diffrent

 

Unfortunately, no... High latency external timers (like HPET) are also problematic. I'm guessing noone read the blog post yet! Shall I link it for the 5th time?

So, the best case scenario is always to have HPET enabled in BIOS and bcdedit /deletevalue useplatformclock as that guarantees you:
1) use of the invariant TSC(s) if your CPU supports it correctly (RESET line properly implemented for syncing)
2) a fall back to HPET if it doesn't, which is the next best compromise.

For DPC latency, you can try toying with disabledynamictick, as that will probably be the main cause for DPC latency increases (due to hardware timer interrupts being delayed so that a CPU can stay more time on a low power state) - but please note that dynamic ticks are only used when there are CPU cores in low-power states, so it should't have any effect on DPC latency when the CPU has a normal load.

 

'When gathering high volume events such as the CSwitch, ReadyThread, ISR and DPC, using QPC for timestamps in ETW generates significant overhead.
...
When the ETW tracing infrastructure is used to gather OS kernel scheduling events, it is probably the most frequent caller of the API on the machine.'

'ETW lets you enable or disable event tracing dynamically, allowing you to perform detailed tracing in a production environment without requiring computer or application restarts.'

If Windows does that ETW activity every second 24/7 then high latency QPC becomes a culprit. If ETW activity is mainly toggled by user (ETW consumers) then high latencies of QPC is of no importance. I really don`t know about default ETW level in OS...

Add:
'Providers

Providers are applications that contain event tracing instrumentation. After a provider registers itself, a controller can then enable or disable event tracing in the provider. The provider defines its interpretation of being enabled or disabled. Generally, an enabled provider generates events, while a disabled provider does not. This lets you add event tracing to your application without requiring that it generate events all the time.'

 

There is one issue thou, it doesn't sync between cores.

 

They are guaranteed to be in-sync, that was one of the problems invariant TSCs solved.

 

Another tool (with sources!)
http://www.nvidia.com/object/timer_function_performance.html

 

On paper sure

 

Those are different problems. The 2nd paragraph deals with the nefarious effects of having the OS postpone a write to a counter, to attend something else - this can happen with any counter, HPET included.

 

Sorry for my noob question, but ¿wich is the ideal scenario of all 4 pictures

and why?

Bye all and great post

 

Well, ideal is when games run the smoothest on a rig, ensuring the player more frags.