I’d like to monitor and graph one way delay (OWD) using the four timestamps in the ntp message. This should be available directly by plotting request delay and response delay:
dt_request = t2 - t1
dt_response = t4 - t3
Measuring one way delay from one stratum 1 ntp server to another stratum 1 should work nicely because both are synced with GPS.
But what log extraction and plotting tools are available to monitor these four timestamps from ntp messages using chrony logs?
In the measurements log file there is offset and peer delay. The delays in the two directions, assuming both server and client have accurate clocks, is peer_delay / 2 + offset and peer_delay / 2 - offset.
yes, yes @mlichvar, true, indeed. This is one approach, but it assumes symmetric outbound and return communication delays.
This assumption does not capture the asymmetry found in the wide area networks (open Internet) where the pool servers operate. this is evidenced by the ntp pool server plots with significant, consistent positive or negative offsets. Even between two stratum 1 ntp servers, both synced very close to GPS time, there can be a 10 or 15ms offsets. This can only be explained by assymetry in network delays (or config file parameters).
I’m hunting for a method of estimating one-way delay directly from ntp packets, or using chrony logs. The logs don’t record t1, t2, t3, or t4 so it may not be possible from chrony logs.
No, it assumes there is no offset between the two clocks, contrary to the offset meaured by NTP.
That’s what I described above.
The logs don’t have the four timestamps, but you can reconstruct t2 - t1 and t4 - t3 from the measured delay and offset. The math is straightforward:
delay = (t2 - t1) + (t4 - t3)
offset = ((t2 + t3) - (t4 + t1)) / 2
offset = ((t2 - t1) - (t4 - t3)) / 2
(t2 - t1) = 2 * offset + (t4 - t3)
(t2 - t1) = 2 * offset + delay - (t2 - t1)
(t2 - t1) = offset + delay / 2
(t4 - t3) = -offset + delay / 2
Hello @mlichvar, thanks for your reply. This is interesting. I’ve extracted delay and offset from my chrony logs to understand this better.
The measurements log file has these, just as you said, and I’ve begun plotting delay and offset to some stratum 1 servers.
Plotting delay vs. offset seems to be the most useful approach for cutting through the noise and jitter, just like Dr. Mills on slide 12 of his seminar.
This screenshot with the Vee is from that presentation. I’m getting similar results.
But on the symmetry issue, I have to disagree, on offset at least. The 1/2 in the offset equation is a clue that symmetry is, indeed, assumed. The basic NTP time transfer approach assumes symmetric 2-way messaging and offset is estimated as the median of the two delta-t terms. This is mentioned in the ntp faq. The symmetry assumption is not terrible, especially with repeated attempts, but it’s part of the offset formulation.
On the delay, you are indeed correct. There is no symmetry assumed and the delay equation is a round trip delay, in total. There is no 1/2 term in the delay equation so highly asymmetric network links will report the correct round trip delay.
It may be interesting to know there is another time keeping community focused on Wireless Sensor Networks (WSNs). They use 1/2 in both offset and delay estimates. The NTP community, here, uses total round trip time and does not assume symmetry for total delay.
If you are making offset vs delay plots, you may find interesting the asymmetry reported in the sourcestats log (the last column). If you make a line with that slope from the point with the minimum delay, the line should go in the direction where most points in the plot are located. That is the correction that chrony applies for the “jitter asymmetry”.
