[ntp:questions] Time until synchronized

David Woolley david at ex.djwhome.demon.co.uk.invalid
Fri May 30 21:07:27 UTC 2008


Anton Persson A wrote:

> I've been trying to figure out a couple of details during
> the last few days concerning NTP/ntpd. I now have the
> following unanswered questions.
> 
> * The ntpdc -> kerninfo -> status bits, are these set
>   by NTP when it considers itself "synchronized"?

Yes.

> * If so, what are ntp:s criteria for setting it to 0001 (pll)?

The time source is not a special one (specifically modem clocks) for 
which PLL mode is not appropriate, and the measured offset is 
consistently within 128ms of the system time.

> * How long should it take for ntpd to reach "synchronized"/pll?

No more than about 20 minutes, and as little as under a minute, 
depending on whether this is a cold start and how far off the clock was 
on startup.  This can be compromised by trying to prevent the time being 
stepped.

> * Is three (3) days acceptable?

No.  If it thinks it is doing a warm start, but the saved frequency data 
is wrong (e.g. because someone, incorrectly, created /etc/ntp.drift 
manually, it may go through the 20 minute cycle several times, but it 
should lock up stably in minutes to hours, not days, unless something is 
broken.

As I asked you before, the output of ntpq peers and ntpq rv 0 and rv for 
each association, is much more useful than ntpdc kerninfo.

> * Can this time be improved in any way, if so, how?

Fix what is broken.  If you don't get your first synchronise within 
about 20 minutes, something is broken.

Don't use -x, or otherwise inhibit stepping.

Make sure that /etc/ntp.drift does not exist on the first start.

Make sure that the time is accurate to about a millisecond, or out by 
more than 128 ms, before you start ntpd.

Use of iburst can reduce the best case from about 5 minutes to under 1 
minute, but you should understand the sever load implications, and 
beware of any multiplexing  due to NATting.

Note that these get you to a synchronized state fairly quickly, but it 
can still take some time for the residual error to converge to the noise 
level, but generally less than three days.




More information about the questions mailing list