[ntp:questions] Maximum time2 fudge value for NMEA refclock?

Rhys user at mailinator.org
Tue Jul 20 09:34:41 UTC 2010


In article <i23q4d$esu$1 at news.eternal-september.org>, david-
taylor at blueyonder.co.uk.invalid says...
> 
> "David J Taylor" <david-taylor at blueyonder.co.uk.invalid> wrote in message 
> news:i23pmn$d32$1 at news.eternal-september.org...
> > "Rhys" <user at mailinator.org> wrote in message 
> > news:MPG.26b01082c6206af6989680 at news.optusnet.com.au...
> > []
> >> I'm amazed it quickly converges, using separate NMEA and PPS on mine,
> >> with the correct offset, and correct drift file, its an hour or 2 
> >> before
> >> it finishes going 500ppm/step/500ppm/step.
> >
> > With a standard NTP system, either with a LAN sync-source, or a 
> > single-connector NMEA/PPS source on either Windows or FreeBSD I've not 
> > seen that sort of behaviour.
> []
> 
> Perhaps I should have added that I have seen something similar when there 
> was a spurious leap second announcement from just one server, and one of 
> my NTPs got out of step.  So your NTP could be oscillating between one 
> second and the next.  I recall needing to delete the drift file as part of 
> solving that one.
> 
> Cheers,
> David 

Sorry I should have said, GPS18x. Now that its stabilised its still 20-
80ms positive out in ntpq, so either my offset didn't actually change, 
or in the wrong direction.

Seems a regular thing for it to jump crazy on startup, makes fine tuning 
a little impossible. PPS takes 30 minutes i think to reappear, it might 
be kernal PPSing in the background vs NTP trying to synch to NMEA.

I was thinking about turning on more NMEA sentences to see if it 
stabilises NMEA, but getting to the Windows boot on that isn't easy now, 
and this main PC has no serial.





More information about the questions mailing list