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

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ] 


On Tue, 29 Sep 2020, Matt Corallo wrote:




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". 

Why would you have your GPS ticking at 5Hz? That does not help the accuracy of
chrony, but may have harm esp in the NMEA timing.





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. 

?? This makes no sense. Any RTC is going to be far worse than GPS. There is
simply no way that GPS should be off by enough that and RTC can help in any
way, while the RTC can certainly be off by enough to make its time way off.

If you are finding that that RTC helps then I would throw away the GPS devices
and start again.





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.

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/