You cannot measure to 1 nanosecond, you cannot measure to 10 nanosconds either. This is because each action of measurement
requires a call of some kind. One of the fastest APIs is
GetSystemTimeAsFileTime(). A call requires 10-15ns. But it's resolution/granularity is rather poor (in the ms regime). QueryPerformanceCounter() delivers frequencies in the MHz to GHz range, depending on the underlaying hardware. This call is not as fast but at 1MHz you get 1 microsecond resolution. At such a frequency, given by QueryPerformanceFrequency(), consecutive call will may return equal values because the call is faster than the increment rate.
Another source is the CPU time stamp counter (rdtsc). But there are some drawback with it too: Modern hardware implements adpative CPU frequency. Therefore this frequency cannot be considered as a constant. This way measurements are only posible during constant phases.
In fact none of the frequency sources delivers a constant frequency. All of these frequencies are generated by some hardware which has offset and drift
. So the OS will return a value for QueryPerformanceFrequency or CPU frequency and makes you believe it is a constant. However, the number you'll get are only close estimates
.
Real accurate timing can only be performed when these frequencies are calibrated against the systems RTC. See this publication for more detailed information about accurate timing on windows.
Edit: Windows chooses the Time Stamp Counter
of the cpu. In such cases the result of QPF() equals the processor speed divided by a fixed number (1024 in your case). Windows chooses to built the timekeeping around the TSC with preference when a constant/invariant TSC is available. 3.33 GHz/1024=3.25 MHz.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…