Re: [Linuxptp-users] gPTP issues with ntpd

[Jakub R. <j.r...@el...>]

> 21.07.2022 10:20 Miroslav Lichvar <mli...@re...> wrote:
> 
>  
> On Wed, Jul 20, 2022 at 05:57:57PM +0200, Jakub Raczyński wrote:
> > So this setup seems to be correct and from the phc2sys log I sent previously it seems to be. So it seems that phc2sys is correctly writing timestamps to ntpshm only when it is Slave.
> 
> No, that's not correct. Try running the ntpshmmon tool from gpsd to
> see that phc2sys is writing new samples in both directions.

You are mistaken, I did try ntpshmmon and it does write to ntpshm only in one direction as Slave. When device switches to Master it stops writing to ntpshm. But from your reaction I assume this is unintended? Because it would work perfectly if not for the ntpd reset bug.

> 
> > The only problem is caused by ntpd reset - it starts synchronizing to PTP (ntpshm) even if it shouldn't as is it Master.
> 
> If you have multiple sources configured for ntpd, it could be
> rejecting the SHM as a falseticker when the TAI-UTC correction in
> phc2sys flips. On a restart/reset and depending on the polling
> intervals, it could temporarily select the SHM source for
> synchronization and later reject it again.
> 
> Try it with SHM as the only source. That should make it obvious
> that this cannot work.

I did and yet again it works and switches direction of synchronization perfectly. Yet again, goal is to achieve ntpshm as clock source in Slave state and CLOCK_REALTIME as Master clock for the network. I do not expect ntpshm to be two-way synchronization clock.

As such, since data is not written to ntpshm, I assume that phc2sys does select direction incorrectly after ntpd reset when significant offset was present. Seems like servo reset issue that does not update direction or sets it incorrectly. I will probably debug it in following days but I had hoped you could be of assistance.

Best regards
Jakub Raczynski