Re: [chrony-users] Multi-PPS+RTC Setup Questions

[Matt Corallo <ntp-lists@xxxxxxxxxxxxxxx>]

On 9/29/20 2:25 PM, Bill Unruh wrote:
> The GPS PPS should be accurate to better than a microsecond. Now with two GPS
> lines coming in, there is a fight between the interrupt handlers which means
> that the second will be out by up to 10us while the first one handles the
> "first" interrupt.  That will of course depend on the hardware as well, and
> whether the the system has multiple CPU cores, and whether the interrupts can
> get distributed amongst the cores, etc. But certainly sub us accuracy and
> precision should be possible with GPS PPS. The NMEA is much much much worse
> than this-- there getting 10 ms accuracy can be difficult. So NMEA is one of the worst ways of getting accuracy (usually 
> much worse than
> internet ntp.) (PPS, network, NMEA, wristwatch is the order of accuracy.)

Yep! Sadly the offset doesn't go away when one is set to tick at 5HZ and one at 4HZ, and also not when one is set to 
tick 1ms offset from "real time".

> chrony already disciplines RTC, and the /var/log/chrony/rtc.log should show
> you what the RTC accuracy is. RTC is a pretty poor way of getting the time, since that clock has
> uncontrollable drifts-- not least from temperature variation inside the
> machine. So in short order it can be seconds away from UTC.

Sorry it wasn't clear - in this case there is a secondary (DS3231) RTC that is being pulled in and disciplined, not the 
system RTC (which, indeed, is disciplined by chrony). The DS3231 is then used to prevent the GPS time from getting far 
off of what the DS3231 claims is possible.

> On Tue, 29 Sep 2020, Matt Corallo wrote:
>
> > In theory the GPS should be able to provide a precision, certainly looking at the NMEA stream *should*, and definitely 
> > looking at u-blox's proprietary messages does, though as far as I can tell gpsd doesn't make any effort to expose it 
> > in a useful way (and I'm not sure how much effort should be required to do so in a vaguely cross-device manner). Even 
> > if it did, I don't see a great way to feed it into chrony, eg there's no way to pass it in via the socket interface 
> > (AFAICT, I was hoping to do this for the RTC to track its drift over time and feed it into chrony) and chrony appears 
> > to ignore the precision field in ntpshm (not that anything sets it usefully).
> >
> > My PPS interrupts are serial-DCD, which has some noise, but in my case u-blox
>
> Are thos interrupts from a usb feed or true serial ports? The interrupts
> certain should NOT be off by many microseconds. It sounds more like interrupt
> handling delays.

"real serial", even on interrupts driven into different CPU cores. I wasn't sure so I even went and patched the kernel 
to pull the time off of when the interrupt hits and not once the kernel has decided which serial line it is and passes 
it off to dcd_changed, but that didn't change anything.

> > appears to be garbage and the two devices are off persistently by 30-ish us (ie an order of magnitude or so more than 
> > noise), and somehow its tied to the u-blox devices themselves (the usual swapping of all ports/antennas/etc doesn't 
> > change the fact that the two devices just have different concepts of the current time, across nearly every setting 
> > including different tick rates so they tick at different times).
>
> That makes very little sense. And be careful that you are not picking the
> wrong "side" for the interrupt-- rising edge vs falling edge.

Right, that's definitely one possible error source, but the 30us timing is smack in between different possible sources - 
its too small to be an error on the edges which are ~100ms away from each other but its too large to just be noise or 
some difference in position accuracy. It is, of course, in the right range(ish) for some kind of interrupt latency, but 
its a constant offset, and it follows the GPS device, not which serial line is driven.

Left clueless,
Matt

--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.