Re: [chrony-users] Is my GPS receiver really less accurate than NTP servers?

[Bill Unruh]

Unfortunaely "symmetric" does not refer to timing as far the ISP is
cconcerned.I usually just means they will provide the same speed upi
as down. So I would certainly believe that there is something in the ISPs
network that is adding abotu 5ms to the route uniformly for all outgoing or
incoming packets. 
If it occurs close enough to you (eg even your inhome router or fibre modem)

then it would be the same for all sources.

Assuming you have the right edge for the pulse, and you are using the pulse (
not the test string) then yes, I would trust the gps as your computer does.


William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ Advanced Research _| Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/

On Mon, 18 Apr 2022, Dominick C. Pastore wrote:


[CAUTION: Non-UBC Email]

First off, thank you all for the responses. I'm going to reply to 
all three messages in one email so as not to flood everyone's 
inbox.


The graphs are plotting the "Offset" column by server from 
Chrony's measurements.log. I should have mentioned originally, 
this was while Chrony was syncing the local clock from the GPS's 
PPS signal. I figured that was the most useful information to 
plot, but I can plot any of the other logged values as well (like 
delays and dispersions) if that would be useful.


Regarding the PPS pulse edge: I forgot to mention, I did think to 
try using the other edge, but when I configured the PPS source as 
/dev/pps0:clear, Chrony gave an error:


2022-04-17T13:55:20Z Fatal error : CAPTURECLEAR not supported on 
/dev/pps0


I'm not sure how to fix that (if anyone has any ideas, I would be 
grateful), but I assumed the pulse was longer than 2.5ms anyway, 
so I didn't worry about it at the time. In the meantime, I'll try 
measuring the pulse width to see if it happens to be in the same 
ballpark as the offset.


The other possibility everyone mentioned was asymmetric network 
delay. That explanation makes a lot of sense (and the paper Steven 
linked was an interesting read). I can certainly test for that in 
my own equipment. As for what's outside my control: My ISP 
(Verizon FiOS) provides "symmetric" fiber service, though I don't 
know if anything about it is symmetric except the throughput. 
There may be asymmetry elsewhere in the path, but since all 
servers were showing offsets in the same 0ms to 5ms range, that 
seems the least likely.


In any case, it sounds like so long as I can rule out the 
possibility that I'm using the wrong PPS edge, I should trust the 
timing of the GPS's PPS signal more than the time derived from 
other servers (but let me know if anyone disagrees with that 
conclusion or has other thoughts).


I appreciate all the advice.

Thanks,
Nick

On 4/16/22 4:16 PM, Steven Sommars wrote:
Network delay asymmetry can also be introduced by local 
equipment.  The scatterplot below shows the round-trip delay 
between an NTP client and a nearby NTP server.
on my fiber internet service 1) at the local NTP client and 2) 
just above my home router.



If the local client and the remote NTP server both have accurate 
time it can be interesting to compare the request delay (client 
-> server) to the response delay (server -> client).

[Asymmetric delays are common]

This paper 
 may 
be of interest.

image.png

On Sat, Apr 16, 2022 at 2:23 AM Rob Janssen 
mailto:chrony-us...@pe1chl.nl>> wrote:


When you have a systemic offset of external services vs your 
local clocks, it is often caused by asymmetric network delay.
E.g. when using VDSL or Cable, it may well be that your 
uplink and downlink rates are different, and also the error 
correction parameters are different.
In that case all your external servers get offset by some 
value, and it is the GPS time that is right, not those 20 
external references.


I have seen that coming and going on my line, over the 
years.  The telecom operators sometimes decide it is better to 
have reliability than low roundtrip time and enable "long 
interleaving" and similar parameters, often only in one of the 
directions.  But then later they find themselves in a contest 
for low roundtrip times in the gaming world, and they change 
that again.
For quite some time I had an offset of a few ms in my VDSL 
line and even tweaked the config for it.  But at the moment it 
is quite symmetric.


But indeed, also check the pulse width of the PPS signal to 
see if it happens to be the same as your offset.  If so, change 
the PPS edge.


Rob

On 4/16/22 06:24, Dominick C. Pastore wrote:
 >
 > 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 timer 

Re: [chrony-users] Is my GPS receiver really less accurate than NTP servers?

[Dominick C. Pastore]

First off, thank you all for the responses. I'm going to reply to all three 
messages in one email so as not to flood everyone's inbox.

The graphs are plotting the "Offset" column by server from Chrony's 
measurements.log. I should have mentioned originally, this was while Chrony was syncing 
the local clock from the GPS's PPS signal. I figured that was the most useful information 
to plot, but I can plot any of the other logged values as well (like delays and 
dispersions) if that would be useful.

Regarding the PPS pulse edge: I forgot to mention, I did think to try using the 
other edge, but when I configured the PPS source as /dev/pps0:clear, Chrony 
gave an error:

2022-04-17T13:55:20Z Fatal error : CAPTURECLEAR not supported on /dev/pps0

I'm not sure how to fix that (if anyone has any ideas, I would be grateful), 
but I assumed the pulse was longer than 2.5ms anyway, so I didn't worry about 
it at the time. In the meantime, I'll try measuring the pulse width to see if 
it happens to be in the same ballpark as the offset.

The other possibility everyone mentioned was asymmetric network delay. That explanation 
makes a lot of sense (and the paper Steven linked was an interesting read). I can 
certainly test for that in my own equipment. As for what's outside my control: My ISP 
(Verizon FiOS) provides "symmetric" fiber service, though I don't know if 
anything about it is symmetric except the throughput. There may be asymmetry elsewhere in 
the path, but since all servers were showing offsets in the same 0ms to 5ms range, that 
seems the least likely.

In any case, it sounds like so long as I can rule out the possibility that I'm 
using the wrong PPS edge, I should trust the timing of the GPS's PPS signal 
more than the time derived from other servers (but let me know if anyone 
disagrees with that conclusion or has other thoughts).

I appreciate all the advice.

Thanks,
Nick

On 4/16/22 4:16 PM, Steven Sommars wrote:

Network delay asymmetry can also be introduced by local equipment.  The 
scatterplot below shows the round-trip delay between an NTP client and a nearby 
NTP server.
on my fiber internet service 1) at the local NTP client and 2) just above my 
home router.


If the local client and the remote NTP server both have accurate time it can be 
interesting to compare the request delay (client -> server) to the response delay 
(server -> client).
[Asymmetric delays are common]

This paper  may be of 
interest.
image.png

On Sat, Apr 16, 2022 at 2:23 AM Rob Janssen mailto:chrony-us...@pe1chl.nl>> wrote:

When you have a systemic offset of external services vs your local clocks, 
it is often caused by asymmetric network delay.
E.g. when using VDSL or Cable, it may well be that your uplink and downlink 
rates are different, and also the error correction parameters are different.
In that case all your external servers get offset by some value, and it is 
the GPS time that is right, not those 20 external references.

I have seen that coming and going on my line, over the years.  The telecom operators 
sometimes decide it is better to have reliability than low roundtrip time and enable 
"long interleaving" and similar parameters, often only in one of the 
directions.  But then later they find themselves in a contest for low roundtrip times in 
the gaming world, and they change that again.
For quite some time I had an offset of a few ms in my VDSL line and even 
tweaked the config for it.  But at the moment it is quite symmetric.

But indeed, also check the pulse width of the PPS signal to see if it 
happens to be the same as your offset.  If so, change the PPS edge.

Rob

On 4/16/22 06:24, Dominick C. Pastore wrote:
 >
 > 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 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).


-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 

with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 

with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org 
.



--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with 

Re: [chrony-users] Is my GPS receiver really less accurate than NTP servers?

[Steven Sommars]

Network delay asymmetry can also be introduced by local equipment.  The
scatterplot below shows the round-trip delay between an NTP client and
a nearby NTP server.
on my fiber internet service 1) at the local NTP client and 2) just above
my home router.


If the local client and the remote NTP server both have accurate time it
can be interesting to compare the request delay (client -> server) to the
response delay (server -> client).
[Asymmetric delays are common]

This paper  may
be of interest.
[image: image.png]

On Sat, Apr 16, 2022 at 2:23 AM Rob Janssen  wrote:

> When you have a systemic offset of external services vs your local clocks,
> it is often caused by asymmetric network delay.
> E.g. when using VDSL or Cable, it may well be that your uplink and
> downlink rates are different, and also the error correction parameters are
> different.
> In that case all your external servers get offset by some value, and it is
> the GPS time that is right, not those 20 external references.
>
> I have seen that coming and going on my line, over the years.  The telecom
> operators sometimes decide it is better to have reliability than low
> roundtrip time and enable "long interleaving" and similar parameters, often
> only in one of the directions.  But then later they find themselves in a
> contest for low roundtrip times in the gaming world, and they change that
> again.
> For quite some time I had an offset of a few ms in my VDSL line and even
> tweaked the config for it.  But at the moment it is quite symmetric.
>
> But indeed, also check the pulse width of the PPS signal to see if it
> happens to be the same as your offset.  If so, change the PPS edge.
>
> Rob
>
> On 4/16/22 06:24, Dominick C. Pastore wrote:
> >
> > 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 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).
>
>
> --
> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
> with "unsubscribe" in the subject.
> For help email chrony-users-requ...@chrony.tuxfamily.org
> with "help" in the subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>

Re: [chrony-users] Is my GPS receiver really less accurate than NTP servers?

[Bill Unruh]

 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 _|___ Advanced Research _| Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
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=60_64_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 100 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-requ...@chrony.tuxfamily.org with 
"unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the 
subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-users] Is my GPS receiver really less accurate than NTP servers?

[Dominick C. Pastore]

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=60_64_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 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).

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?

Thanks,
Nick

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.