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

jimmyterrence jimmyterrence at gmail.com
Sat Jul 24 20:34:29 UTC 2010


On Jul 22, 10:40 am, jimmyterrence <jimmyterre... at gmail.com> wrote:
> On Jul 22, 9:11 am, Rhys <u... at mailinator.org> wrote:
>
>
>
>
>
> > In article <mqilh7-0hi.... at p4x2400c.home.lordynet.org>,
> > sn... at lordynet.org says...
>
> > > Rhys wrote:
> > > > In article <keqgh7-lgg.... at p4x2400c.home.lordynet.org>,
> > > > sn... at lordynet.org says...
> > > >> Rhys wrote:
> > > >>> In article <i241ce$bu... at news.eternal-september.org>, david-
> > > >>> tay... at blueyonder.co.uk.invalid says...
> > > >>>> "Rhys" <u... 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.
>
> > Well its settled down ok now. Config NMEA offset is set around 600ms
> > again, and using 'true' keyword for both as well. True on just NMEA
> > causes PPS to drop out for being too far off. Noselects on all the lan
> > clients.
>
> > Therefore I've got a config at last that can self align on an airgapped
> > lan, thanks to those who posted up their offsets and the link showing
> > the offset chart, helps a lot for this kinda stuff.
>
> > Now to figure out how to synch an LPRO...
>
> I managed to set up a pps-enabled kernel on another linux box I have.
> Same thing, works with gpsd, not with the NMEA driver. One thing I was
> wondering, though, what pps pulse length does the NMEA driver seem to
> want? I have the gps receiver set at 200 ms right now for gpsd.

I solved the problem with the nmea driver (20) not working. Despite
the documentation saying that it works at 19200 bps, it only works for
me at 4800. I followed David Taylor's link:

 http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm

And in that document he links to Brian Doyle's Blog, where Brian says
that he could only get the nmea driver working at 4800 bps. I used
minicom to change the baud rate back to 4800, changed the mode in
ntp.conf from 32 to 0 (default) and....

Oh....it's triggering on the NMEA data and not the PPS signal.
Jitter's huge, and it's 700 ms off the other servers.

 remote    refid  st t when poll reach  delay  offset  jitter
============================================
*GPS_NMEA(0)     .GPS.            0 l    4   16  377    0.000
-73.187  80.005
 72.38.124.94 (s 192.168.3.6      2 u   47   64    7   22.467
721.370  11.570
 clock.psu.edu   128.118.2.33     2 u   51   64    7   47.755
719.459  10.370
 198.82.1.204 (n 198.82.247.164   2 u   48   64    7   44.536
724.609   9.450

Time to go back to doing research. My ntp.conf entry is:

# LinuxPPS: GPS + PPS
server 127.127.20.0 minpoll 4 prefer # mode 32
fudge 127.127.20.0 flag1 1 flag2 1 flag3 1 flag4 1 time1 0.545






More information about the questions mailing list