> 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
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 :
2017-08-31 14:58 GMT+02:00 Bill Unruh <un...@physics.ubc.ca>:
> 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
> 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
>>> out because it did not get the interrupt until the first one had
>>> 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-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.