Re: [Linuxptp-users] Need help debugging failed clock synchronization

[John H. <jhu...@no...>]

On 03/16/2016 03:50 AM, Richard Cochran wrote:
> On Tue, Mar 15, 2016 at 04:14:32PM -0700, John Hubbard wrote:
>> Apologies if this has already been asked and answered.  I tried to look for
>> solutions to my problem in the mailing list archive, but when I click the
>> list archive link on the mailman page, I get a sourceforge page telling me
>> Error 403 "Read access required".
> Yes, SF is mostly broken.  Please use gmane for the archives.
>
>     http://news.gmane.org/gmane.comp.linux.ptp.user
>
>     http://news.gmane.org/gmane.comp.linux.ptp.devel

Thanks for the hint.  Looking through the archive, it looks like my 
problem might be similar to Daniel Le's January thread "Master offsets 
don't converge".  However it doesn't look like he ever resolved things, 
and it also looks like he was using SW time-stamping where as I believe 
my NIC should be capable of HW time-stamping.

>> I'm trying to configure a machine running CentOS 7 (3.10 kernel) with an
>> Intel 82574L NIC to use PTP as its time source.
> There are two Linux kernel driver workarounds for that unlucky card:
>
> 5e7ff97004  v3.16-rc1  e1000e: 82574/82583 TimeSync errata for SYSTIM read
> 37b12910dd  v4.3-rc1   e1000e: Fix tight loop implementation of systime read algorithm
>
> You should try a newer kernel (4.3+) or use the Intel out of tree
> drivers from SF.

Thanks for the suggestions.  I followed the instructions at [1] and I'm 
now running with a 4.5 kernel.

[jhubbard@statler:~]$ uname -a
Linux statler 4.5.0-1.el7.elrepo.x86_64 #1 SMP Mon Mar 14 10:24:58 EDT 
2016 x86_64 x86_64 x86_64 GNU/Linux

I've disabled phc2sys for now.  I tried restarting ptp4l and the log [2] 
still shows the same clock jumped forward errors.

[2]
[jhubbard@statler:~]$ journalctl -u ptp4l -f
-- Logs begin at Wed 2016-03-16 07:48:05 MST. --
Mar 16 08:15:33 statler ptp4l[12591]: [242.851] port 0: INITIALIZING to 
LISTENING on INITIALIZE
Mar 16 08:15:32 statler systemd[1]: Stopping Precision Time Protocol 
(PTP) service...
Mar 16 08:15:33 statler systemd[1]: Started Precision Time Protocol 
(PTP) service.
Mar 16 08:15:33 statler systemd[1]: Starting Precision Time Protocol 
(PTP) service...
Mar 16 08:15:33 statler ptp4l[12591]: [243.204] port 1: new foreign 
master 000cec.fffe.080c09-1
Mar 16 08:15:37 statler ptp4l[12591]: [247.209] selected best master 
clock 000cec.fffe.080c09
Mar 16 08:15:37 statler ptp4l[12591]: [247.209] port 1: LISTENING to 
UNCALIBRATED on RS_SLAVE
Mar 16 08:15:37 statler ptp4l[12591]: [247.279] port 1: minimum delay 
request interval 2^4
Mar 16 08:15:39 statler ptp4l[12591]: [249.211] master offset 
-16769399087 s0 freq +23999998 path delay -1116866908
Mar 16 08:15:40 statler ptp4l[12591]: [250.213] master offset 
-13924642727 s1 freq +23999999 path delay -1116866908
Mar 16 08:15:41 statler ptp4l[12591]: [251.214] master offset 2750049109 
s2 freq +23999999 path delay -1116866908
Mar 16 08:15:41 statler ptp4l[12591]: [251.214] port 1: UNCALIBRATED to 
SLAVE on MASTER_CLOCK_SELECTED
Mar 16 08:15:42 statler ptp4l[12591]: [252.215] clockcheck: clock jumped 
forward or running faster than expected!
Mar 16 08:15:42 statler ptp4l[12591]: [252.215] master offset 5502378494 
s0 freq +23999999 path delay -1116866908

Messages continue with alternating "clockcheck: clock jumped" and 
"master offset" messages.  The freq is fixed, the master offset counts 
slowly upwards, and the path delay remains negative with the occasional 
small fluctuations.

[1] 
http://linuxg.net/install-kernel-4-x-on-enterprise-linux-7-centos-7-and-rhel-7/


-- 
-john

To be or not to be, that is the question
                 2b || !2b
(0b10)*(0b1100010) || !(0b10)*(0b1100010)
         0b11000100 || !0b11000100
         0b11000100 ||  0b00111011
                0b11111111
255, that is the answer.