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.burni...@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.burni...@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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions