[ntp:questions] false ticker after GPS coldreset

Martin Burnicki martin.burnicki at meinberg.de
Mon Nov 6 21:16:12 UTC 2017


Hi Gary,

sorry for the late reply. I've been mostly offline for some days.

Gary E. Miller wrote:
> Yo Martin!
> 
> On Fri, 3 Nov 2017 14:27:52 +0100
> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> 
>>>> Anyway, gpsd seems to accept the raw GPS time as UTC time, feeds
>>>> it to ntpd, and ntpd sets the Linux system time off by a number of
>>>> seconds.  
>>>
>>> Which is why gpsd should rarely be the only input into your ntp
>>> daemon.  
>>
>> Hm. According to my own observations, if you get most accurate time
>> from your GPS receiver operating normally, as single time source, and
>> then add some upstream NTP sources beside the GPS refclock the
>> resulting accuracy of the system time becomes worse.
> 
> That can happen, but there are mitigation strategies.  First I use
> the prefer keyword on my PPS time.  I'm not seeing that here:
> 
>      remote           refid      st t when poll reach   delay   offset   jitter
> *SHM(1)          .PPS.            0 l    1    2  377      0ns    722ns    968ns
> +spidey.rellim.c .PPS.            1 u   25   32  377 254.35µs 57.594µs 63.995µs
> -pi.rellim.com   .PPS.            1 u   22   32  377 416.27µs -654.8µs 154.28µs
>  pi2.rellim.com  .PPS.            1 u   9d   32    0 581.89µs 28.000µs      0ns
>  pi4.rellim.com  .STEP.          16 u    -   32    0      0ns      0ns    954ns
> -catbert.rellim. .PPS.            1 u   30   32  377 376.48µs 455.34µs 49.887µs
> -kong.rellim.com 204.17.205.8     2 u   59   32  266 347.37µs 196.00µs 30.736µs
> -backup.rellim.c 204.17.205.8     2 u   22   32  377 412.37µs 158.38µs 48.486µs
> +SHM(0)          .GPS.            0 l   13   16  377      0ns 507.16µs 672.13µs
> 
>  
> Note the 722 ns offset and 960ns jitter on mmy PPS.
> 
>> So it's not generally better to use other time sources beside a GPS
>> receiver.
> 
> Until your GPS goes wacky...
> 
>> You can simply try this if you look at the smoothness of the loopstats
>> generated with a GPS receiver only vs. the loopstats generated with a
>> GPS receiver plus some NTP servers on the network.
> 
> I've got a dozen chimers up now with PPS, not seeing it.

Agreed, eventually we have to distinguish a little bit more.

I'm mostly working with GPS PCI cards, where the kernel driver reads a
high resolution, accurate time stamp from the PCI card, plus an
associated system time stamp, plus some TSC counts. The calling
application can check the TSC values to see if reading the time stamp
pairs has taken longer than "usual", and repeat the call, or feed both
time stamps into SHM.

This approach avoids IRQ latencies, and doesn't need a PPS, but of
course it works only with a PCI card where you can read a high
resolution time stamp at any time, and don't have to wait until a serial
time string has been received.

On the other hand, with external GPS receivers connected via NMEA or
some binary serial messages you need PPS to compensate the serial
jitter. If you enable kernel PPS support then the kernel evaluates the
PPS time stamps by itself, but the kernel is unable to determine the
mean PPS latency.

Indeed, the loopstats may not be affected by additional time sources
since *only* the PPS slope is used to determine the second boundary.

So here we have to look at what happens to the PPS if the GPS goes
wacky. If you have a GPS with good, disciplined oscillator the it makes
sense to keep on evaluating the PPS even after GPS reception has just
failed.

On the other hand, if your GPS has no such oscillator on-board, the PPS
slope starts drifting quickly after reception has been lost. So it would
be better to disable PPS in this case since otherwise the PPS slopes
will cause a system time drift.

>> ntpd doesn't anyway accept the time from a source that indicates that
>> its time is not synchronized. So it wouldn't accept the time from the
>> GPS receiver (directly or via gpsd/SHM) if a "not synchronized" status
>> was available from the receiver and passed to ntpd.
> 
> Which is NOT what the OP was complaining about.  His GPS was saying synced,
> but was off by the UTC/GPS offset which had not been downloaded yet.

That's exactly what I try to say. The GPS said "synced" but probably
only because a navigational fix could be achieved, which doesn't need
the UTC correction parameters. If there was a "time sync" status flag
that could be evaluated then the time from the GPS wouldn't be accepted
before the UTC correction parameters were available, even if a position
fix could have been achieved.


Regards,

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy


More information about the questions mailing list