| Re: [chrony-users] Is my GPS receiver really less accurate than NTP servers? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
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&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 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
<http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf> may
be of interest.
image.png
On Sat, Apr 16, 2022 at 2:23 AM Rob Janssen
<chrony-users@xxxxxxxxx <mailto:chrony-users@xxxxxxxxx>> 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-request@xxxxxxxxxxxxxxxxxxxx
<mailto:chrony-users-request@xxxxxxxxxxxxxxxxxxxx>
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
<mailto:chrony-users-request@xxxxxxxxxxxxxxxxxxxx>
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx
<mailto: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.