-----Original Message-----
From: Dave Hart [mailto:[email protected]]
Sent: Saturday, July 07, 2012 7:14 PM
To: Justin Piszcz
Cc: [email protected]
Subject: Re: [Pool] X9SCM-F-O clock drift +1 second into the future when ntp
running?
> My guess would be the NMEA output is starting relatively late the UTC
> second and continuing into the next second. Using NMEA from a GPS
> without also using the PPS signal is difficult at best -- you're
> depending on the NMEA emission being consistently offset from UTC,
> which it is not with many receivers. With some, NMEA timing wander
> hundreds of milliseconds relative to UTC. If you're lucky and that
> unit has stable NMEA timing, you should be able to fudge it into
> submission. Try:
fudge 127.127.28.0 time1 -0.985
--
> ntpd doesn't discpline the CMOS clock. As long as your OS clock runs
> within 500 PPM of nominal, ntpd should manage it. Errors introduced
> each boot by the wayward CMOS clock will get stepped away early by
> ntpd (or ntpdate, if it's run before ntpd).
OK, thanks.
--
Hi,
I am able to use the GPS (thus far) with that fudge of -0.985 on the
X9SCM-F:
# ntpq -pn
remote refid st t when poll reach delay offset
jitter
============================================================================
==
*127.127.28.0 .SHM. 0 l 7 16 377 0.000 25.168
51.466
+64.6.144.6 128.252.19.1 2 u 34 64 1 74.498 77.264
69.854
+204.235.61.9 209.51.161.238 2 u 31 64 3 46.668 65.476
67.756
+108.61.73.244 129.7.1.66 2 u 30 64 3 24.246 71.441
68.162
+67.18.187.111 129.7.1.66 2 u 1 64 7 50.851 94.044
89.377
I did see this from the kernel on June 30th (normally it happens on December
31):
Jun 30 19:59:59 atom kernel: [144126.759010] Clock: inserting leap second
23:59:60 UTC
Unsure if this could be causing any issues as this was a recent change.
Here is the ntp output from a Supermicro X8DTH-6F:
$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
============================================================================
==
+38.109.218.175 192.43.244.18 2 u 25 64 1 57.070 -2.652
2.037
-96.44.157.90 173.244.211.10 3 u 24 64 1 82.532 -9.315
0.635
*205.196.146.72 128.59.39.48 2 u 23 64 1 39.337 -5.478
0.736
+169.229.70.95 128.32.206.55 2 u 22 64 1 84.710 -7.677
0.703
The delay and jitter are very low (with no special fudge time)
Here is the ntp output from an old Dell P733mhz box (no special fudge time):
$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
============================================================================
==
*66.178.0.74 .GPS. 1 u 70 1024 177 36.040 0.351
1.230
+108.61.73.243 209.51.161.238 2 u 1010 1024 377 29.065 -0.025
0.768
-96.44.157.90 173.244.211.10 3 u 1072 1024 377 93.172 -1.143
0.774
+199.101.103.82 133.243.238.243 2 u 603 1024 377 93.458 2.639
0.588
Some ~5 minutes later, the same system (X9SCM-F)
# ntpq -pn
remote refid st t when poll reach delay offset
jitter
============================================================================
==
*127.127.28.0 .SHM. 0 l 1 16 377 0.000 285.814
51.660
+64.6.144.6 128.252.19.1 2 u 63 64 77 72.052 316.644
209.681
+204.235.61.9 130.207.244.240 2 u 55 64 177 46.634 308.658
210.028
+108.61.73.244 129.7.1.66 2 u 50 64 177 23.992 318.532
213.599
+67.18.187.111 129.7.1.66 2 u 28 64 377 52.303 336.487
215.653
It is nice I can use the GPS now (thanks!); however, in your opinion could
there be an issue with the clock on this host as the offset+jitter seems
excessively high here?
Justin.
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
