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

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

On 03/16/2016 12:54 PM, Richard Cochran wrote:
> On Wed, Mar 16, 2016 at 10:20:35AM -0700, John Hubbard wrote:
>> After changing the 'time_stamping' option in /etc/ptp4l.conf from
>> hardware to software and restarting ptp4l I now see much better
>> behavior.
> Yes, but probably you are disappointed having to forego the HW
> synchronization performance.  At least this test shows that your card
> most likely has a HW bug.

If possible it would be really nice to get the HW time-stamping working 
on this system.  I can move to another system if needed but getting this 
working would help me in the short term.  (No expansion ports or I'd 
just pick up another NIC.  On a related note do you or anyone else on 
the list know how well the Intel X540 (10Gb NIC using the ixgbe driver) 
is supported WRT ptp4l?

>> I believe that I did try the Intel driver but didn't see any success.  I
>> found version 3.3.3 of the driver at [3], followed the instructions in
>> the readme.  At the time I was running the 3.10.0-327.10.1 kernel.  The
>> timestamp (see below) on e1000e.ko matches up with when I performed the
>> build, and the file size is way bigger (6M as compared to ~780K) for the
>> ko on the older 3.10 and the newer 4.5 kernels.  I did an rmmod (which
>> hung my SSH session) I then rebooted the machine (which I assume loaded
>> the new driver).
> I wouldn't assume that.  Either do rmmod/insmod by hand (on the
> console!) or simply rename or move the original driver before
> rebooting.

OK the machine has got three kernels installed.  Here's the e1000e 
driver version (as reported by modinfo) for each:

Kernel 3.10.0-327 e1000e version 3.2.5-k
Kernel 3.10.0-327.10.1 e1000e version 3.3.3-NAPI
Kernel 4.5.0-1 e1000e version 3.2.6-k

Under all three kernels with software time stamping things 'work' but 
with more jitter than I'd like to see.  With hardware time stamping 
things don't work.  Specifically I see clock jumped forward messages and 
an ever increasing master offset.


-- 
-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.