[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200726212952.GF1551@shell.armlinux.org.uk>
Date: Sun, 26 Jul 2020 22:29:53 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Richard Cochran <richardcochran@...il.com>
Cc: Vladimir Oltean <olteanv@...il.com>, netdev@...r.kernel.org
Subject: Re: phc2sys - does it work?
On Sun, Jul 26, 2020 at 11:05:51AM -0700, Richard Cochran wrote:
> On Sun, Jul 26, 2020 at 12:01:05PM +0100, Russell King - ARM Linux admin wrote:
> > 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."
>
> It is clear that you can't have two services both adjusting the system
> time. For example, running ntpd and chrony on the same machine won't
> work, and neither does running ntpd with 'phc2sys -a -r'.
You've misunderstood, that is not what I'm doing. The system time on
the machine is sync'd using ntpd, and then I'm syncing the PTP clock
to alone to the system time. Right now, I'm just testing the PTP
clock implementation, nothing else, to make sure that it is implemented
properly.
So, the setup is:
+----------+ +--------------------------+
| host 1 | | test host | freq
GPS ---> ntpd ---- lan ---> ntpd -> system -> TAI ---> PPS -> counter
| | | time |
+----------+ +--------------------------+
The good news is - the whole thing has mostly settled - I no longer
see large swings in the PPS signal produced by the PTP/TAI clock,
where large is 10s of PPM. I'm now down to a frequency error of
around 500PPB.
I think what was going on is ntpd on the test host was switching
between different time sources, causing it to almost constantly slew
the system time on the test host.
I have noticed that phc2sys can sometimes get confused and it needs
phc_ctl to reset the frequency back to zero for it to have another go.
The hardware is capable of a max_adj of S32_MAX, and I think that
allows phc2sys to get confused sometimes, so I probably need to clamp
my calculated max_adj to a sane limit. Is there an upper limit that
phc2sys expects?
Thanks.
--
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