Re: [chrony-users] Time offset on versions 3+ without hw timestamping

[Thibaut BEYLER <thibautbeyler@xxxxxxxxx>]

So the same timestamping combination that the client is using to
synchronize its clock is used in the monitoring? I'm not sure if that
is a valid test. If there is a large asymmetry and the clock has a
large error, I don't think the monitoring client would see it, because
the asymmetry would cancel the error out in the opposite direction, in
which the monitoring client is making measurements.

In order to measure the error with SW timestamping it's necessary to
use something better, e.g. HW timestamping or a reference clock.

You could run a separate server instance of chronyd on a different
port with HW timestamping for the monitoring client. It needs to
support the interleaved mode to be able to get the server's HW
transmit timestamps.

Ok i think i understand what you mean, i will try to configure a server instance to see if there is differencies. What source should i configure on that instance ?

With 3.2-pre2 you can disable it with "asymmetry 0.0" in the server
directive.

I tried to force the jitter asymmetry to 0 and got good results again. Also with this settings test C are not failing anymore.

With the default chrony settings the asymmetry and test C failures are all occuring with sources coming from different ntp output (SW and HW) of two timervers from the same vendor.

With a third timeserver (sw ntp output only) no asymmetry is detected and the results are good.

The jitter asymmetry goes especially very fast from 0 to +0.50 with the sources that have hw timestamping, here are some logs just after a chrony restarts for instance :

https://pastebin.com/fSHuw7Mx

2017-08-31 14:58 GMT+02:00 Bill Unruh <unruh@xxxxxxxxxxxxxx>:

It has been a while now and I do not entirely remember. I wrote my own
interrupt handler module, which would grab the time immediately that it was
called by the kernel to service the interrupt, so it was effectively the
kernel that was servicing the timestamping. If I recall correctly I had two
modules attached to two interrupts, but of course one would be called before
theother, and that would give a delay in the servicing.

On Thu, 31 Aug 2017, Miroslav Lichvar wrote:

On Wed, Aug 30, 2017 at 12:14:05PM -0700, Bill Unruh wrote:

You could run a separate server instance of chronyd on a different
port with HW timestamping for the monitoring client. It needs to
support the interleaved mode to be able to get the server's HW
transmit timestamps.

The problem is interrupt contention, and clock reading contention. I once
tried to have two different readers (chrony and ntpd, or two versions of
chrony) reading the interrupt at the same time and one of them was about 8us
out because it did not get the interrupt until the first one had finished.
Ie, in monitoring you do not want to do it "on the second" since it might
interfere with the other one.

Was that with timestamping of PPS in userspace using ioctl(TIOCMIWAIT)?

I don't think that applies to timestamping of NTP packets. A receive
timestamp is made by the kernel, not by the application, and separate
instances of chronyd are not receiving both the same packet. They
won't share the same UDP port.

When running multiple instances of chronyd, it's important than only
one of them is adjusting the clock. Also, they should be configured to
use different "port", "cmdport", "bindcmdaddress", and "pidfile".

--
Miroslav Lichvar

--
To unsubscribe email chrony-users-request@xxxxxxxxxxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxfamily.org
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxg.

--
To unsubscribe email chrony-users-request@xxxxxxxxxxfamily.org with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxfamily.org with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxg.