[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"?
> > * 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
> 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/22.214.171.124-hrt1-WR2.0bl_standard", leap=00,
stratum=4, precision=-19, rootdelay=2.367, rootdispersion=68.721,
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,
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
Yes, without the -x option we get to synchronized quite fast.
More information about the questions