> Indeed, but I also would like measure how good the path between the two > points is. I mean: if the network randomly delays packets (or so), then that > would influence the syncing I think? Yes. NTP assumes the network delays are symmetric. Half of any extra delay in one direction will turn into a clock offset error. The classic way to screwup NTP is to do a big download that saturates one side of your link. ntpd keeps a FIFO of the last 8 packets and only uses a new response if it is the best of the 8. That filters out short bursts of traffic but a long download can fill the FIFO with long delays. > Ping times of around 8.3 seconds (yes, seconds). What is the minimum ping time? With slow links, you have to be very very careful not to shoot yourself in the foot. If the round trip time is 2 seconds but your retransmit timer is only 1 second, the pattern goes like this: 0: send #1 1: retransmit #1 2: recv #1, send #2 3: retransmit #2 4: recv #1, retransmit #2 5: retransmit #2 6: recv #2, send #3 NB: There are still 3 retransmitted copies of #2 in the pipeline. (and that's assuming that the 2 second round trip time is less than 2 ticks of the 1 second retransmit timer) Basically, the link gets full of retransmitted packets. It gets worse if there is any other traffic on the link. -------- Magnus Danielson said: > ADEV and TDEV is intended to handle random noise, ... Network delays are often far from random. All it takes to really screw things up is a download with enough bandwidth to saturate the link. I usually start with a graph of round trip time on Y and time of day on X. Your eye/brain is really good at analyzing that sort of picture. Is there any *DEV that works well with missing samples? Occasional packets get lost and I'd like to see what happens if I discard wild samples. Is there anything better than generating fake data by interpolating? -- These are my opinions. I hate spam.

Hal, On 9/15/22 14:53, Hal Murray via time-nuts wrote: >> Indeed, but I also would like measure how good the path between the two >> points is. I mean: if the network randomly delays packets (or so), then that >> would influence the syncing I think? > Yes. NTP assumes the network delays are symmetric. Half of any extra delay > in one direction will turn into a clock offset error. > > The classic way to screwup NTP is to do a big download that saturates one side > of your link. > > ntpd keeps a FIFO of the last 8 packets and only uses a new response if it is > the best of the 8. That filters out short bursts of traffic but a long > download can fill the FIFO with long delays. Indeed. Variation in delays eat into the result quickly despite the filtering applied of this scheme. > >> Ping times of around 8.3 seconds (yes, seconds). > What is the minimum ping time? > > With slow links, you have to be very very careful not to shoot yourself in the > foot. If the round trip time is 2 seconds but your retransmit timer is only 1 > second, the pattern goes like this: > 0: send #1 > 1: retransmit #1 > 2: recv #1, send #2 > 3: retransmit #2 > 4: recv #1, retransmit #2 > 5: retransmit #2 > 6: recv #2, send #3 > NB: There are still 3 retransmitted copies of #2 in the pipeline. (and > that's assuming that the 2 second round trip time is less than 2 ticks of the > 1 second retransmit timer) > Basically, the link gets full of retransmitted packets. It gets worse if > there is any other traffic on the link. > > -------- > > Magnus Danielson said: >> ADEV and TDEV is intended to handle random noise, ... > Network delays are often far from random. All it takes to really screw things > up is a download with enough bandwidth to saturate the link. For sure. ADEV and friends is power measurements and the details of packet delay variations get muddled and hard to pin-point in that world. There are other tools one should look at and all packet delay variations comes from various buffer mechanisms in play one way or another. There is some fiber delay variations as one goes far, but it is usually swamped by other things. > > I usually start with a graph of round trip time on Y and time of day on X. > Your eye/brain is really good at analyzing that sort of picture. Further processing is possible, but it is a bit complex to smash it all out. > > Is there any *DEV that works well with missing samples? Occasional packets > get lost and I'd like to see what happens if I discard wild samples. Is there > anything better than generating fake data by interpolating? You should look at David Howe's Data imputation paper. It's the cutting edge in 2022. It can take quite a beating and still retain really good ADEV plots. The approach they took in the paper is however not suitable to handle systematics, as I pointed out when I had a good long chat with him during my Boulder visit. The reason is that the way he treats noise will not work with systematics, because he mirrors the noise with long term end-point matching. For a running sine this will be disruptive and not work. He had not considered that, so such things needs to be handled before imputation. Cheers, Magnus