| Re: [chrony-users] Is my GPS receiver really less accurate than NTP servers? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
have no idea what those graphs mean.
Yes, I have compared my gps against public time servers and the GPS is a few
orders of magnitude better.
One possibility is that you are triggering on the wrong edge of the pulse
from the GPS.
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
On Sat, 16 Apr 2022, Dominick C. Pastore wrote:
[CAUTION: Non-UBC Email]
Hello everyone,
I'm sure a bunch of people on this list have seen or tried one of the guides
out there for setting up a Raspberry Pi as a stratum 1 time server with a GPS
receiver like one of these:
https://www.adafruit.com/product/2324
https://store.uputronics.com/index.php?route=product/product&path=60_64&product_id=81
I'm wondering, has anyone tried comparing their results from one of those
guides against public time servers? If so, were the results positive (as in,
at least as accurate and more precise than time from NTP servers)? I ask
because after setting mine up, I plotted Chrony's reported offset from
several public time servers ("Offset" column in measurements.log). I got some
interesting results.
(Before I continue, for those who will wonder about my setup: I'm using a
Raspberry Pi 3B+ with a Ublox MAX-M8Q GPS receiver and Chrony 4.0. I set the
boot options to disable tickless mode and the serial console, installed
cpufrequtils and set the cpu governor to full performance, enabled uart and
pps and disabled bluetooth and wifi in /boot/config.txt, and uninstalled a
few unnecessary daemons.)
First, I compared against NTP pool servers. The results here look pretty
phenomenal: https://i.imgur.com/4At0m1d.png The accuracy from the GPS
receiver seems to be great. The plot doesn't show the refclock's precision,
but it was several orders of magnitude better than the servers as well.
Then I measured against public NTP servers run by large tech companies and
NIST. Notably, apart from time.cloudflare.com, these are all stratum 1
servers. This is the plot: https://i.imgur.com/eu267CW.png Here, the picture
doesn't look so rosy. In fact, taking those results at face value, I should
just abandon the GPS, because it seems I'd get better accuracy by syncing
with a few of these servers instead. (It makes no noticeable difference
whether Chrony uses GPSd for the refclock or uses /dev/pps0 directly.)
The one thing that does seem a little suspicious is that the offsets for all
the servers fall pretty uniformly between about 0 and +5 milliseconds. That
seems a little too coincidental, like maybe 5ms is the granularity of the
Teh accuracy from a properly setup GPS is of the order of a few hundres of
nanoseconds, a factor of almost 1000000 from what you are getting. I
nd no, 5ms is NOT the granularity of the timestamping, unless your system
clock is really bad.
timer used to timestamp the packets or something. But, admittedly, I have no
other reason to believe the measurements aren't correct, and that sounds like
an unlikely explanation. I suppose it's possible the PPS from the GPS
receiver has a constant 2.5ms delay from somewhere, but I'd be a little
surprised (it's not a timing GPS, but the datasheet still quotes a PPS
accuracy within 60ns).
Or else your network could be introducing a delay of 2.5ms one way into the
signals from all the network sources.
So are these plots the difference between the offsets of the gps with those of
the verious sites.
So now I'm curious if anyone else with one of these Raspberry Pi setups has
done any benchmarking like this. If so, what did your results look like? And
does anyone have any theories about the positive offsets between 0 and 5ms in
the second plot?
As I mentioned, you may be using the wrong edge of the pps pulse. (2.5ms
sounds like what the pulse width could be).
Thanks,
Nick
--
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.
--
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.