Re: [Linuxptp-users] ptp4l and network connectivity interruption

[Richard C. <ric...@gm...>]

On Tue, Dec 08, 2015 at 11:27:29AM -0500, Brian Walsh wrote:
> Sorry if this has been asked before. The archives are unreachable on
> sourceforge. I keep getting an "Error 403 Read access required" when trying
> to view the list archives.

Yes, SF does have issues, and I want to move away from there,
eventually.  In the mean time, you can use the archives on Gmane:

  http://news.gmane.org/gmane.comp.linux.ptp.user
  http://news.gmane.org/gmane.comp.linux.ptp.devel
 
> I am having an issue with the ptp4l client and network connectivity. The
> client works just fine and syncs the hardware clock on an Intel e1000
> device.

Which device?

> However, if anything interrupts that connectivity for a couple of
> seconds the clock seems to drop the fact that it is synced to a TAI time
> source with a leap second offset. It will panic that it is behind and jump
> forward 36 seconds (the current leap second offset). Then a few seconds
> later when connectivity is restored and resynced, it realizes it is now 36
> seconds fast and takes 20 minutes or more to work back to the correct time.

IIRC, this problem is due to the fact the e1000 HW and driver requires
a complete reset when the link goes down.  The old time values gets
lost, and the driver simply initializes the clock with the current
system time.
 
> I am able to reproduce this by temporarily blocking access to 1588 udp
> ports 319 and 320 through iptables. Wait a few seconds and the clock will
> jump ahead by the leap second offest. Unblock the udp ports and then the
> clock begins the long process of adjusting back to the actual time.

Hm, I wouldn't expect that behavior, but it does sound like the link
loss symptom.
 
> Is there a setting that I have missed or something I have over looked? The
> ptp4l client does not have many options. I would think that the clock
> should maintain the last known offset during the brief interruption.

I think the source of the jump is not in ptp4l but rather in the
driver or HW.

Thanks,
Richard