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

David Lord snews at lordynet.org
Thu Jul 22 10:23:50 UTC 2010


Rhys wrote:
> 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=
> 4,
> mintc=3, offset=0.000, frequency=790.076, sys_jitter=39.625,
> clk_jitter=95.396, clk_wander=0.000
> 
> 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 :)

That is same as I see without my large fudge time1. To use a
large fudge time1 also requires tos mindist 0.8.

The fudge time2 offset is intended to adjust for the difference
between NMEA and PPS offsets so large fudge time1 isn't required.
I have not yet been able to get ntpd 4.2.6p2 to behave on NetBSD
so not able to test the NMEA fudge time2 feature.

/etc/ntp.conf:  (less restrict and logging)
#########################
tos minsane 3
tos orphan 10
tos mindist 0.8

server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPSb

server 127.127.20.2 minpoll 6 maxpoll 8 prefer
fudge 127.127.20.2 time1 0.680 refid GPSb

peer mypeer1 maxpoll 8
peer mypeer2 maxpoll 8

server mylocal1 minpoll 6 maxpoll 8
server mylocal2 minpoll 6 maxpoll 8

server remote1 minpoll 8
############################

peer_summary from 20100721

ident            mean     rms     max
127.127.22.0   -0.000   0.008   0.022 # PPS
127.127.20.2   34.448  28.200  88.589 # GPS


David




More information about the questions mailing list