[ntp:hackers] Non-monotonic time on NT

Terje Mathisen terje.mathisen at hda.hydro.com
Fri May 11 02:39:44 PDT 2007


peda at axentia.se wrote:
> I then want you to consider [1] to see exactly how bad the
> suggestion is. Granted, the mock-up resynchronizes 20 times
> more often than Dave suggested, but the error in d also has
> 20 times longer to propagate if you resynchronize at the
> suggested rate. So, the steps in the figure is as large as
> they would be with a 1 Hz resync.

I'll try to write down an english pseudocode version of what I'm trying 
to do!

This all happens in the realtime thread, OK?

The target for this thread is obviously to sample the TSC (or 
PerformanceCounter) as closely after each update to the OS filetime counter:

Given two samples, we have an estimate of the slope d, which is pretty bad.

With three samples, we can determine the slope between the first and 
last, and check if the middle one happened before or after the expected 
point in time, right?

With N samples, we can start by determining a very good estimate of d, 
by doing a straight line curve fitting to all the samples, then discard 
all the obviously late samples, i.e. those that happened after the 
average expected time, then redo the curve fitting.

This gives us the average slope over the total sample interval, to be 
used for extrapolation.

Then, on each new sample we check if the current count is more or less 
than the count expected by extrapolating from the last sync point.

If the count is less, then this was an early (i.e. good!) sample, and we 
use this as the new sync point. This can lead to a very small forwards 
jump in time.

Otherwise, this sample was slightly late.

In both cases the new sample will go into the N-sample filter, and 
slightly influence the calculated slope (d) value.

So what happens if/when the TSC frequency changes?

If the frequency is dropped, then the TSC count will be too low on every 
new sample, so each of them will be used as the new sync point, and 
after a number of new samples (up to N) has been gathered, the new slope 
(d) has been captured.

Going in the other direction, i.e. increasing the cpu frequency, the TSC 
count will be too high, but this gives us an easy way to determine that 
this has happened: When the count is so high that it corresponds to a 
full timer interrupt interval, then we know that the slope must have 
changed and it is time to discard (most of?) the history buffer and 
start over.

Anyway, to me this seems quite similar to the kind of code the PPS 
algorithms must use to determine which of the per-second samples are 
best, modulo our need to handle a variable pulse/sample frequency.

Terje

-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"


More information about the hackers mailing list