William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ 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 Mon, 24 Apr 2017, Chris Perl wrote:

On Thu, Apr 20, 2017 at 5:32 AM, Miroslav Lichvar <mlich...@redhat.com> wrote:
Yes. That's a good description. If you would like to improve the
manual pages, I'll gladly accept patches :).

I'll take another read through what is already there and see if I
think I can add anything useful.

The root distance (root delay / 2 + root dispersion) is the
uncertainty of the "true" time, which is increasing when no updates of
the clock are made. You can graph "system time" +/- "root distance" to
show the maximum assumed error of the clock at given time.

Graphing "last offset" can be useful to show the stability of the
synchronization and estimate the minimum error of the clock.

Great, thanks, that was very helpful.

In my setup it seems the largest potential error comes from the root
delay piece (in my case, usually something like 50us).

I believe that taking one half that value is essentially saying that
its possible that the delay is asymmetric with one direction being
instantaneous and the other taking the full amount of the measured
round trip.

Yes. but without other information that is all you can say. Remember what it
says is "maximum error". You need more information on the distribution of the
delays to make stronger statements.



That would obviously not generally be the case in a reasonable
network.  Although I guess "reasonable" is the important part of that
sentence.

But what is a "reasonable network"? Is it defined as one where that does not
happen? And how do you know your network is "reasonable"?



But, I think what you're saying is I could watch the measured offsets
to get a "feel" for how stable things seem to be.

The problem is that those measured offsets will only give a feel for the
"random" component of the offset variation. Thus if there is a gate which adds
50us to every outbound packet there is not way that watching the offsets will
give you a hint that that could be happening. Of course you could put in another clock (GPS, atomic clock,...) and get a
feel for whether or not such a systematic error exists.



Maybe something like the following set of statements:

1.  If there is asymmetry, its unlikely it is constant for the entire
life of the chrony process, assuming you're running chrony for a

I would not say it is unlikely. There may well be a reason why one leg or the
other has a very consistant extra delay, which does not vary.

reasonable period and have a reasonably designed network and your time
sources are located reasonably close ("reasonable" can obviously be
different for different people).

Not sure what that sentence says to anyone.



2.  If the asymmetry is totally constant, there isn't much you can do
to detect it.

Sure you can. PUt other clocks which do not have that assymmetry on both ends.



3.  If there is asymmetry, it would seem unlikely (although not
impossible) that it would change in such a way that the TX delay and
the RX delay both changed by the same amount with opposite signs
(meaning you wouldn't actually see any change to the offset
measurements).

These statements are so wishy washy that they do not really add anything for
anyone reading them.



4.  If asymmetry is introduced then its possible we could detect that
via the offsets.  Either seeing some step in the offsets or just an
increase in the variability of the offset measurements.

See for example the graphs in www.theory.physics.ubc.ca/chrony/chrony.html
at the bottom of the page. These are offset vs delay graphs. They all clearly
show that the larger offsets come from assymetric random delays. There is a
correlation between offset and delay which would not be there if the delays
were symmetric and random. This of course does not mean that there are not also systematic assymmetry in
the delays which would not show up in such a scatter plot.



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

Reply via email to