Re: [Linuxptp-users] Failed synchronization

[Daniel Le <dan...@ex...>]

Hi Richard, please see follow-up comments and questions inline.

-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...] 
Sent: Thursday, August 04, 2016 4:34 PM
To: Daniel Le <dan...@ex...>
Cc: lin...@li...
Subject: Re: [Linuxptp-users] Failed synchronization

On Thu, Aug 04, 2016 at 07:36:45PM +0000, Daniel Le wrote:
> I have frequent synchronization issue on a PTP ordinary clock which 
> has Linux kernel 3.18.12 and LinuxPTP v1.6. It runs in slave mode with 
> software timestamping.

You didn't tell us what hardware your are using: platform, NIC, driver?
[DL] It's an embedded system with proprietary FPGA based NIC and driver.

> To force the problem to occur every time, I change the system clock to 
> be approximately 5 minutes ahead of PTP Grandmaster clock. In the 
> following, the (enhanced) log messages show ptp4l correctly steps the 
> system clock with the observed offset, then transitions into 
> SERVO_LOCKED state, however the master offset as seen by ptp4l keeps 
> increasing afterwards. The slew and PI reset operations seem not to be 
> able to keep up.

After stepping the clock, the offset remains the same.  Your system clock or the MAC driver is somehow broken.
[DL] Is tsproc_update_offset function a good place where to check t1, t2, t3, t4 values
         in order to see which timestamp(s) may cause the offset to remain the same?
[DL] In this function, are master timestamps (t1, t4) TAI and slave timestamps (t2, t3) UTC?

Also, the frequency estimation that occurs between UNCALIBRATED and SLAVE runs off the scale.  Is your local oscillator really that bad?
[DL] I can't explain why... but if the system is rebooted then synchronization works fine, while a restart of ptp4l doesn't make a difference.

No idea how your computer could be so messed up.

Sorry,
Richard