[ntp:hackers] Non-monotonic time on NT

Terje Mathisen terje.mathisen at hda.hydro.com
Mon May 7 14:40:00 PDT 2007


hackers-bounces+terje.mathisen=hda.hydro.com at support.ntp.org wrote:
> David J Taylor wrote:
>> I'm not missing the point - I'm asking a question, which I 
>> don't believe you have yet answered.  I suggest that you test
>> again with the MMtimer permanently enabled, and see if the
>> problem remains.
> 
> I do not know if the MMtimer was disabled or not, but don't
> think anything meddled with it. At least, I did not do it
> intentionally to provoke the problem. How would I know if the
> MMtimer is permanently enabled or not?
> 
> However, the above is of no consequence here, as the problem
> stares at me when I'm reading the code. I don't want to be hit
> by a bug, however seldom it rears its head. In fact, bugs that
> trigger seldom is far worse in my book, as they tend to show at
> the worst possible time but never when you actively look for them.
> 
> So, my answer is: of course the problem remains even if the
> MMtimer is permanently enabled.

I understand why David is asking, and the problem might well be less in 
that case, but I agree with you that the interpolation code is a kludge.

OTOH, it is a somewhat better kludge than the equivalent code I wrote 
around the same time, and it does improve the stability of the local 
clock on an NT machine acting as a client only.

So what can we do?

a) Assuming very rapid calls to gettimeofday(), it is quite likely that 
you could see occasional backwards steps, but this probably doesn't matter!

The only thing that happens after a slightly bogus timestamp is that the 
corresponding sample is less likely to be accepted, but as long as the 
overall statistical properties are maintained, the resulting system 
clock will indeed be pretty good.

If there were some other processes that used the ntp-internal 
interpolated timestamps directly, then an occasional glitch would be a 
_bad thing_, but as this is a private ntp clock, it is OK.

b) If we really do need to make the interpolated clock as accurate as 
possible, then we'll have to use ntp-style statistical processing in the 
realtime interpolation thread!

Referring back to your nice figures, it is obvious that we can use an 
algorithm very similar to the huff-puff filter to discard those samples 
were the realtime thread was woken up slightly too late, since these 
will have a RDTSC value offset from (i.e. too large) the expected range.

Simply running a 16-sample (or N-sample) median filter like the PPS code 
uses would allow us to discard outliers, while extrapolating time from 
the last good sample, instead of always using the most recent polling value.

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