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

2017-09-04 Thread 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

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

2017-08-16 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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. > >

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

2017-08-10 Thread 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

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

2017-08-10 Thread 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

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

2017-08-09 Thread 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

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

2017-08-08 Thread 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

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

2017-08-08 Thread 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

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

2017-08-08 Thread 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

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

2017-08-07 Thread 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'

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

2017-08-04 Thread 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

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

2017-08-03 Thread 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 >>

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

2017-06-26 Thread 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

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

2017-06-23 Thread 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