The operative word here is should. There are stilt many drives that are badly coded despite the many efforts of Microsoft to make it harder to be stupid
Hook a profiler and see what else runs on your specific machine. Also try your tests on different hardware and note the differences
Sent from Surface Pro
From: xxxxx@gmx.de
Sent: Tuesday, February 24, 2015 2:58 AM
To: Windows System Software Devs Interest List
An ISR should not do much: Read the interrupt register from the hardware to check whether the interrupt came from me. Acknowledge the interrupt on the hardware. Schedule the DPC. I hoped, that this is faster than the 50 us I saw.
It could equally the clock on his device, but given the size of the distortions, it seems more likely to be software. I know nothing about the exact hardware he is using, but modern systems don’t generally suffer from clock skew during sleep states or between cores
Sent from Surface Pro
From: xxxxx@Freyberger.de
Sent: Wednesday, February 25, 2015 2:36 AM
To: Windows System Software Devs Interest List
Couldn’t this deviation also be caused by the source of KeQueryPerformanceCounter? Looking at the given frequency the source doesn’t seem to be the HPET and so I think the returned value could slightly change after switching the core of a multicore CPU or the different sleep states?
Which suggests that the delays you see are real and not the effect of how you are measuring. As Tim mentions this is expected on Windows, but if you want to find out what runs during those times, hook up a profiler and see
Sent from Surface Pro
From: xxxxx@gmx.de
Sent: Thursday, February 26, 2015 3:49 AM
To: Windows System Software Devs Interest List
I checked the timestamp source. Coreinfo.exe returns:
RDTSCP * Supports RDTSCP instruction
TSC * Supports RDTSC instruction
TSC-DEADLINE * Local APIC supports one-shot deadline timer
TSC-INVARIANT * TSC runs at constant rate