RTT, NTP time
I was looking at the RTT code (still don't see what the problem is).
BUT It's worth pointing out that NTP must be working properly to get
accurate time, otherwise the RTT values are skewed by a significatnt
amount.
On Linux, "ntptrace" should show a clean trace back to a stratum 1
time server (GPS or atomic clock). Newer distros may have firewall issues,
but should still show a good trace to the adjacent server, even if they
can't check further upstream. Offset should be a few milliseconds at most.
e.g. (Good - public NTP servers)
$ ntptrace
localhost: stratum 3, offset 0.000013, synch distance 0.08220
cuckoo.nevada.edu: stratum 2, offset 0.001163, synch distance 0.02295
clepsydra.dec.com: stratum 1, offset 0.005873, synch distance 0.00151,
refid 'GPS'
(Good - adjacent server OK but firewall stops client seeing stratum 1)
$ /usr/sbin/ntptrace
localhost.localdomain: stratum 3, offset 0.001284, root distance 0.001734
trprint.triumf.ca: stratum 2, offset 0.000014, root distance 0.000452
142.90.119.35: timed out, nothing received
***Request timed out
(Good - onsite GPS clock)
$ ntptrace
localhost: stratum 3, offset 0.000025, synch distance 0.03596
tgate.triumf.ca: stratum 2, offset 0.000975, synch distance 0.01073
gpstime.triumf.ca: stratum 1, offset -0.021169, synch distance 0.00002,
refid 'GPS'
(Bad - no adjacent servers - clock is 12 seconds out)
mokash.ns.uvic.ca: stratum 16, offset 12.167266, synch distance 75.91002
0.0.0.0: *Not Synchronized*
(Bad - adjacent server time is wrong - clock is 3 minutes out)
lg.up.univ-mrs.fr: stratum 6, offset -176.343556, synch distance 0.03436
147.94.112.6: stratum 5, offset -176.344450, synch distance 0.03162
imtsun8.imt-mrs.fr: *Timeout*
(Stratum 6 is a long way from a master time source; usually machines are
at stratum 4 or less. I seem to remember some guideline of a factor of
100 per stratum, but I'm sure some of the public machines have lots more
- e.g. RedHat's default clock.redhat.com seems to be a stratum 1)
Note that ntpd may refuse to re-sync clocks that are too far wrong.
Normally the startup script calls "ntpdate" to set the system clock
initially, but if a firewall or dead server prevents the time from being
set properly ntpd may still run yet not sync.
I wrote a web page for Y2K to check browser clocks; it seems to be still
working, and will show how far out your desktop clock is. I didn't allow
for trip time to the browser, so it may show a second or two off when you
are in fact correct. http://vancouver-webpages.com/time/
--
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376
security@triumf.ca