[ntp:questions] ntpdate.c unsafe buffer write

David Woolley david at ex.djwhome.demon.co.uk.invalid
Sun Feb 10 10:55:29 UTC 2008


Harlan Stenn wrote:

> In the case I describe, at the end of that O(11 second) period the clock is
> Real Close (ie, the offset is "low enough"), the frequency drift is known
> and compensated for, and ntpd is in "state 4".

As I read 4.2.4p4, for a warm start, the clock is within 128ms on exit. 
However, if it wasn't stepped, because it was already within 128ms, it 
will be slewing at maximum rate.  Allowing 100ppm for motherboard 
tolerances, that means that it can take up to a further 320 seconds to 
reach the low milliseconds.  I don't believe it would be safe to start 
ntpd in normal mode within that period.

For a cold start, it won't reach state 4 for a further 900 seconds after 
first priming the clock filter.

The 128ms is the tinkerable clock_max value, so it would be possible to 
configure for a tighter tolerance, but that probably means using 
different config files for start and run.  The 900 is also the 
tinkerable clock_minstep.  Note that setting clock_max to zero really 
sets it to infinity.

Tinkering comes with the comment:

    Special tinker variables for Ulrich Windl.  Very dangerous.

The best advice for someone trying to simulate ntpdate -b is probably to 
make sure that the clock is wrong by at least 128ms before starting. 
That way, you should get a step, even with the default configuration.




More information about the questions mailing list