[ntp:questions] Maximum time2 fudge value for NMEA refclock?
user at mailinator.org
Thu Jul 22 08:24:28 UTC 2010
In article <keqgh7-lgg.ln1 at p4x2400c.home.lordynet.org>,
snews at lordynet.org says...
> 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.
Well I've adjusted it 40ms forward, to even out todays. If its got 100ms
of travel day to day in the NMEA, its gonna be tricky. Added true
keyword as well, as it was getting declared falseticker once it got to
around 80ms out, which also labelled PPS false. It still aligns to PPS
regardless of NTPs algorithim as its Kernel, but doesn't look good. Put
noselect on all the lan/internet sources as well, as I'm aiming for it
to self align on just NMEA and PPS.
associd=0 status=c418 leap_alarm, sync_uhf_radio, 1 event, no_sys_peer,
version="ntpd 4.2.6p1-RC5 at 1.2149 Wed May 19 07:51:59 UTC 2010 (1)",
processor="i386", system="FreeBSD/8.0-RELEASE", leap=11, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=253.185, refid=NMEA,
reftime=cff27dd1.7bef9db9 Thu, Jul 22 2010 18:20:33.484,
clock=cff27dda.c5c16006 Thu, Jul 22 2010 18:20:42.772, peer=11561, tc=
mintc=3, offset=0.000, frequency=790.076, sys_jitter=39.625,
This is the restart 'thrasing' as described before. Stop NTP while
perfectly aligned, restart, somehow ends up 200-800ms out (aligns to
NMEA on startup without offset?), then after 5-10 mins does this. Note
the frequency of 790 ppm, when normal running its 12-14 PPM for maybe
12-25 degrees celcius here. Offsets go negative due to insane PPM, then
it rejumps and corrects I believe. Drift file says 12ppm.
Just noticed sync_uhf_radio as well, no radio service here in Aus :)
More information about the questions