Re: how to analyze clock drift

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 23 Nov 2014 20:15:36 -0500, Dennis Lee Bieber wrote:

[...]
> 	One thing not seen in the above, is that under Windows, there are
> uncontrollable events that will throw a data point out to the extreme...
> Look at the millisecond data (0.001). The max latency was 5.1E-4, while the
> mean was 2.9E-6. In a run of 500 samples, only 2 or 3 data points jumped to
> that high value. That's a sign of the OS doing some house-keeping and
> blocking the program from responding. But to see it requires plotting the
> data -- once seen, one can attempt to explain that data point. Excluding
> those data points will bring the mean down a small amount, but will reduce
> the standard deviation significantly.

A few notes:

1. It is impossible under Windows (Win32) to wait (non-busily) for a time
period shorter than 1ms. This is the highest possible resolution (but not
accuracy) of all waitable services.

Furthermore, depending on the Windows version, you should probably change
the minimum timer resolution. The function for this is timeBeginPeriod from
winmm.dll. 

http://msdn.microsoft.com/en-us/library/windows/desktop/dd757624%28v=vs.85%29.aspx

I don't remember of Win32Ada include it, but it is no problem to call it
without bindings.

2. If there is an assumption that some other processes intervene, you could
change the priority of the task. E.g.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686277%28v=vs.85%29.aspx

Setting THREAD_PRIORITY_TIME_CRITICAL blocks practically everything (except
for drivers).

However I doubt that background processes or services are the problem when
waiting for 10 or 5ms

The rule of thumb for Windows is that anything below 5ms is unreliable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de