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

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

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.

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