[ntp:questions] Default config on Ubuntu doesn't work as client

Michael B Allen miallen at ioplex.com
Mon Mar 10 22:37:45 UTC 2008


On 10 Mar 2008 19:43:34 GMT
Steve Kostecke <kostecke at ntp.org> wrote:

> On 2008-03-10, Michael B Allen <miallen at ioplex.com> wrote:
> 
> > Steve Kostecke <kostecke at ntp.org> wrote:
> >
> >> The output of 'ntpq -pcrv' is what we need to see.
> >>
> >> BTW: You should append 'iburst' to your server lines to speed up
> >> initial sync from a bit over 5 minutes to a bit less than 20 seconds
> >> (assuming no other issues exist).
> >
> > Output of ntpq:
> 
> [snip]
> 
> > refid=INIT, reftime=00000000.00000000  Thu, Feb  7 2036  1:28:16.000,
> > poll=6, clock=cb7fdd9b.a61cc7fd  Mon, Mar 10 2008 12:17:31.648, state=1,
> 
> Your ntpd is stuck in its early start-up stages.
> 
> >  remote       refid      st t when poll reach delay  offset jitter
> >===================================================================
> >nano.foo.net 69.31.13.210  3 u   13   64    1  0.364 -420416  0.001
> 
> Although this was taken a bit prematurely (i.e. right after ntpd was
> started) ...
> 
> We can see that the remote time server is answering your polls. So we
> can probably rule out a network problem.
> 
> The offset is excessive. It may be because ntpd has not run long enough
> to poll the remote time server and determine that a step is required.
> 
> You should either (a) start ntpd with -g to allow a large initial
> time step, or (b) preset the clock with 'ntpq -gq' (or the deprecated
> ntpdate) before starting the daemon instance of ntpd
> 
> > Mar 10 12:17:17 ls3 ntpd[5924]: frequency initialized 0.000 PPM \
> >	from /var/lib/ntp/ntp.drift
> 
> A driftfile containing 0.00 is not a good sign.
> 
> Please add the '-g' command-line argument to your ntp init script (if it
> is not already there) then (a) stop ntpd, (b) delete the driftfile, and
> (c) start ntpd.
> 
> Make sure ntpd is allowed to run undisturbed until a non-zero value is
> written to the driftfile (this may take an hour). Your ntpd will spend
> about 20 minutes testing the clock to determine the needed frequency
> correction. This is the value which is written to the driftfile. Once
> the test is complete ntpd will be able to synchronize its time sources.
> 
> ntpd will synchronize quickly to its time sources on subsequent
> start-ups when your drift file contains a "good" frequency correction
> value.

I stopped ntpd, deleted the drift file, ran 'ntpdate 192.168.2.15',
verified that the time was sync'd and started ntpd.

Ninty minutes later the time is ahead of the time server by 36 seconds.

# ntpq -pcrv
assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.4p0 at 1.1472-o Thu Oct  4 20:58:45 UTC 2007 (1)",
processor="i686", system="Linux/2.6.22-14-server", leap=11, stratum=16,
precision=-20, rootdelay=0.000, rootdispersion=98.190, peer=0,
refid=INIT, reftime=00000000.00000000  Thu, Feb  7 2036  1:28:16.000,
poll=6, clock=cb8034d0.c2c6254f  Mon, Mar 10 2008 18:29:36.760, state=0,
offset=0.000, frequency=0.000, jitter=0.001, noise=0.001,
stability=0.000, tai=0
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 nano.foo.net    69.31.13.210     3 u   37   64  377    0.637  -30672. 1355.63

Restarting ntpd shows:

Mar 10 18:33:10 ls3 ntpd[6545]: ntpd 4.2.4p0 at 1.1472-o Thu Oct  4 20:58:45 UTC 2007 (1)
Mar 10 18:33:10 ls3 ntpd[6546]: precision = 1.000 usec
Mar 10 18:33:10 ls3 ntpd[6546]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Mar 10 18:33:10 ls3 ntpd[6546]: Listening on interface #1 wildcard, ::#123 Disabled
Mar 10 18:33:10 ls3 ntpd[6546]: Listening on interface #2 lo, ::1#123 Enabled
Mar 10 18:33:10 ls3 ntpd[6546]: Listening on interface #3 eth0, fe80::20c:29ff:fe82:21c2#123 Enabled
Mar 10 18:33:10 ls3 ntpd[6546]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
Mar 10 18:33:10 ls3 ntpd[6546]: Listening on interface #5 eth0, 192.168.2.23#123 Enabled
Mar 10 18:33:10 ls3 ntpd[6546]: kernel time sync status 0040
Mar 10 18:33:10 ls3 ntpd[6546]: frequency initialized 0.000 PPM from /var/lib/ntp/ntp.drift

After hearing your description of "testing the clock" I have to wonder
if the fact that the server is running in VMWare matters. The clock
drifts quite a bit (e.g. 36 seconds in an 90 minutes). Could the fact that
Ubuntu is running in VMWare Server be a problem?

Mike




More information about the questions mailing list