Re: [chrony-users] chronyc tracking question

[Chris Perl]

On Thu, Jul 27, 2017 at 4:57 AM, Miroslav Lichvar  wrote:
> On Wed, Jul 26, 2017 at 06:15:13PM -0400, Chris Perl wrote:
>> I'm pretty sure the interleaving gets messed up and I don't wind up
>> getting back the timestamp from the previous exchange (i.e. I'm losing
>> out on the hardware timestamping of t3 on the server).  I think that
>> accounts for the extra 15us that I'm seeing.
>
> Your analysis is correct.

Thanks for confirming.

> With the current implementation, interleaved mode with multiple
> clients on the same IP address is not expected to work. The man page
> mentions this issue with multiple clients behind NAT.

Doh.  Next time I'll try to read the man page more carefully.

> Modifying the code to keep track of individual ports wouldn't help,
> because clients usually change their port between requests.

I had come to the same realization a few hours after I had sent my prior email.

> The timestamps could be separate from IP addresses completely. This
> would allow multiple clients on the same IP address, or even clients
> that change their address between requests. However, a broken client
> sending too many request would be able to flush timestamps that belong
> to other clients. I'm not sure which is worse. There may be a better
> way to do this.

Interesting thought.  I agree with your sentiment, "I'm not sure which
is worse."

> As a workaround in your case, you could configure the monitoring
> client as a peer or you could run a second server instance on a
> different port serving local time.

I had thought of the latter, but not the former.  I'll try both and
see how I make out.

-- 
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] chronyc tracking question

[Miroslav Lichvar]

On Tue, Apr 25, 2017 at 08:19:54AM -0700, Bill Unruh wrote:
> On Tue, 25 Apr 2017, Miroslav Lichvar wrote:
> > For example, here is a client with an Intel i210 card running two
> > chronyd instances using the same server. One is using HW timestamping
> > and controlling the clock, the other is using SW timestamping and just
> > monitoring the server with the noselect option.
> 
> Running two instances of chrony means that one has to wait with its interrupt
> while the other finishes. That can give a large delay. I once tried that (not
> with one doing hardware timestamping however) and found a large delay (about
> 10us if I remember correctly) of the second waiting for the first.

The two instances are sending and receiving packets at different
times, which are timestamped by the kernel or the HW, so I think it
shouldn't matter. Currently it's necessary to use separate instances
for experiments like this, because the kernel doesn't allow SW
timestamping to be used together with HW timestamping. I'm working on
some patches that should remove this limitation.

-- 
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] chronyc tracking question

[Bill Unruh]

On Tue, 25 Apr 2017, Miroslav Lichvar wrote:


On Mon, Apr 24, 2017 at 03:54:25PM -0400, Chris Perl wrote:

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
reasonable period and have a reasonably designed network and your time
sources are located reasonably close ("reasonable" can obviously be
different for different people).


A major source of constant asymmetry is the timestamping. Unless you
are using HW timestamping, there can easily be an asymmetry of few
tens of microseconds due to interrupt coalescing and other delays in
the kernel, driver and HW. If both ends had the same asymmetry, it
would cancel out, but at least in my experience that's unusual. Even
if both machines had the same HW and SW, there may be a difference due
to the timing of the packets (i.e. server sends a response
immediatelly after receiving a request).

For example, here is a client with an Intel i210 card running two
chronyd instances using the same server. One is using HW timestamping
and controlling the clock, the other is using SW timestamping and just
monitoring the server with the noselect option.


Running two instances of chrony means that one has to wait with its interrupt
while the other finishes. That can give a large delay. I once tried that (not
with one doing hardware timestamping however) and found a large delay (about
10us if I remember correctly) of the second waiting for the first.

--
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] chronyc tracking question

[Chris Perl]

On Thu, Apr 20, 2017 at 5:32 AM, Miroslav Lichvar  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.

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

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.

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
reasonable period and have a reasonably designed network and your time
sources are located reasonably close ("reasonable" can obviously be
different for different people).

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

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

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.

-- 
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] chronyc tracking question

[Miroslav Lichvar]

On Wed, Apr 19, 2017 at 02:34:21PM -0400, Chris Perl wrote:
> I'm trying to figure out what metric(s) from `chronyc tracking' I
> should be logging and graphing to answer the question of "how far off
> is my system from its reference".

> The System time field from `chronyc tracking' represents the
> difference between what chrony believes the "true" time to be and the
> system time.  But, chrony is constantly updating its notion of what
> the "true" time is.  In the absence of updates, it simply does its job
> and drives that difference to 0.

Yes. That's a good description. If you would like to improve the
manual pages, I'll gladly accept patches :).

> If that is true, does that mean that I should be graphing the "System
> time", but that I need to be sure I've got sufficiently fresh samples
> to make sure the notion of the "true" time is correct?  Or, should I
> just be graphing the "Last offset", or perhaps something else
> entirely?

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.

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