[ntp:questions] Time until synchronized

David Woolley david at ex.djwhome.demon.co.uk.invalid
Tue Jun 10 07:11:03 UTC 2008

Anton Persson A wrote:

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

All of these are useful.  ntpq peers gives an overview and makes it easy 
to see if you are synchronized.
> ntpq> rv 0
> assID=0 status=06f4 leap_none, sync_ntp, 15 events,

You are synchronized.  You don't need to wait any longer.

> event_peer/strat_chg,
> 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
>>> * 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
> managed

That may be a problem with the (human) packager.  -x is undesirable for 
NTP, but  prevents grief with software that absolutely cannot stand 
backward time steps.  Packagers tend to chose options that are least 
likely to result in support calls, rather than those that are optimum.

> to get "synchronized"/pll status in "kerninfo".

The reason I mentioned -x is that, if you start with a large time error, 
you cannot synchronise until that has been cleared by slewing, which can 
take an arbitrarily long time.  However, setting -x is equivalent to 
setting a parameter value that is incompatible with the kernel PLL, so 
the time discipline is run in user mode.  The time is still adjusted, 
but the offset sawtooths around the correct value, by a small amount.

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

If it is within that interval, it is too accurate for an initial step 
and not as accurate as it might be immediately after an initial step, so 
you will have to wait for the error to converge from the initial value 
to around 1ms or less.  Having it greater than 128ms, with the standard 
configuration (no -x, no tinkers) forces an initial step.

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

With -x you will also get to synchronised quite fast, but you will never 
get the kernel PLL turned on.  You will be using a user space PLL.

More information about the questions mailing list