Message-ID: <20200726110104.GV1605@shell.armlinux.org.uk>
Date:   Sun, 26 Jul 2020 12:01:05 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>,
        Richard Cochran <richardcochran@...il.com>,
        netdev@...r.kernel.org
Subject: Re: phc2sys - does it work?

On Sat, Jul 25, 2020 at 04:29:16PM +0300, Vladimir Oltean wrote:
> Just a sanity check: do you have this patch?
> https://github.com/richardcochran/linuxptp/commit/e0580929f451e685d92cd10d80b76f39e9b09a97

I did not, as I was running Debian stable's 1.9.2 version, whereas
current git head for linuxptp appears to behave much better.  Thanks.

I've got to the bottom of stuff like:

phc2sys[7190.912]: /dev/ptp1 sys offset        81 s2 freq  -71290 delay    641
phc2sys[7191.912]: /dev/ptp1 sys offset        66 s2 freq  -71281 delay    640
phc2sys[7192.912]: /dev/ptp1 sys offset      -926 s2 freq  -72253 delay    640
phc2sys[7193.912]: /dev/ptp1 sys offset     -8124 s2 freq  -79729 delay    680
phc2sys[7194.912]: /dev/ptp1 sys offset     -7794 s2 freq  -81836 delay    641
phc2sys[7195.913]: /dev/ptp1 sys offset     -5355 s2 freq  -81735 delay    680
phc2sys[7196.913]: /dev/ptp1 sys offset     -2994 s2 freq  -80981 delay    680
phc2sys[7197.913]: /dev/ptp1 sys offset     -1336 s2 freq  -80221 delay    640
phc2sys[7198.913]: /dev/ptp1 sys offset      -422 s2 freq  -79708 delay    640
phc2sys[7199.913]: /dev/ptp1 sys offset        -9 s2 freq  -79421 delay    680
phc2sys[7200.913]: /dev/ptp1 sys offset       159 s2 freq  -79256 delay    640
phc2sys[7201.913]: /dev/ptp1 sys offset       211 s2 freq  -79156 delay    680

This is due to NTP.  Each NTP period (starting at 64s), ntpd updates
the kernel timekeeping variables with the latest information.  One of
these is the offset, which is applied to the kernel's timekeeping by
adjusting the length of a tick:

        /* Compute the phase adjustment for the next second */
        tick_length      = tick_length_base;

        delta            = ntp_offset_chunk(time_offset);
        time_offset     -= delta;
        tick_length     += delta;

This has the effect of slightly changing the length of a second to slew
small adjustments, which appears as a change of frequency compared to
the PTP clock.  As we progress through the NTP period, the amount of
adjustment is reduced (notice that time_offset is reduced.)  When
time_offset hits zero, then no further adjustment is made, and the rate
that the kernel time passes settles - and in turn phc2sys settles to
a stable "freq" figure.

What this means is that synchronising the PTP clock to the kernel time
on a second by second basis exposes the PTP clock to these properties
of the kernel NTP loop, which has the effect of throwing the PTP clock
off by a 10s of PPM.

One way around this would be to synchronise the PTP clock updates with
NTP updates, but that is difficult due to NTP selecting how often it
does its updates - it generally starts off at 64s, and the interval
increases through powers of two.  However, just specifying -R to
phc2sys does not give better results - the amount that the PTP clock
fluctuates just gets larger.

Another solution would be to avoid running NTP on any machine intending
to be the source of PTP time on a network, but that then brings up the
problem that you can't synchronise the PTP time source to a reference
time, which rather makes PTP pointless unless all that you're after is
"all my local machines say the same wrong time."

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists