[ntp:questions] Time until synchronized

Anton Persson A anton.a.persson at ericsson.com
Mon Jun 9 10:17:59 UTC 2008

> David Woolley wrote:
> > Anton Persson A wrote:
> > I've been trying to figure out a couple of details during the last
> > 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.

ntpq> rv 0
assID=0 status=06f4 leap_none, sync_ntp, 15 events,
version="ntpd 4.2.4p0 at 1.1472-o Sat Dec  1 06:59:06 UTC 2007 (1)",
processor="ppc", system="Linux/", leap=00,
stratum=4, precision=-19, rootdelay=2.367, rootdispersion=68.721,
peer=59945, refid=,
reftime=cbf76e3a.35b92725  Mon, Jun  9 2008  8:54:18.209, poll=6,
clock=cbf76f25.47f90c7d  Mon, Jun  9 2008  8:58:13.281, state=4,
offset=1.835, frequency=13.325, jitter=0.041, noise=0.015,
stability=0.007, tai=0

These are quite OK values, are they not?

> > * 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.

This was infact enabled by default, for some reason. By disabling it I
to get "synchronized"/pll status in "kerninfo".

> 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.

So, what you are saying: the time offset should not be in the 1ms <
128ms interval? Why is this important, and
what happens if it IS within this interval?

> 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
> 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.

Yes, without the -x option we get to synchronized quite fast.

   Kind regards,

More information about the questions mailing list