To finish my line of thoughts:
- Syncing to stratum 2 and 3 servers over Internet is surely not the solution. Even wired network to stratum 2 or 3 can have 1 microsec sync error, depending on the protocol and the load. High and/or variable jitter value is not not ideal. There are timestamps, ok. but there is no garantie for having a periodic error. Instead, sometimes it can be erratic. We can not forget that our computers are not for a single purpose, so its load will be vary. (they are not NTP computers exclusively)
- On the cheaper side, the accuracy of GPS time signals is
±10 nanoseconds so all the other unwanted delays (offset) are locally added.
As long as the typical processing time of the hardware is known and the processor is not loaded close to 100 percent, the accuracy can be maintained quite well. If necessary, you can even run sync with elevated priority, also handling the known mismatch of local clock-frequency.
- Just a line in
chrony.conf: "refclock SHM 0 offset -0.00004 delay 0.0 refid NMEA"
(If local clock is fast or slow, we can run "makestep" more often, and shift the already reduced mismatch to be closer to zero in average.)
Compared to the uncertainties of Internet communication where a timestamp cannot fully solve the problem either, a local solution may also be more acceptable. The rest is just a matter of standardization.
- There are also ways to avoid the collapse of time-sensitive applications. A kind of slow sync - without bigger jumps.
- Dependancies of critical processes shall be kept on a virtual drive, in memory - for reducing the latencies.
- Of course, adding also a high precision RTC (realtime clock) to Pi device won't harm either. PTP capable GPS would help a lot.
As for me, combining a good RTC with slow sync is not impossible.
This cheap Pi-compatible 56 channel USB GPS receiver has a 30 ns timing accuracy:
UBX-G7020-KT
