[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