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

David Lord snews at lordynet.org
Tue Jul 20 15:03:15 UTC 2010


Rhys wrote:
> In article <i241ce$bu9$1 at news.eternal-september.org>, david-
> taylor at blueyonder.co.uk.invalid says...
>> "Rhys" <user at mailinator.org> wrote in message 
>> news:MPG.26b018b8126a17a1989681 at news.optusnet.com.au...
>> []
>>> 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.
>> For NMEA alone, no PPS, you may get poorer performance then just with 
>> LAN/Internet sync.  Just to remind me, you're somehow measuring one system 
>> against another?
>>
>>> 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.
>> What do you mean "reappear"?  To be present on ntpq -p at all, or to have 
>> the synced tag "o"?
>>
>>> 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.
>> I would have thought that the fewer sentences the better, to be honest, 
>> although I've seen one recommendation to use the sentences which include 
>> the number of satellites locked (IIRC) so that you can get a measure of 
>> how marginal GPS lock might be.
>>
>> My own tests showed that while a serial-to-USB converter made accuracy a 
>> lot worse, it could still be better than a LAN connection alone.
>>
>>   http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#usb
>>
>> Cheers,
>> David 
> 
> Using both 20 MMEA and 22 PPS references. PPS turned off on the NMEA, 
> Kernel mode on the PPS. They seem to operate almost independantly. PPS 
> has zero reach, with no 'when' time, for about 1/2 an hour, it may be 
> waiting for NMEA to get under a certain threshold, or for NTP to stop 
> thrashing around the 500 PPM mark and align. Its present, just not doing 
> anything.

That's what I see with separate gps and pps sources and
drivers. PPS does nothing until GPS (or other prefer peer)
is marked as selected. This can be an hour or more or never
depending what fudge offset is set for gps although with
680ms fudge offset at moment, pps is selected and at reach
377 in under 30 minutes from starting ntpd.

Just using nmea and its pps support is simpler even if sub
us offsets aren't possible. Some results from last year on
NetBSD gave type-20 driver alone at between 9.514-97.51ms,
type-20 and PPS kernel 0.007-0.200ms whilst with addition of
type-22 driver I had 0.002-0.006ms.


David


> 
> The number of satellites sounds like a useful one, although last time I 
> did a 'cat gps1' it seems to drop out the NMEA to NTP, will have to 
> retry. Refid PPSx/GPSx with x being number of sats anyone?
> 
> My offsets for NMEA so far in this run (last 3 hours I think), most 
> positive i saw was 20ms, most negative 80ms, so I'd put jitter of NMEA 
> on GPS18x data at 100ms, if NTPs reading it correctly. WIth a fixed 
> offset of 0.585, I'd be looking at 0.5-0.6 seconds. As it seems to have 
> a cycle of min to max of a few hours, I'm not adjusting it till its had 
> a few days, to find the new center.
> 
> If I get bored at work (electronic calibration lab and nothing to do), I 
> might bring it into work, and run the GPS 18x like the link above 
> through a few heat/cold cycles and a few power cycles, and see if theres 
> any correlation in offset.
> 
> Even if all this infos offtopic, its gonna be useful to anyone else 
> trying the same thing in the future, because NTP is never predictable.




More information about the questions mailing list