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

[Horia Muntean]

On Wed, Aug 23, 2017 at 5:40 PM, Miroslav Lichvar  wrote:

> 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


trainer@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:

root@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.03815 seconds)
Root delay  : 0.00 seconds
Root dispersion : 0.001022 seconds
Reference ID: 4D525300 (MRS)
Reference time  : Mon Sep 04 09:26:22 2017
Offset  : -0.26464 seconds
Peer delay  : 0.000123199 seconds
Peer dispersion : 0.03835 seconds
Response time   : 0.000317335 seconds
Jitter asymmetry: +0.00
NTP tests   : 111 111 
Interleaved : No
Authenticated   : No
TX timestamping : Daemon
RX timestamping : Kernel
Total TX: 91
Total RX: 91
Total valid RX  : 91



root@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.00126 seconds fast of NTP time
Last offset : -0.00720 seconds
RMS offset  : 0.00750 seconds
Frequency   : 3.535 ppm slow
Residual freq   : -0.001 ppm
Skew: 0.094 ppm
Root delay  : 0.71799 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 ?

-- 
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.

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

[Chris Perl]

On Mon, Aug 14, 2017 at 4:09 AM, Miroslav Lichvar  wrote:
> 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.

-- 
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.

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

[Horia Muntean]

On Mon, Aug 14, 2017 at 11:09 AM, Miroslav Lichvar  wrote:
> 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 ?

-- 
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.

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

[Miroslav Lichvar]

On Thu, Aug 10, 2017 at 05:47:26PM +0300, Horia Muntean wrote:
> On Thu, Aug 10, 2017 at 4:49 PM, Miroslav Lichvar  wrote:
> > 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.

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

-- 
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.

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

[Horia Muntean]

On Thu, Aug 10, 2017 at 4:49 PM, Miroslav Lichvar  wrote:
> On Thu, Aug 10, 2017 at 01:22:25PM +0300, Horia Muntean wrote:
>> 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.
>
>> 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 ?

> 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 ?

-- 
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.

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

[Miroslav Lichvar]

On Thu, Aug 10, 2017 at 01:22:25PM +0300, Horia Muntean wrote:
> 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.

> 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?

-- 
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.

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

[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-users@chrony.tuxfamily.org/msg01196.html


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


On Tue, Aug 8, 2017 at 6:50 PM, Bill Unruh  wrote:
> Isn't that information all there already in the "measurements" log?
>
>
> William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
> Physics _|___ Advanced Research _| Fax: +1(604)822-5324
> UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
> Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/
>
>
> On Tue, 8 Aug 2017, Horia Muntean wrote:
>
>> On Tue, Aug 8, 2017 at 5:07 PM, Miroslav Lichvar 
>> wrote:
>>>
>>> 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.
>>
>> --
>
>
> --
> 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.
>

-- 
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.

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

[Horia Muntean]

On Tue, Aug 8, 2017 at 5:07 PM, Miroslav Lichvar  wrote:
> 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.

-- 
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.

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

[Miroslav Lichvar]

On Tue, Aug 08, 2017 at 04:53:28PM +0300, Horia Muntean wrote:
> On Mon, Aug 7, 2017 at 12:11 PM, Miroslav Lichvar  wrote:
> > 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?

-- 
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.

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

[Horia Muntean]

On Mon, Aug 7, 2017 at 12:11 PM, Miroslav Lichvar  wrote:
> 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.

-- 
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.

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

[Miroslav Lichvar]

On Fri, Aug 04, 2017 at 11:12:08AM -0400, Chris Perl wrote:
> 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.

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

-- 
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.

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

[Chris Perl]

On Fri, Aug 4, 2017 at 4:30 AM, Miroslav Lichvar  wrote:
> 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.

-- 
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.

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

[Chris Perl]

On Mon, Jun 26, 2017 at 9:28 AM, Chris Perl  wrote:
>> 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.

-- 
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.

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

[Chris Perl]

On Mon, Jun 26, 2017 at 4:37 AM, Miroslav Lichvar  wrote:
> 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."

> 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!

-- 
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.

[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.

[cperl@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.00060 seconds)
Root delay  : 0.15 seconds
Root dispersion : 0.15 seconds
Reference ID: 50545030 (PTP0)
Reference time  : Fri Jun 23 20:31:30 2017
Offset  : +0.01374 seconds
Peer delay  : 0.000114600 seconds
Peer dispersion : 0.00397 seconds
Response time   : 0.64935 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/

-- 
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.