[dropping [email protected], I highly doubt this is a Linux bug.]
On Sat, Jul 7, 2012 at 15:12 UTC, Justin Piszcz wrote: > I did some digging and it looks like the system clock on this motherboard > with the latest BIOS (2.00a) runs 1 second too fast when comparing to other > NTP-synchronized machines. I doubt that's relevant, but please refer to your source for that info. The thing is, the mobo clock is only consulted once at boot time to initialize the OS clock. How it drifts while the system is off or on has no effect in how the system clock drifts. > When comparing the clock on this vs. an atomic clock, the system clock is ~1 > second faster, which is probably why the GPS has problems syncing. > > $ ntpq -pn > remote refid st t when poll reach delay offset > jitter > ============================================================================ > == > x127.127.28.0 .GPS. 0 l 11 16 377 0.000 0.363 > 100.414 > *204.235.61.9 128.174.38.133 2 u 48 64 37 48.716 -985.27 > 326.767 > +184.105.192.247 216.218.254.202 2 u 43 64 37 90.902 -987.55 > 332.766 > +50.7.247.114 85.114.26.194 2 u 42 64 37 158.445 -985.19 > 330.627 > +69.65.40.29 209.51.161.238 2 u 43 64 37 47.733 -984.50 > 329.232 > > Any idea why it consistently has a ~1 second offset? > Is there a good way to fix this? 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 Cheers, Dave Hart _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
