[ntp:hackers] Non-monotonic time on NT

Danny Mayer mayer at ntp.isc.org
Mon May 7 19:31:22 PDT 2007


Peter Rosin wrote:
> Hi!
> 
>    [ Some years ago there was a mail exchange started by me (Peter
>      Ekberg back then when I was still a bachelor) about a problem in
>      ports/winnt/ntpd/nt_clockstuff.c and I provided a patch for it
>      (grantad, non-perfect, but better than the current code). The patch
>      wasn't very well received though (Danny Mayer didn't understand it
>      and said David Mills would need to comment on it, David Mills said
>      that Windows wasn't his table and also went on at length about why
>      thou shalt not filter the system clock). I have since moved away
>      from ntp hacking, but since I did find a real problem I thought I
>      should at least describe it as best I can. Then you can fix it (or
>      not) in any way you see fit. ]
> 

Hi Peter, I have a vague recollection of this. The reason that I defer
these kinds of things to Dave Mills is that this is not my area of
expertise.

Martin or Heiko might be able to make respond to this better than me and
I'd still like to have Dave to voice his opinion.

Danny

> The system time on windows takes rather big steps (typically 100Hz, but
> 1000Hz and 64Hz are also not impossible, it just varies from system to
> system). David Mills says that these steps are not a problem for the ntp
> core, but for some reason code has been added for winnt which tries to
> extrapolate a "better" time using the performance counter, as
> illustrated by [1] showing the case of a 64Hz system time update.
> 
> However, the ntpd code does not live up to the ideal situation of [1],
> and the reason is found in the support code for the gettimeofday
> replacement for winnt. Basically a high priority thread polls the system
> time at 1 ms intervals and checks if the system time has changed. If it
> has, update the base from which the performance counter is used to
> extrapolate in future calls to gettimeofday.
> 
> So, on a good day (i.e. when the above poll really happens at 1000Hz),
> you get this [2] plot for the gettimeofday replacement. Looking really
> closely at this, one sees that the reported time takes small steps
> backwards on three of those steps, and forward on one of them (the 2nd).
> (I know, the picture isn't top quality...)
> 
> As if that is not bad enough, there is no guarantee that the poll really
> happens at 1 ms intervals. If the computer is "busy" with other things
> and the poll happens later than intended, it might e.g. look like [3].
> 
> Figures [1], [2] and [3] are mock-ups, made from memory, but on occation
> I did see gettimeofday go backwards (which was why I started to dig into
> the code in the first place) and I'm very convinced they represent what
> is really going on.
> 
> Big question follows: Is the rest of ntpd ready for a gettimeofday that
> steps backwards? And forward for that matter?
> 
> Further, looking at ntpd/ntp_proto.c:default_get_precision() reveals
> that the precision of winnt systems will often be misreported as (some
> relation to) the precision of the performance counter, but that's
> completely bogus IMHO. The precision can't be better that 1 ms since
> that's how often the system clock is polled (on a good day) in the
> extrapolation, and there is no control on how good the sample is. On a
> bad day the precision might be reported as several ms (if time was
> stepped forward just as default_get_precision() did its thing) on the
> same system that reported a precision of a few us on the previous run.
> (this one I haven't noticed happen, but I don't think I'm that bad at
> reading code... Famous last words and all thst...)
> 
> Cheers,
> Peter
> 
> [1] http://www.lysator.liu.se/~peda/ntp/ideal_day.gif
> [2] http://www.lysator.liu.se/~peda/ntp/good_day.gif
> [3] http://www.lysator.liu.se/~peda/ntp/bad_day.gif
> 
> PS. Feel free to copy this info into bugzilla, if you like.


More information about the hackers mailing list