[chrony-users] Accuray statistical claims

[Horia Muntean]

Hi,

I have a stratum 1 NTP server in the same LAN as my client - one
switch apart. The server is a Microsemi SyncServer S600 that gets the
time over GPS and has hardware timestamping on it's port.

On the client's (which is a chrony instance and does not have hardware
timestamping capabilities for NTP) measurements.log the NTP server
reports all root delays and dispersions as zero (0.000e+00).

If on every measurement made by the client and reported on
measurements.log (every 4 seconds), it is true that

abs(offset) + peer_delay / 2 + peer_dispersion <= target

(target being a constant, say 1 ms) is it safe to say with certainty
(100% probability) that my client's system clock has a maximum
divergence from the NTP server's time (which is presumed to be the
source of UTC time when not on holdover) of 'target' (at least when
each measurement was done) ?

If the answer in no, please explain. Any advice about how can this
(prove that a client's system clock is within a target from UTC) be
done only with NTP/chrony ? AFAIK if one wants to measure the accuracy
of a system, another more accurate system must be used (in my case
maybe installing a PPS card on the client then comparing its output
with the server's PPS output) but we can't afford to do this on each
client.

BR

[Miroslav Lichvar]

Post by Horia Muntean
If on every measurement made by the client and reported on
measurements.log (every 4 seconds), it is true that
abs(offset) + peer_delay / 2 + peer_dispersion <= target
(target being a constant, say 1 ms) is it safe to say with certainty
(100% probability) that my client's system clock has a maximum
divergence from the NTP server's time (which is presumed to be the
source of UTC time when not on holdover) of 'target' (at least when
each measurement was done) ?

That works only for the "NTP time" which chronyd is tracking. It
doesn't include the offset of the system clock, which may be larger
than the NTP offset, e.g. when slewing a large initial offset after
start. The expression would need to include also the "Offset" and
"Rem. corr." values from the tracking log to get what you describe.

I think a better way to monitor the maximum error of the system clock
is to use the values from the chronyc tracking command:
abs(System_time) + Root_delay / 2 + Root_dispersion <= target

That should work even between updates of the clock (assuming
maxclockerror is large enough to cover the wander of the clock and
nothing else is touching the clock), and it combines all time sources,
allowing them to have some bad measurements due to overloaded network,
etc.

Post by Horia Muntean
If the answer in no, please explain. Any advice about how can this
(prove that a client's system clock is within a target from UTC) be
done only with NTP/chrony ? AFAIK if one wants to measure the accuracy
of a system, another more accurate system must be used (in my case
maybe installing a PPS card on the client then comparing its output
with the server's PPS output) but we can't afford to do this on each
client.

Right. An NTP client doesn't know the current error of the clock (if
it did, it could correct the clock to have zero error), but if it can
make some assumptions on stability of the clock and trust its sources,
it can give an estimate of the maximum error. That's the root delay
and dispersion.

[Bill Unruh]

...

Post by Horia Muntean
If the answer in no, please explain. Any advice about how can this
(prove that a client's system clock is within a target from UTC) be
done only with NTP/chrony ? AFAIK if one wants to measure the accuracy
of a system, another more accurate system must be used (in my case
maybe installing a PPS card on the client then comparing its output
with the server's PPS output) but we can't afford to do this on each
client.

If you put such a card in then you would of course use it, not ntp, to
discipline the clock. However, you can run a single test bed in which you
connect one such more accurate clock to one of your clients to see what the
relation is between its chrony driven time and the more accurate time from the
PPS source (eg a gps puck).
This would of course not catch some sudden change in one of the intermediate
routers on your system which introduced a 10us delay in one of the paths and
not the other when the gps clock was not attached.

Not sure what you mean by prove? In a court of law? And what would the
consequences be of not having the time be sufficiently accurate? If high
enough then the cost of a say a gps attached to each client would be worth it.