My experimental stratum-1 server (using a Garmin GPS as its reference clock)
continues to run stably -- albeit with an offset several msec different from
the rest of my home LAN (which is synced to Stanford University's time server
infrastructure).
remote refid st t when poll reach delay offset jitter
==============================================================================
oGPS_NMEA(0) .GPS. 0 l 2 8 377 0.000 -0.001 0.002
PPS(0) .PPS. 9 l 6 8 377 0.000 0.000 0.002
*iknow.richw.org 171.64.7.115 3 u 10 16 376 10.058 -9.249 3.871
In an attempt to compare my results with something (and get some idea of
which of us -- the campus server or my own -- is more likely correct), I
set up a second test server here at home, using a Conexant HCF modem (a
PCI device) phoning NIST in Colorado. The results from this setup appear
disappointingly unstable (several msec jitter even after running all night),
but the modem refclock seems to be more in agreement with the campus clock
than with mine. Here are a few "ntpq -p" outputs from this second system
(I've omitted some of my home LAN systems from the peer list to reduce
clutter somewhat).
remote refid st t when poll reach delay offset jitter
==============================================================================
*sixeyes.richw.o .GPS. 1 u 13 16 376 0.103 0.327 0.018
+iknow.richw.org 171.64.7.115 3 u 60 64 376 10.593 -8.087 1.696
ACTS_MODEM(0) .NIST. 0 l 273 512 277 0.000 -5.147 3.674
remote refid st t when poll reach delay offset jitter
==============================================================================
*sixeyes.richw.o .GPS. 1 u 5 16 377 0.097 0.127 0.014
+iknow.richw.org 171.64.7.115 3 u 9 64 377 9.888 -10.077 2.085
ACTS_MODEM(0) .NIST. 0 l 185 512 377 0.000 -16.325 10.689
remote refid st t when poll reach delay offset jitter
==============================================================================
*sixeyes.richw.o .GPS. 1 u 4 16 377 0.099 0.158 0.057
+iknow.richw.org 171.64.7.77 3 u 2 64 377 8.919 -9.841 1.103
ACTS_MODEM(0) .NIST. 0 l 120 512 377 0.000 -5.147 5.961
The 171.64.7.* hosts in the above are stratum-2 servers at Stanford,
which are in turn syncing to 171.64.7.87, a stratum-1 server with a
TrueTime GPS receiver. Also, the delay reaching iknow.richw.org (on
campus) is because I'm going through a cable modem -- but all my
boxes are running ntp-dev and using xleave, which is why jitter to
iknow.richw.org is low.
I also checked the "clockstats" data on the server with the modem,
and it reported timestamps ending in "#" (delay correction valid).
I can post some of this data if anyone thinks it would matter.
So, at this point, what basis (if any) would I have to conclude that
my test server is or isn't accurate? And if it isn't accurate, what
should I do to fix the problem? Or, if the campus server is likely to
be the falseticker, how would one go about establishing that fact?
In case it might matter, I checked the geographical coordinates being
output by my GPS against a satellite photo from Google Maps, and it's
showing my exact location to within a few feet. And the GPS claims to
be consistently seeing at least seven satellites. So I would assume
my GPS unit is working properly -- except for the above evidence that
seems to suggest its time is off.
Any thoughts or suggestions welcomed.
--
Rich Wales / ri...@richw.org / ri...@stanford.edu
Wikipedia: http://en.wikipedia.org/wiki/User:Richwales
Facebook: http://www.facebook.com/richwales
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
