On Sat, Jul 01, 2017 at 12:03:30AM +0300, Horia Muntean wrote:
> 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.
> 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.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
