[chrony-users] Root delay and Root dispersion values in `chronyc ntpdata'

[Chris Perl]

I have a setup that looks like the following:

GPS Receiver -- PTP --> machine_a -- NTP --> machine_b

Where:

These machines are all pretty close together (the switching latency
between them should be something like 10us).

machine_a is running linuxptp and chrony with a shared memory region
via timemaster (similar to what is described in [1]).

machine_b is running chrony, polling machine_a every 1s.

What I'm trying to understand is why on machine_b, I consistently see
a "Root delay" and "Root dispersion" of 15us in the output of `chronyc
ntpdata'. It doesn't vary, its always 15us.

I've verified that the packets themselves flowing from server to
client have a "Root Delay" and a "Root dispersion" of 0 (via tcpdump),
so I'm guessing this must be getting calculated on the client, but I
can't figure out where or how.

[***@machine_b ~]$ sudo chronyc ntpdata
Remote address : 192.168.1.10 (C0A8010A)
Remote port : 123
Local address : 192.168.1.20 (C0A80114)
Leap status : Normal
Version : 4
Mode : Server
Stratum : 1
Poll interval : 0 (1 seconds)
Precision : -24 (0.000000060 seconds)
Root delay : 0.000015 seconds
Root dispersion : 0.000015 seconds
Reference ID : 50545030 (PTP0)
Reference time : Fri Jun 23 20:31:30 2017
Offset : +0.000001374 seconds
Peer delay : 0.000114600 seconds
Peer dispersion : 0.000000397 seconds
Response time : 0.000064935 seconds
Jitter asymmetry: +0.00
NTP tests : 111 111 1101
Interleaved : Yes
Authenticated : No
TX timestamping : Kernel
RX timestamping : Kernel
Total TX : 3410
Total RX : 3410
Total valid RX : 3410

[1] http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/

[Miroslav Lichvar]

Post by Chris Perl
What I'm trying to understand is why on machine_b, I consistently see
a "Root delay" and "Root dispersion" of 15us in the output of `chronyc
ntpdata'. It doesn't vary, its always 15us.
I've verified that the packets themselves flowing from server to
client have a "Root Delay" and a "Root dispersion" of 0 (via tcpdump),
so I'm guessing this must be getting calculated on the client, but I
can't figure out where or how.

The root delay and dispersion fields printed by the ntpdata command
are the values from the received packet. They should be the same as
printed by tcpdump. Can you post tcpdump -v -x output?

The reason why they are always 15 microseconds is that the fields have
a 32-bit fixed-point format with ~15 microsecond resolution and
chronyd as a server rounds them up. So, if it calculates its delay and
dispersion as 1 microsecond, they will still be rounded to 15
microseconds. It's a limitation of the NTPv4 protocol. I'd like to
improve this in NTPv5 when the NTP WG starts working on a new version.

If you wanted to get a more accurate root distance on the client, you
could set the delay of the SHM refclock on the server to 0 and add
half of the delay to the precision instead. I think it might have a
small effect on the timekeeping performance though.

[Horia Muntean]

What are the reported values if you use the PTP hardware clock (PHC)
as a reference clock on the ntp server instead of SHM ? This way you
can get rid of the delays introduced by phc2sys (I suppose you use
ptp4l to synchronize the PHC to PTP grandmaster and then phc2sys to
synchronize the SHM to PHC).

Post by Miroslav Lichvar

Post by Chris Perl
What I'm trying to understand is why on machine_b, I consistently see
a "Root delay" and "Root dispersion" of 15us in the output of `chronyc
ntpdata'. It doesn't vary, its always 15us.
I've verified that the packets themselves flowing from server to
client have a "Root Delay" and a "Root dispersion" of 0 (via tcpdump),
so I'm guessing this must be getting calculated on the client, but I
can't figure out where or how.

The root delay and dispersion fields printed by the ntpdata command
are the values from the received packet. They should be the same as
printed by tcpdump. Can you post tcpdump -v -x output?
The reason why they are always 15 microseconds is that the fields have
a 32-bit fixed-point format with ~15 microsecond resolution and
chronyd as a server rounds them up. So, if it calculates its delay and
dispersion as 1 microsecond, they will still be rounded to 15
microseconds. It's a limitation of the NTPv4 protocol. I'd like to
improve this in NTPv5 when the NTP WG starts working on a new version.
If you wanted to get a more accurate root distance on the client, you
could set the delay of the SHM refclock on the server to 0 and add
half of the delay to the precision instead. I think it might have a
small effect on the timekeeping performance though.
--
Miroslav Lichvar
--
with "unsubscribe" in the subject.
with "help" in the subject.

[Chris Perl]

Post by Miroslav Lichvar
The root delay and dispersion fields printed by the ntpdata command
are the values from the received packet. They should be the same as
printed by tcpdump. Can you post tcpdump -v -x output?

I guess I must have confused myself somehow. Looking at tcpdump again
does indeed show that the values coming from the server to the client
are 15us for both "Root delay" and "Root dispersion."

Post by Miroslav Lichvar
The reason why they are always 15 microseconds is that the fields have
a 32-bit fixed-point format with ~15 microsecond resolution and
chronyd as a server rounds them up. So, if it calculates its delay and
dispersion as 1 microsecond, they will still be rounded to 15
microseconds. It's a limitation of the NTPv4 protocol. I'd like to
improve this in NTPv5 when the NTP WG starts working on a new version.
If you wanted to get a more accurate root distance on the client, you
could set the delay of the SHM refclock on the server to 0 and add
half of the delay to the precision instead. I think it might have a
small effect on the timekeeping performance though.

That is very helpful. Thanks!

[Chris Perl]

Post by Chris Perl

Post by Miroslav Lichvar
The reason why they are always 15 microseconds is that the fields have
a 32-bit fixed-point format with ~15 microsecond resolution and
chronyd as a server rounds them up. So, if it calculates its delay and
dispersion as 1 microsecond, they will still be rounded to 15
microseconds. It's a limitation of the NTPv4 protocol. I'd like to
improve this in NTPv5 when the NTP WG starts working on a new version.
If you wanted to get a more accurate root distance on the client, you
could set the delay of the SHM refclock on the server to 0 and add
half of the delay to the precision instead. I think it might have a
small effect on the timekeeping performance though.

That is very helpful. Thanks!

Are there any similar tricks to be able to get a more accurate root
dispersion on clients? In the setup I've been testing, chrony on the
server generally reports a root dispersion of about 1us. But, this is
getting rounded up to 15us due to the aforementioned fixed-point
format.

[Miroslav Lichvar]

Post by Chris Perl

Post by Chris Perl

Post by Miroslav Lichvar
If you wanted to get a more accurate root distance on the client, you
could set the delay of the SHM refclock on the server to 0 and add
half of the delay to the precision instead. I think it might have a
small effect on the timekeeping performance though.

That is very helpful. Thanks!

Are there any similar tricks to be able to get a more accurate root
dispersion on clients? In the setup I've been testing, chrony on the
server generally reports a root dispersion of about 1us. But, this is
getting rounded up to 15us due to the aforementioned fixed-point
format.

No, at least not with the current code. There might be a possibility
of moving the dispersion to the precision (which has an exponential
scale), which clients are supposed to include in their peer
dispersion, but I have not thought that through.

Do you need this to show compliance with the new MiFID directive?
I think one possibility here might be to reduce root delay on clients
by minimum latency of switches along the path to the server. If a
switch is guaranteed to add at least 5 microseconds in each direction,
you could substract 10 microseconds from the delay and get a more
accurate estimate of the maximum error.

[Chris Perl]

Post by Miroslav Lichvar
Do you need this to show compliance with the new MiFID directive?
I think one possibility here might be to reduce root delay on clients
by minimum latency of switches along the path to the server. If a
switch is guaranteed to add at least 5 microseconds in each direction,
you could substract 10 microseconds from the delay and get a more
accurate estimate of the maximum error.

Yes, exactly.

The idea about some minimum about of delay introduced by the switches
is interesting. I'll have to think about that one a bit harder.

What I had been considering as a workaround was something like:

Record the root dispersion on the server on some regular interval (say
every few seconds or so).

When looking at a given client's stats (`chronyc tracking' output)
over some time interval, if you take the max dispersion reported by
the server over that same interval, round up to the nearest 15us
boundary and subtract the root dispersion, that value can be
subtracted from the clients reported root dispersion.

As an example, if over some interval the server reported a max root
dispersion of 2us (`chronyc tracking' on the server), then you could
subtract 13us from the reported root dispersion for clients that were
tracking this server over that same interval.

[Miroslav Lichvar]

Post by Chris Perl
Record the root dispersion on the server on some regular interval (say
every few seconds or so).
When looking at a given client's stats (`chronyc tracking' output)
over some time interval, if you take the max dispersion reported by
the server over that same interval, round up to the nearest 15us
boundary and subtract the root dispersion, that value can be
subtracted from the clients reported root dispersion.

Yes, I think that could work. I'm wondering if it would make sense to
add root delay and dispersion to the tracking log.

[Horia Muntean]

Post by Miroslav Lichvar
Yes, I think that could work. I'm wondering if it would make sense to
add root delay and dispersion to the tracking log.

It would make sense if one wants to easily compute the estimated error
right from an existing log.
It can be computed from measurements.log but you must join it with
tracking.log anyway so see what's the current source.
More, if the source is a reference clock measurements.log will not help at all.

[Miroslav Lichvar]

Post by Horia Muntean

Post by Miroslav Lichvar
Yes, I think that could work. I'm wondering if it would make sense to
add root delay and dispersion to the tracking log.

It would make sense if one wants to easily compute the estimated error
right from an existing log.
It can be computed from measurements.log but you must join it with
tracking.log anyway so see what's the current source.
More, if the source is a reference clock measurements.log will not help at all.

Ok. I agree it could be useful.

Do you think it would be better to write there the delay and
dispersion as was estimated right before the update of the clock to
get the maximum value of dispersion, or rather use the new values from
the update, assuming the user will calculate the amount of dispersion
that accumulated till the next update?

[Horia Muntean]

Post by Miroslav Lichvar
Ok. I agree it could be useful.
Do you think it would be better to write there the delay and
dispersion as was estimated right before the update of the clock to
get the maximum value of dispersion, or rather use the new values from
the update, assuming the user will calculate the amount of dispersion
that accumulated till the next update?
--
Miroslav Lichvar

How would one compute the estimated error of the system time from UTC
at any point in time from information given by 'chronyc tracking' ?
Is 'System Time' + 'Root Delay' / 2 + 'Root Dispersion' the correct formula ?
If yes then then all these 3 values would be helpful to be put in
tracking.log (or maybe other log) regardless
they are before or after an update as long as they are consistent
(they refer to the state of time from the same moment).

For consistency maybe they should be the values 'chronyc tracking'
would display after the last update.

[Bill Unruh]

Isn't that information all there already in the "measurements" log?


William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Horia Muntean

Post by Miroslav Lichvar
Ok. I agree it could be useful.
Do you think it would be better to write there the delay and
dispersion as was estimated right before the update of the clock to
get the maximum value of dispersion, or rather use the new values from
the update, assuming the user will calculate the amount of dispersion
that accumulated till the next update?
--
Miroslav Lichvar

How would one compute the estimated error of the system time from UTC
at any point in time from information given by 'chronyc tracking' ?
Is 'System Time' + 'Root Delay' / 2 + 'Root Dispersion' the correct formula ?
If yes then then all these 3 values would be helpful to be put in
tracking.log (or maybe other log) regardless
they are before or after an update as long as they are consistent
(they refer to the state of time from the same moment).
For consistency maybe they should be the values 'chronyc tracking'
would display after the last update.
--

[Horia Muntean]

AFAIK in measurements.log there is no info that points to the source clock
so if one has more sources you would have to look at tracking.log to
see whats the current source.

Second in measurements.log there are no records if the source clock is
a reference clock.

Third 'System Time' from 'chronyc tracking' command is the difference
between the
chronyd's estimate of the current true time and the system time. This
difference together with root delay and
dispersion can give you the estimated maximum error from UTC.

At least this is my understanding - it might be wrong.

See https://www.mail-archive.com/chrony-***@chrony.tuxfamily.org/msg01196.html

<quote>
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
</quote>

Post by Bill Unruh
Isn't that information all there already in the "measurements" log?
William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Horia Muntean

Post by Miroslav Lichvar
Ok. I agree it could be useful.
Do you think it would be better to write there the delay and
dispersion as was estimated right before the update of the clock to
get the maximum value of dispersion, or rather use the new values from
the update, assuming the user will calculate the amount of dispersion
that accumulated till the next update?
--
Miroslav Lichvar

How would one compute the estimated error of the system time from UTC
at any point in time from information given by 'chronyc tracking' ?
Is 'System Time' + 'Root Delay' / 2 + 'Root Dispersion' the correct formula ?
If yes then then all these 3 values would be helpful to be put in
tracking.log (or maybe other log) regardless
they are before or after an update as long as they are consistent
(they refer to the state of time from the same moment).
For consistency maybe they should be the values 'chronyc tracking'
would display after the last update.
--

--
"unsubscribe" in the subject.
subject.

[Miroslav Lichvar]

Post by Horia Muntean
How would one compute the estimated error of the system time from UTC
at any point in time from information given by 'chronyc tracking' ?
Is 'System Time' + 'Root Delay' / 2 + 'Root Dispersion' the correct formula ?

Yes, that would be a good estimate of the maximum error. When the
clock is synchronized and the system time offset is just noise which
is already included in the dispersion, I guess the first term can be
ignored.

Post by Horia Muntean
If yes then then all these 3 values would be helpful to be put in
tracking.log (or maybe other log) regardless
they are before or after an update as long as they are consistent
(they refer to the state of time from the same moment).

The value of the "System time" offset right after the update can be
calculated by adding (or substracting?) "Offset" and "Rem. corr.". It
decreases over time at a rate which can be calculated from "Offset sd"
and corrtimeratio in chrony.conf.

Post by Horia Muntean
For consistency maybe they should be the values 'chronyc tracking'
would display after the last update.

The trouble is that the dispersion is not constant. It's increasing at
a rate of MAX(skew, maxclockerr) and the formula could change in a
future version of chrony.

If the log had root dispersion right before clock update, one could
get a (slightly more pessimistic) estimate of the maximum error simply
by adding values from the log (root delay and dispersion from one
line, and offset and remaining correction from the previous line).

[Horia Muntean]

Post by Miroslav Lichvar

Post by Horia Muntean
How would one compute the estimated error of the system time from UTC
at any point in time from information given by 'chronyc tracking' ?
Is 'System Time' + 'Root Delay' / 2 + 'Root Dispersion' the correct formula ?

Yes, that would be a good estimate of the maximum error. When the
clock is synchronized and the system time offset is just noise which
is already included in the dispersion, I guess the first term can be
ignored.

Post by Horia Muntean
If yes then then all these 3 values would be helpful to be put in
tracking.log (or maybe other log) regardless
they are before or after an update as long as they are consistent
(they refer to the state of time from the same moment).

The value of the "System time" offset right after the update can be
calculated by adding (or substracting?) "Offset" and "Rem. corr.". It
decreases over time at a rate which can be calculated from "Offset sd"
and corrtimeratio in chrony.conf.

Post by Horia Muntean
For consistency maybe they should be the values 'chronyc tracking'
would display after the last update.

The trouble is that the dispersion is not constant. It's increasing at
a rate of MAX(skew, maxclockerr) and the formula could change in a
future version of chrony.
If the log had root dispersion right before clock update, one could
get a (slightly more pessimistic) estimate of the maximum error simply
by adding values from the log (root delay and dispersion from one
line, and offset and remaining correction from the previous line).
--
Miroslav Lichvar

The root dispersion just after a clock update contains what the server
reports right ?
In my opinion the values (root delay end dispersion) taken just after
the clock update
along with a short update interval (less than few seconds) would give
a good max. error estimate.
In a short amount of time between the updates the root dispersion
should not increase too much.
And for a good synchronization I don't think one can afford large
update intervals.

[Bill Unruh]

Post by Horia Muntean
And for a good synchronization I don't think one can afford large
update intervals.

The problem is that with short update intervals, the value of the drift becomes more
uncertain, and thus the uncertainty in the next value of the offset becomes
larger due to the uncertainty of the drift. This becomes more important if you
lose updates dues to line noise, disconnections etc. Chrony is better than
ntpd because it uses the last N offsets to estimate the drift, but N varies
from 3 to about 60, so is usually better on both the drift and the offset.

[Miroslav Lichvar]

Post by Horia Muntean
The root dispersion just after a clock update contains what the server
reports right ?

It includes dispersion that accumulated since the best measurement was
made (it doesn't have to be the last one) and also peer dispersion of
the measurement.

Post by Horia Muntean
In my opinion the values (root delay end dispersion) taken just after
the clock update
along with a short update interval (less than few seconds) would give
a good max. error estimate.
In a short amount of time between the updates the root dispersion
should not increase too much.

If the network is heavily loaded, chronyd may drop a large number of
consecutive measurements.

I think what people are interested in is the maximum possible error of
the clock at any time, not just the points when the clock was updated.

If we know at time t the error was 10 +/- 50 microseconds and at time
t+100 (seconds) it was -20 +/- 70 microseconds, what can we say about
t+1, t+50 and t+99, if we assume the frequency of clock is accurate to
1 ppm?

[Horia Muntean]

Post by Miroslav Lichvar

Post by Horia Muntean
The root dispersion just after a clock update contains what the server
reports right ?

It includes dispersion that accumulated since the best measurement was
made (it doesn't have to be the last one) and also peer dispersion of
the measurement.

Post by Horia Muntean
In my opinion the values (root delay end dispersion) taken just after
the clock update
along with a short update interval (less than few seconds) would give
a good max. error estimate.
In a short amount of time between the updates the root dispersion
should not increase too much.

If the network is heavily loaded, chronyd may drop a large number of
consecutive measurements.
I think what people are interested in is the maximum possible error of
the clock at any time, not just the points when the clock was updated.

I agree. Maybe a whole different log with this info would be more appropriate
or one should should just put 'chronyc -n tracking' in a loop and
compute system_time + root_delay / 2 + root_dispersion ?

Post by Miroslav Lichvar
If we know at time t the error was 10 +/- 50 microseconds and at time
t+100 (seconds) it was -20 +/- 70 microseconds, what can we say about
t+1, t+50 and t+99, if we assume the frequency of clock is accurate to
1 ppm?

In 100 seconds you would have a maximum drift of 100 ppm = 100 us
and so in 100 seconds your error could grow to 60 + 100 = 160 us.
But because at the second measurement you have only a 90 us error it means
that during 100 seconds period the error was not higher then 90 us ?
Or that was a rhetorical question ?

[Miroslav Lichvar]

Post by Horia Muntean

Post by Miroslav Lichvar
I think what people are interested in is the maximum possible error of
the clock at any time, not just the points when the clock was updated.

I agree. Maybe a whole different log with this info would be more appropriate
or one should should just put 'chronyc -n tracking' in a loop and
compute system_time + root_delay / 2 + root_dispersion ?

I think the log should provide all necessary information to avoid
having to run chronyc in a loop.

Post by Horia Muntean

Post by Miroslav Lichvar
If we know at time t the error was 10 +/- 50 microseconds and at time
t+100 (seconds) it was -20 +/- 70 microseconds, what can we say about
t+1, t+50 and t+99, if we assume the frequency of clock is accurate to
1 ppm?

In 100 seconds you would have a maximum drift of 100 ppm = 100 us
and so in 100 seconds your error could grow to 60 + 100 = 160 us.
But because at the second measurement you have only a 90 us error it means
that during 100 seconds period the error was not higher then 90 us ?

I'm not sure if that is safe to assume. I think the error could go up
and then down in the interval. The question is what should be reported
in the log in order to give an estimate of maximum error.

- root dispersion right after the update
- root dispersion right before the update
- a combination of the two

[Horia Muntean]

Post by Miroslav Lichvar
I'm not sure if that is safe to assume. I think the error could go up
and then down in the interval. The question is what should be reported
in the log in order to give an estimate of maximum error.
- root dispersion right after the update
- root dispersion right before the update
- a combination of the two
--
Miroslav Lichvar

Considering both provide valuable info why not both ?

[Miroslav Lichvar]

Post by Horia Muntean

Post by Miroslav Lichvar
I'm not sure if that is safe to assume. I think the error could go up
and then down in the interval. The question is what should be reported
in the log in order to give an estimate of maximum error.
- root dispersion right after the update
- root dispersion right before the update
- a combination of the two

Considering both provide valuable info why not both ?

The latest code in git produces three additional fields in the
tracking log: root delay, root dispersion and maximum error using root
delay and dispersion as it is right before the update. I wasn't able
to figure out a good way to combine the data before and after update.
It can be improved later.

[Horia Muntean]

Post by Miroslav Lichvar
The latest code in git produces three additional fields in the
tracking log: root delay, root dispersion and maximum error using root
delay and dispersion as it is right before the update. I wasn't able
to figure out a good way to combine the data before and after update.
It can be improved later.
--
Miroslav Lichvar

***@spark:~/downloads/chrony-3.2-pre2$ tail -f /var/log/chrony/tracking.log
===================================================================================================================================
Date (UTC) Time IP Address St Freq ppm Skew ppm
Offset L Co Offset sd Rem. corr. Root delay Root disp. Max. error
===================================================================================================================================
2017-09-04 12:20:19 0.0.0.0 0 -3.374 0.319
0.000e+00 ? 0 0.000e+00 1.505e-16 1.000e+00 1.000e+00 1.500e+00
2017-09-04 12:20:28 192.168.254.122 2 -3.374 0.319
2.569e-06 N 1 9.987e-06 1.292e-10 9.488e-05 1.088e-03 1.500e+00
2017-09-04 12:20:32 192.168.254.122 2 -3.374 0.333
4.472e-06 N 1 5.106e-06 4.518e-10 7.142e-05 1.027e-03 1.145e-03
2017-09-04 12:20:36 192.168.254.122 2 -3.375 0.397
-1.854e-06 N 1 3.455e-06 -1.863e-06 7.142e-05 1.051e-03 1.073e-03
2017-09-04 12:20:40 192.168.254.122 2 -3.382 0.563
-4.762e-07 N 1 2.978e-06 -9.035e-09 8.081e-05 1.027e-03 1.093e-03
2017-09-04 12:20:44 192.168.254.122 2 -3.397 0.854
4.996e-07 N 1 2.085e-06 4.186e-07 8.081e-05 1.032e-03 1.074e-03
2017-09-04 12:20:48 192.168.254.122 2 -3.557 1.098
-3.358e-06 N 1 2.188e-06 -7.890e-08 7.458e-05 1.028e-03 1.080e-03
2017-09-04 12:20:52 192.168.254.122 2 -3.582 0.871
5.087e-07 N 1 2.359e-06 2.816e-08 7.458e-05 1.030e-03 1.078e-03
2017-09-04 12:20:56 192.168.254.122 2 -3.521 0.724
1.633e-06 N 1 2.427e-06 -4.157e-07 7.458e-05 1.032e-03 1.075e-03
2017-09-04 12:21:00 192.168.254.122 2 -3.544 0.535
-8.967e-07 N 1 2.171e-06 -8.854e-07 7.458e-05 1.032e-03 1.078e-03
2017-09-04 12:21:04 192.168.254.122 2 -3.558 0.396
-3.287e-07 N 1 1.881e-06 1.131e-08 7.458e-05 1.032e-03 1.076e-03
2017-09-04 12:21:08 192.168.254.122 2 -3.556 0.343
9.500e-08 N 1 1.978e-06 2.991e-07 7.458e-05 1.034e-03 1.076e-03
2017-09-04 12:21:12 192.168.254.122 2 -3.536 0.376
9.286e-07 N 1 2.591e-06 1.902e-07 7.458e-05 1.036e-03 1.077e-03
2017-09-04 12:21:16 192.168.254.122 2 -3.514 0.338
7.338e-07 N 1 2.475e-06 -5.981e-07 7.458e-05 1.035e-03 1.080e-03
2017-09-04 12:21:20 192.168.254.122 2 -3.503 0.279
3.578e-07 N 1 2.267e-06 -8.524e-07 7.458e-05 1.035e-03 1.079e-03
2017-09-04 12:21:24 192.168.254.122 2 -3.496 0.241
2.553e-07 N 1 2.183e-06 -7.818e-07 7.458e-05 1.036e-03 1.079e-03
2017-09-04 12:21:28 192.168.254.122 2 -3.491 0.211
2.499e-07 N 1 2.087e-06 -7.075e-07 7.458e-05 1.035e-03 1.079e-03

Thanks

But something is off:

***@spark:~# chronyc -n ntpdata 192.168.254.122
Remote address : 192.168.254.122 (C0A8FE7A)
Remote port : 123
Local address : 192.168.254.76 (C0A8FE4C)
Leap status : Normal
Version : 4
Mode : Server
Stratum : 1
Poll interval : 3 (8 seconds)
Precision : -18 (0.000003815 seconds)
Root delay : 0.000000 seconds
Root dispersion : 0.001022 seconds
Reference ID : 4D525300 (MRS)
Reference time : Mon Sep 04 09:26:22 2017
Offset : -0.000026464 seconds
Peer delay : 0.000123199 seconds
Peer dispersion : 0.000003835 seconds
Response time : 0.000317335 seconds
Jitter asymmetry: +0.00
NTP tests : 111 111 1111
Interleaved : No
Authenticated : No
TX timestamping : Daemon
RX timestamping : Kernel
Total TX : 91
Total RX : 91
Total valid RX : 91



***@spark:~# chronyc -n tracking
Reference ID : C0A8FE7A (192.168.254.122)
Stratum : 2
Ref time (UTC) : Mon Sep 04 12:26:28 2017
System time : 0.000000126 seconds fast of NTP time
Last offset : -0.000000720 seconds
RMS offset : 0.000000750 seconds
Frequency : 3.535 ppm slow
Residual freq : -0.001 ppm
Skew : 0.094 ppm
Root delay : 0.000071799 seconds
Root dispersion : 0.001026187 seconds
Update interval : 4.0 seconds
Leap status : Normal



192.168.254.122 is reported as stratum-1 in 'ntpdata' and as stratum-2
in 'tracking'. Why is that ?

[Miroslav Lichvar]

Post by Horia Muntean
192.168.254.122 is reported as stratum-1 in 'ntpdata' and as stratum-2
in 'tracking'. Why is that ?

ntpdata shows the values from the response of the NTP server, i.e.
stratum of the server itself. tracking shows the NTP values of the
local machine, which is a client of the server, i.e. its stratum is
one higher.

[Chris Perl]

Post by Miroslav Lichvar
I think the log should provide all necessary information to avoid
having to run chronyc in a loop.

Fwiw, this is basically what I'm doing.