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. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions