20031009: clocks are way off (cont.)

>From: Eirh-Yu Hsie <address@hidden>
>Organization: Aeronomy Laboratory/NOAA
>Keywords: 200309291535.h8TFZhk1020058 IDD ntpd ntpdate clock

Hi Hsie,

re: your clock is off

>I am running ntpd to synchronize all my computers to NIST clock.  All my 
>computers are within +- 2 sec.

Yes, but it is strange that it would be that far off.  Since you are
setting it off of the NIST clock, it should be within a few
milliseconds, not 2 to 3 seconds.  I have seen this kind of "problem"
(your clock was the best of the three that I sent out the note for), on
systems running ntpd.  What we do internally is have one machine
running ntpd and have our other machines set their clock off of this
machine (timeserver.unidata.ucar.edu) by running ntpdate from root's
cron once per hour.  With this setup, we keep clocks on our PCs (and
PCs are the ones with the worst clocks) accurate to a fraction of a
second.

From: Eirh-Yu Hsie <address@hidden>
Date: Thu, 09 Oct 2003 08:25:13 -0600

>Look at the figure you provided, the Latency from rainbow is not that 
>bad (3 sec ???).

Right.  Ordinarily, I wouldn't have bothered you with the email since
rainbow's clock is accurate to within 3 seconds.  Since I was composing
an email to U Illinois and Texas A&M, I figured I would include you
in case you were running ntpdate from root's cron, but it was not
being run often enough.  Our suggestion especially on PCs is to run
ntpdate once per hour (or more frequently if needed), not ntpd. 
The reason for this is that on some hardware ntp cannot compute an
accurate drift, so the clock will never converge.  We just logged onto
rainbow and took a look at your drift file, /etc/ntp/drift, and see
that it has a value of 0.000.  This is clearly wrong given that your
clock is off by 2-3 seconds after 6 hours of drifting.

Compare the latencies being reported by rainbow with those being
reported by blizzard.al.noaa.gov, a Sun SPARC.  You will see that
the PC rainbow is not able to keep its clock as accurate as the
SPARC machine.

We logged onto rainbow to check out your ntpd setup, and see:

- /etc/ntp.conf has the line 'multicastclient' uncommented.  This
  means rainbow is listening to multicasts for time.  Is the multicast
  a NIST multicast?

- /etc/ntp.conf has:

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

  This says that in the absence of any better clock, use "my" (rainbow's)
  clock.

- we ran /usr/sbin/ntpdc and do not see a "better" clock than rainbow:

% /usr/sbin/ntpdc
ntpdc> peers
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*LOCAL(0)        127.0.0.1       10   64  177 0.00000  0.000000 0.06343

ntpdc> peers
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*LOCAL(0)        127.0.0.1       10   64  177 0.00000  0.000000 0.06343
ntpdc> sysinfo
system peer:          LOCAL(0)
system peer mode:     client
leap indicator:       00
stratum:              11
precision:            -16
root distance:        0.00000 s
root dispersion:      0.07364 s
reference ID:         [127.127.1.0]
reference time:       c32ffb54.41800a7c  Thu, Oct  9 2003  9:20:52.255
system flags:         bclient auth monitor ntp kernel stats 
jitter:               0.000015 s
stability:            0.000 ppm
broadcastdelay:       0.007996 s
authdelay:            0.000000 s

  This says that the clock you are synced to is the local (rainbow's)
  clock.

  You could change this by adding a 'server' line to /etc/ntp.conf
  that points to a good local timeserver.  Here is an example:

server  132.163.4.101   version 2       # time-A.timefreq.bldrdoc.gov

All of the above says that rainbow's clock is essentially floating.
This is why it is not accurate to any better than 3 seconds over 6
hours.

Given this, we recommend that you either add the additional 'server' line
to your /etc/ntp.conf file, or not run ntpd on rainbow, but, rather,
run ntpdate from root's cron.  Here is an example invocation:

#
# Set the system clock
#
0 * * * * /usr/sbin/ntpdate timeserver > /dev/null

Here, 'timeserver' is the name of the time server you are setting
your clock form now.

Cheers,

Tom