linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] phc offset explodes after a while

[Ledda W. E. <Wil...@it...>]

I'm working with i350 and the IGB driver without any problem.

I know "very well" your problem because I was getting the same and I was wander about the possibility of a driver/HW issue. But after many days of continuous tests and a lot of debug information collected (igress and origin timestamp from ptp4l, tcpdump for the network) I haven't seen any error due to inconsistent read of the HW clock or something like that, but I instead discovered a problem in a TC in our facility.

So I feel to say that i350 and the driver are ok.

Regards

William


-----Original Message-----
From: Koehrer Mathias (ETAS/ESW5) [mailto:mat...@et...] 
Sent: 31 January 2014 14:18
To: Vick, Matthew; lin...@li...
Cc: Richard Cochran; Ledda William EXT
Subject: Re: [Linuxptp-users] phc offset explodes after a while

Hi Matthew,

thanks for the information.

> Thanks for your report on this! We've had a few reports of this now 
> and are investigating it internally. We currently believe we may have 
> a hardware bug on 82574L where some reads of the device clock are 
> corrupted.
> We are testing a workaround now and will be submitting the patch 
> upstream once it has passed our internal validation.

Is the Intel IGB (i350 controller) also affected or which Intel adapter to you recommend for PTP?
We are fairly free in choosing a suitable adapter.

Thanks for a short feedback.

Best regards

Mathias

Re: [Linuxptp-users] phc offset explodes after a while

[Koehrer M. (ETAS/ESW5) <mat...@et...>]

Hi Matthew,

thanks for the information.

> Thanks for your report on this! We've had a few reports of this now and
> are investigating it internally. We currently believe we may have a
> hardware bug on 82574L where some reads of the device clock are
> corrupted.
> We are testing a workaround now and will be submitting the patch upstream
> once it has passed our internal validation.

Is the Intel IGB (i350 controller) also affected or which Intel adapter to you recommend for PTP?
We are fairly free in choosing a suitable adapter.

Thanks for a short feedback.

Best regards

Mathias

Re: [Linuxptp-users] phc offset explodes after a while

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

On Fri, Jan 31, 2014 at 09:07:25AM +0000, Koehrer Mathias (ETAS/ESW5) wrote:
> > 2. What happens when you run with the roles reversed?
> >    Use ptp4l -s on host PCB.
> The same behaviour happens - now on the other PC.
> I think this is no wonder as both are using the same type of NIC.

But you said that you are running a different kernel (32/64 bit), and
so this is one variable to check.

> I wonder why the time presented by the testptp program does not fit to  the system time. Here is always a delta of about 35 seconds.

This 35 second difference is the current TAI-UTC offset. You should
make sure that your PTP clock is initialized with the TAI timescale,
if you want to run as a grand master clock.

(But this has nothing to do with the time jump that you are seeing.)
 
> I hope that helps to identify the issue.

>From what Matt Vick said, it sounds like there is a hardware issue
with this card.

Thanks,
Richard

Re: [Linuxptp-users] phc offset explodes after a while

[Koehrer M. (ETAS/ESW5) <mat...@et...>]

Hi all,

thanks for the feedback.
I did some new tests...
> 
> Your PCA (64 bit kernel) is the slave, and your PCB (32 bit kernel) is
> the master. The source of the problem is in the master.
> 
> 1. Maybe there is another program on host PCB that is resetting the
>    time of the PTP clock?
No, I checked already for that.
Without running the ptp tools, there is no time jump at all.

 
> 2. What happens when you run with the roles reversed?
>    Use ptp4l -s on host PCB.
The same behaviour happens - now on the other PC.
I think this is no wonder as both are using the same type of NIC.

> 3. On host PCB, try the following script with nothing else running.
> 
> 	testptp -s
> 	while [ 1 ]; do
> 		date;
> 		testptp -g;
> 		sleep 1;
> 	done
> 
>    Does the sudden jump in time also occur?  The testptp program is
>    under /Documentation/ptp in the Linux kernel sources.
OK, I did this using my original setup. PCB is master, PCA is slave.
On PCB I added your proposed commands and logged the output 
via "logger" to the log file to have all results in a single file per PC.

------- BEGIN PCB (Master) --------
Jan 31 09:55:08 pcb testptp: clock time: 1391158543.964709305 or Fri Jan 31 09:55:43 2014
Jan 31 09:55:09 pcb phc2sys: [5455.412] phc offset     -1124 s2 freq   -2642 delay   4120
Jan 31 09:55:09 pcb date: Fri Jan 31 09:55:09 CET 2014
Jan 31 09:55:09 pcb testptp: clock time: 1391158544.967732260 or Fri Jan 31 09:55:44 2014
Jan 31 09:55:10 pcb phc2sys: [5456.412] phc offset      6967 s2 freq   +5112 delay   4120
Jan 31 09:55:10 pcb date: Fri Jan 31 09:55:10 CET 2014
Jan 31 09:55:10 pcb testptp: clock time: 1391158545.970753621 or Fri Jan 31 09:55:45 2014
Jan 31 09:55:11 pcb phc2sys: [5457.413] phc offset      6980 s2 freq   +7215 delay   4119
Jan 31 09:55:11 pcb date: Fri Jan 31 09:55:11 CET 2014
Jan 31 09:55:11 pcb testptp: clock time: 1391158546.973770115 or Fri Jan 31 09:55:46 2014
Jan 31 09:55:12 pcb phc2sys: [5458.413] phc offset      -620 s2 freq   +1709 delay   4119
Jan 31 09:55:12 pcb date: Fri Jan 31 09:55:12 CET 2014
Jan 31 09:55:12 pcb testptp: clock time: 1391158547.976781979 or Fri Jan 31 09:55:47 2014
Jan 31 09:55:13 pcb phc2sys: [5459.413] phc offset 70368744182224 s2 freq +599999999 delay   4119
Jan 31 09:55:13 pcb date: Fri Jan 31 09:55:13 CET 2014
************ Here is the jump:
Jan 31 09:55:13 pcb testptp: clock time: 1391228917.600794255 or Sat Feb  1 05:28:37 2014
Jan 31 09:55:14 pcb phc2sys: [5460.413] phc offset 70368144122243 s2 freq +599999999 delay   1600
Jan 31 09:55:14 pcb date: Fri Jan 31 09:55:14 CET 2014
Jan 31 09:55:14 pcb testptp: clock time: 1391228918.002014685 or Sat Feb  1 05:28:38 2014
Jan 31 09:55:15 pcb phc2sys: [5461.413] phc offset 70367544038218 s2 freq +599999999 delay   1648
Jan 31 09:55:15 pcb date: Fri Jan 31 09:55:15 CET 2014
Jan 31 09:55:15 pcb testptp: clock time: 1391228918.403224428 or Sat Feb  1 05:28:38 2014
Jan 31 09:55:16 pcb phc2sys: [5462.413] phc offset 70366943954855 s2 freq +599999999 delay   1648
Jan 31 09:55:16 pcb date: Fri Jan 31 09:55:16 CET 2014
Jan 31 09:55:16 pcb testptp: clock time: 1391228918.804436187 or Sat Feb  1 05:28:38 2014
----------- END PCB --------------

------------- BEGIN PCA (Slave) ----------------
Jan 31 09:55:10 pca ptp4l: [5467.031] ingress:1391158545769528578  origin:1391158545769530044 path_delay:733 c1:0 c2:0
Jan 31 09:55:10 pca ptp4l: [5467.031] master offset      -2199 s2 freq  -10448 path delay       733
Jan 31 09:55:11 pca phc2sys: [5467.603] phc offset      4115 s2 freq  +31537 delay   6748
Jan 31 09:55:11 pca ptp4l: [5468.031] ingress:1391158546769555014  origin:1391158546769547343 path_delay:734 c1:0 c2:0
Jan 31 09:55:11 pca ptp4l: [5468.031] master offset       6937 s2 freq   -1972 path delay       734
Jan 31 09:55:12 pca phc2sys: [5468.604] phc offset     -2634 s2 freq  +26022 delay   6810
Jan 31 09:55:12 pca ptp4l: [5469.031] ingress:1391158547769564771  origin:1391158547769554271 path_delay:736 c1:0 c2:0
Jan 31 09:55:12 pca ptp4l: [5469.031] master offset       9764 s2 freq   +2936 path delay       736
Jan 31 09:55:13 pca phc2sys: [5469.604] phc offset      8630 s2 freq  +36496 delay   6763
Jan 31 09:55:13 pca ptp4l: [5470.031] ingress:1391158548769579072  origin:1391158548769576093 path_delay:738 c1:0 c2:0
Jan 31 09:55:13 pca ptp4l: [5470.031] master offset       2241 s2 freq   -1658 path delay       738
Jan 31 09:55:14 pca phc2sys: [5470.604] phc offset     12870 s2 freq  +43325 delay   6555
********** Here is the jump:
Jan 31 09:55:14 pca ptp4l: [5471.031] ingress:1391158549769582167  origin:1391228917916706058 path_delay:3137 c1:0 c2:0
Jan 31 09:55:14 pca ptp4l: [5471.031] master offset -70368147127028 s2 freq -599999999 path delay      3137
Jan 31 09:55:15 pca phc2sys: [5471.604] phc offset -343848810 s2 freq -500000 delay   6105
Jan 31 09:55:15 pca ptp4l: [5472.031] ingress:1391158551368868373  origin:1391228918316714536 path_delay:7912 c1:0 c2:0
Jan 31 09:55:15 pca ptp4l: [5472.031] master offset -70366947854075 s2 freq -599999999 path delay      7912
Jan 31 09:55:16 pca phc2sys: [5472.604] phc offset -943159536 s2 freq -500000 delay   6752
Jan 31 09:55:16 pca ptp4l: [5473.032] ingress:1391158552968869361  origin:1391228918716717414 path_delay:12701 c1:0 c2:0
Jan 31 09:55:16 pca ptp4l: [5473.032] master offset -70365747860754 s2 freq -599999999 path delay     12701
Jan 31 09:55:17 pca phc2sys: [5473.605] phc offset -1542448802 s2 freq -500000 delay   6090
------------ END PCA ---------------

I wonder why the time presented by the testptp program does not fit to  the system time. Here is always a delta of about 35 seconds.

I hope that helps to identify the issue.

Thanks a lot

Mathias

Re: [Linuxptp-users] phc offset explodes after a while

[Vick, M. <mat...@in...>]

On 1/30/14, 12:53 AM, "Koehrer Mathias (ETAS/ESW5)"
<mat...@et...> wrote:

>Hi all,
>
>I am very new in using linuxptp.
>I want to synchronize two PC using a separate point-to-point Ethernet
>connection between both PCs.
>This Ethernet connection is used only for PTP, any other network traffic
>is routed via another NIC.
>
>Kernel 3.2.48-rt69 (RT_PREEMPT patch).
>I use the Intel Gigabit CT Desktop adapter (82574L).
>For this is use the latest e1000e driver (Version 2.5.4) and build it
>outside the kernel to have the PTP support.
>One of the PCs (PCA) runs using 64 bit kernel, the other PC (PCB) runs
>using a 32 bit kernel.
>linux-ptp version 1.3.
>
>On PCA I start the following commands:
># ./ptp4l -i eth1 -p /dev/ptp1 -m -H -P
>and after a couple of seconds:
># ./phc2sys -s /dev/ptp1 -w -m
>
>On PCB I do the very same (unless I have to use /dev/ptp0 here).
>
>This works really fine for a while. However after a while the value of
>phc explodes dramatically.
>The value will be -35192325800 which looks like a kind of value overrun!
>In hex this is 0xFFFFFFF7CE5FB958.
>Please see the logfiles below.
>What could be the issue for that?!?
>
>Thanks for any feedback on this!
>
>Regards
>
>Mathias

Mathias,

Thanks for your report on this! We've had a few reports of this now and
are investigating it internally. We currently believe we may have a
hardware bug on 82574L where some reads of the device clock are corrupted.
We are testing a workaround now and will be submitting the patch upstream
once it has passed our internal validation.

Cheers,
Matthew

Matthew Vick
Linux Development
Networking Division
Intel Corporation

Re: [Linuxptp-users] phc offset explodes after a while

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

On Thu, Jan 30, 2014 at 04:22:22PM +0000, Ledda William EXT wrote:
> Are you able to find the same jump of origin in the tcpdump (look for the Follow_up messages)? 
> 
> If yes the problem is in your master clock device.

Yes, in the PCAP file there is a jump in the follow up messages.

Packet 28 has seconds = 1391093891.
Packet 36 has seconds = 1391164261.

The difference is 70370 seconds. That seems to be consistent with your
other logs.

Your PCA (64 bit kernel) is the slave, and your PCB (32 bit kernel) is
the master. The source of the problem is in the master.

Here are a few questions to answer to get to the bottom of this:

1. Maybe there is another program on host PCB that is resetting the
   time of the PTP clock?

2. What happens when you run with the roles reversed?
   Use ptp4l -s on host PCB.

3. On host PCB, try the following script with nothing else running.

	testptp -s
	while [ 1 ]; do
		date;
		testptp -g;
		sleep 1;
	done

   Does the sudden jump in time also occur?  The testptp program is
   under /Documentation/ptp in the Linux kernel sources.

Thanks,
Richard

Re: [Linuxptp-users] phc offset explodes after a while

[Ledda W. E. <Wil...@it...>]

Are you able to find the same jump of origin in the tcpdump (look for the Follow_up messages)? 

If yes the problem is in your master clock device.

William


-----Original Message-----
From: Koehrer Mathias (ETAS/ESW5) [mailto:mat...@et...] 
Sent: 30 January 2014 16:10
To: Richard Cochran
Cc: lin...@li...
Subject: Re: [Linuxptp-users] phc offset explodes after a while

Hi Richard,

> I have used the very same kernel 3.2.48 without the RT_PREEMPT patch 
> using the same configuration.
> Also here, I got the same issue after a while (it took more than 30 minutes).
> I added some print-outs to the file clock.c in function clock_synchronize().
> Directly after the c->master_offset = tmv_sub(....) call I printed out 
> the values that are used in the computation.
> Below is the related snippet from the logfile.
> There is a jump in the value of "origin" that seems to  cause the issue.
> 
I was able to catch the issue again.
Also I created a tcpdump log in parallel.
Here is the log snippet, the tcpdump file is attached.

Regards

Mathias
---- BEGIN LOG
Jan 30 15:57:34 pca ptp4l: [6636.856] ingress:1391093889615119561  origin:1391093889615118874 path_delay:734 c1:0 c2:0
Jan 30 15:57:34 pca ptp4l: [6636.856] master offset        -47 s2 freq   -6217 path delay       734
Jan 30 15:57:35 pca phc2sys: [6637.403] phc offset       451 s2 freq  +29992 delay   6572
Jan 30 15:57:35 pca ptp4l: [6637.856] ingress:1391093890615137959  origin:1391093890615137194 path_delay:734 c1:0 c2:0
Jan 30 15:57:35 pca ptp4l: [6637.856] master offset         31 s2 freq   -6153 path delay       734
Jan 30 15:57:36 pca phc2sys: [6638.403] phc offset     -2442 s2 freq  +27235 delay   6811
Jan 30 15:57:36 pca ptp4l: [6638.856] ingress:1391093891615150863  origin:1391093891615150154 path_delay:734 c1:0 c2:0
Jan 30 15:57:36 pca ptp4l: [6638.856] master offset        -25 s2 freq   -6200 path delay       734
Jan 30 15:57:37 pca phc2sys: [6639.403] phc offset     10534 s2 freq  +39478 delay   6712
Jan 30 15:57:37 pca ptp4l: [6639.855] Offset is 18446673704965374042 Line 1058 Jan 30 15:57:37 pca ptp4l: [6639.855] ingress:1391093892614699018  origin:1391164261358875858 path_delay:734 c1:0 c2:0
Jan 30 15:57:37 pca ptp4l: [6639.855] master offset -70368744177574 s2 freq -599999999 path delay       734
Jan 30 15:57:38 pca phc2sys: [6640.403] phc offset -329001709 s2 freq -500000 delay   6783
Jan 30 15:57:38 pca ptp4l: [6640.855] Offset is 18446673704965374042 Line 1055 Jan 30 15:57:38 pca ptp4l: [6640.855] Offset is 18446673705563630157 Line 1058 Jan 30 15:57:38 pca ptp4l: [6640.855] ingress:1391093894212433325  origin:1391164262358351738 path_delay:3046 c1:0 c2:0
Jan 30 15:57:38 pca ptp4l: [6640.855] master offset -70368145921459 s2 freq -599999999 path delay      3046
Jan 30 15:57:39 pca phc2sys: [6641.404] phc offset -928285857 s2 freq -500000 delay   6749
Jan 30 15:57:39 pca ptp4l: [6641.854] Offset is 18446673705563630157 Line 1055 Jan 30 15:57:39 pca ptp4l: [6641.854] Offset is 18446673706163311668 Line 1058
---- END LOG

Re: [Linuxptp-users] phc offset explodes after a while

[Koehrer M. (ETAS/ESW5) <mat...@et...>]

Hi Richard,

> I have used the very same kernel 3.2.48 without the RT_PREEMPT patch
> using
> the same configuration.
> Also here, I got the same issue after a while (it took more than 30 minutes).
> I added some print-outs to the file clock.c in function clock_synchronize().
> Directly after the c->master_offset = tmv_sub(....) call I printed out the
> values that are used in the computation.
> Below is the related snippet from the logfile.
> There is a jump in the value of "origin" that seems to  cause the issue.
> 
I was able to catch the issue again.
Also I created a tcpdump log in parallel.
Here is the log snippet, the tcpdump file is attached.

Regards

Mathias
---- BEGIN LOG
Jan 30 15:57:34 pca ptp4l: [6636.856] ingress:1391093889615119561  origin:1391093889615118874 path_delay:734 c1:0 c2:0
Jan 30 15:57:34 pca ptp4l: [6636.856] master offset        -47 s2 freq   -6217 path delay       734
Jan 30 15:57:35 pca phc2sys: [6637.403] phc offset       451 s2 freq  +29992 delay   6572
Jan 30 15:57:35 pca ptp4l: [6637.856] ingress:1391093890615137959  origin:1391093890615137194 path_delay:734 c1:0 c2:0
Jan 30 15:57:35 pca ptp4l: [6637.856] master offset         31 s2 freq   -6153 path delay       734
Jan 30 15:57:36 pca phc2sys: [6638.403] phc offset     -2442 s2 freq  +27235 delay   6811
Jan 30 15:57:36 pca ptp4l: [6638.856] ingress:1391093891615150863  origin:1391093891615150154 path_delay:734 c1:0 c2:0
Jan 30 15:57:36 pca ptp4l: [6638.856] master offset        -25 s2 freq   -6200 path delay       734
Jan 30 15:57:37 pca phc2sys: [6639.403] phc offset     10534 s2 freq  +39478 delay   6712
Jan 30 15:57:37 pca ptp4l: [6639.855] Offset is 18446673704965374042 Line 1058
Jan 30 15:57:37 pca ptp4l: [6639.855] ingress:1391093892614699018  origin:1391164261358875858 path_delay:734 c1:0 c2:0
Jan 30 15:57:37 pca ptp4l: [6639.855] master offset -70368744177574 s2 freq -599999999 path delay       734
Jan 30 15:57:38 pca phc2sys: [6640.403] phc offset -329001709 s2 freq -500000 delay   6783
Jan 30 15:57:38 pca ptp4l: [6640.855] Offset is 18446673704965374042 Line 1055
Jan 30 15:57:38 pca ptp4l: [6640.855] Offset is 18446673705563630157 Line 1058
Jan 30 15:57:38 pca ptp4l: [6640.855] ingress:1391093894212433325  origin:1391164262358351738 path_delay:3046 c1:0 c2:0
Jan 30 15:57:38 pca ptp4l: [6640.855] master offset -70368145921459 s2 freq -599999999 path delay      3046
Jan 30 15:57:39 pca phc2sys: [6641.404] phc offset -928285857 s2 freq -500000 delay   6749
Jan 30 15:57:39 pca ptp4l: [6641.854] Offset is 18446673705563630157 Line 1055
Jan 30 15:57:39 pca ptp4l: [6641.854] Offset is 18446673706163311668 Line 1058
---- END LOG

Re: [Linuxptp-users] phc offset explodes after a while

[Koehrer M. (ETAS/ESW5) <mat...@et...>]

Hi Richard,

thanks for the response and the hint.
> > Kernel 3.2.48-rt69 (RT_PREEMPT patch).
> > I use the Intel Gigabit CT Desktop adapter (82574L).
> > For this is use the latest e1000e driver (Version 2.5.4) and build it outside
> the kernel to have the PTP support.
> 
> ...
> 
> > This works really fine for a while. However after a while the value of phc
> explodes dramatically.
> > The value will be -35192325800 which looks like a kind of value overrun!
> > In hex this is 0xFFFFFFF7CE5FB958.
> 
> This sounds like a RT_PREEMPT issue. That patch makes spinlocks
> preemptable, and the 82574 does need real locking, IIRC.
> 
> Can you reproduce the problem with RT_PREEMPT disabled?
I have used the very same kernel 3.2.48 without the RT_PREEMPT patch using
the same configuration.
Also here, I got the same issue after a while (it took more than 30 minutes).
I added some print-outs to the file clock.c in function clock_synchronize().
Directly after the c->master_offset = tmv_sub(....) call I printed out the values that are used in the computation.
Below is the related snippet from the logfile.
There is a jump in the value of "origin" that seems to  cause the issue.

Any ideas?

Thanks a lot!

Best regards

Mathias

------------ BEGIN SNIPPET ----
Jan 30 14:40:46 pca ptp4l: [2060.928] ingress:1391089281141037037  origin:1391089281141036324 path_delay:738 c1:0 c2:0
Jan 30 14:40:46 pca ptp4l: [2060.928] master offset        -25 s2 freq   -6231 path delay       738
Jan 30 14:40:46 pca phc2sys: [2061.632] phc offset      2066 s2 freq  +32240 delay   6073
Jan 30 14:40:47 pca ptp4l: [2061.928] ingress:1391089282141051035  origin:1391089282141050284 path_delay:734 c1:0 c2:0
Jan 30 14:40:47 pca ptp4l: [2061.928] master offset         17 s2 freq   -6197 path delay       734
Jan 30 14:40:47 pca phc2sys: [2062.632] phc offset      3961 s2 freq  +34755 delay   6393
Jan 30 14:40:48 pca ptp4l: [2062.928] ingress:1391089283141068939  origin:1391089283141068244 path_delay:734 c1:0 c2:0
Jan 30 14:40:48 pca ptp4l: [2062.928] master offset        -39 s2 freq   -6248 path delay       734
Jan 30 14:40:48 pca phc2sys: [2063.632] phc offset     -7230 s2 freq  +24752 delay   6178
Jan 30 14:40:49 pca ptp4l: [2063.927] ingress:1391089284141082537  origin:1391089284141081804 path_delay:732 c1:0 c2:0
Jan 30 14:40:49 pca ptp4l: [2063.927] master offset          1 s2 freq   -6220 path delay       732
Jan 30 14:40:49 pca phc2sys: [2064.632] phc offset      -952 s2 freq  +28861 delay   6655
############# The following line shows the jump in origin which causes the master offset to be really large!
Jan 30 14:40:50 pca ptp4l: [2064.928] ingress:1391089285141017574  origin:1391159653885194468 path_delay:734 c1:0 c2:0
Jan 30 14:40:50 pca ptp4l: [2064.928] master offset -70368744177628 s2 freq -599999999 path delay       734
Jan 30 14:40:50 pca phc2sys: [2065.633] phc offset -422734042 s2 freq -500000 delay   6740
Jan 30 14:40:51 pca ptp4l: [2065.928] ingress:1391089286738705674  origin:1391159654884640068 path_delay:3007 c1:0 c2:0
Jan 30 14:40:51 pca ptp4l: [2065.928] master offset -70368145937401 s2 freq -599999999 path delay      3007
Jan 30 14:40:51 pca phc2sys: [2066.633] phc offset -1021983284 s2 freq -500000 delay   6721
Jan 30 14:40:52 pca ptp4l: [2066.926] ingress:1391089288337875110  origin:1391159655884127148 path_delay:5266 c1:0 c2:0
Jan 30 14:40:52 pca ptp4l: [2066.926] master offset -70367546257304 s2 freq -599999999 path delay      5266
Jan 30 14:40:52 pca phc2sys: [2067.633] phc offset -1621224622 s2 freq -500000 delay   6737
Jan 30 14:40:53 pca ptp4l: [2067.928] ingress:1391089289937036930  origin:1391159656883609508 path_delay:7518 c1:0 c2:0
Jan 30 14:40:53 pca ptp4l: [2067.928] master offset -70366946580096 s2 freq -599999999 path delay      7518
------ END SNIPPET ------

Re: [Linuxptp-users] phc offset explodes after a while

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

On Thu, Jan 30, 2014 at 08:53:17AM +0000, Koehrer Mathias (ETAS/ESW5) wrote:

> Kernel 3.2.48-rt69 (RT_PREEMPT patch).
> I use the Intel Gigabit CT Desktop adapter (82574L).
> For this is use the latest e1000e driver (Version 2.5.4) and build it outside the kernel to have the PTP support.

...

> This works really fine for a while. However after a while the value of phc explodes dramatically.
> The value will be -35192325800 which looks like a kind of value overrun! 
> In hex this is 0xFFFFFFF7CE5FB958.

This sounds like a RT_PREEMPT issue. That patch makes spinlocks
preemptable, and the 82574 does need real locking, IIRC.

Can you reproduce the problem with RT_PREEMPT disabled?

If not, then you will probably have to find the guilty spinlock in the
driver and convert it to a raw spin lock.

Thanks,
Richard

[Linuxptp-users] phc offset explodes after a while

[Koehrer M. (ETAS/ESW5) <mat...@et...>]

Hi all,

I am very new in using linuxptp.
I want to synchronize two PC using a separate point-to-point Ethernet connection between both PCs.
This Ethernet connection is used only for PTP, any other network traffic is routed via another NIC.

Kernel 3.2.48-rt69 (RT_PREEMPT patch).
I use the Intel Gigabit CT Desktop adapter (82574L).
For this is use the latest e1000e driver (Version 2.5.4) and build it outside the kernel to have the PTP support.
One of the PCs (PCA) runs using 64 bit kernel, the other PC (PCB) runs using a 32 bit kernel.
linux-ptp version 1.3.

On PCA I start the following commands:
# ./ptp4l -i eth1 -p /dev/ptp1 -m -H -P
and after a couple of seconds:
# ./phc2sys -s /dev/ptp1 -w -m

On PCB I do the very same (unless I have to use /dev/ptp0 here).

This works really fine for a while. However after a while the value of phc explodes dramatically.
The value will be -35192325800 which looks like a kind of value overrun! 
In hex this is 0xFFFFFFF7CE5FB958.
Please see the logfiles below.
What could be the issue for that?!?

Thanks for any feedback on this!

Regards

Mathias


Here are extracts of the logfiles of the two PCs.
PCA:

Jan 30 08:17:14 pca ptp4l: [1175.684] selected /dev/ptp1 as PTP clock
Jan 30 08:17:14 pca ptp4l: [1175.684] failed to read out the clock frequency adjustment: Operation not supported
Jan 30 08:17:14 pca ptp4l: [1175.684] port 1: get_ts_info not supported
Jan 30 08:17:14 pca ptp4l: [1175.686] port 1: INITIALIZING to LISTENING on INITIALIZE
Jan 30 08:17:14 pca ptp4l: [1175.686] port 0: INITIALIZING to LISTENING on INITIALIZE
Jan 30 08:17:20 pca ptp4l: [1181.686] port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
Jan 30 08:17:20 pca ptp4l: [1181.686] selected best master clock 001b21.fffe.84554a
Jan 30 08:17:20 pca ptp4l: [1181.686] assuming the grand master role
Jan 30 08:17:48 pca ptp4l: [1209.687] port 1: new foreign master 001b21.fffe.525477-1
Jan 30 08:17:52 pca ptp4l: [1213.687] selected best master clock 001b21.fffe.525477
Jan 30 08:17:52 pca ptp4l: [1213.687] port 1: MASTER to UNCALIBRATED on RS_SLAVE
Jan 30 08:17:53 pca ptp4l: [1214.688] master offset -70195994425 s0 freq      +0 path delay       742
Jan 30 08:17:54 pca ptp4l: [1215.688] master offset -70196000905 s1 freq   -6480 path delay       742
Jan 30 08:17:55 pca ptp4l: [1216.688] master offset      -6537 s2 freq  -13017 path delay       740
Jan 30 08:17:55 pca ptp4l: [1216.688] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
Jan 30 08:17:56 pca ptp4l: [1217.688] master offset        -98 s2 freq   -8539 path delay       742
Jan 30 08:17:57 pca ptp4l: [1218.688] master offset       1877 s2 freq   -6594 path delay       740
Jan 30 08:17:58 pca ptp4l: [1219.688] master offset       1984 s2 freq   -5924 path delay       736
Jan 30 08:17:59 pca ptp4l: [1220.688] master offset       1381 s2 freq   -5931 path delay       732
Jan 30 08:18:00 pca ptp4l: [1221.688] master offset        814 s2 freq   -6084 path delay       732
Jan 30 08:18:01 pca ptp4l: [1222.688] master offset        306 s2 freq   -6348 path delay       728
Jan 30 08:18:02 pca ptp4l: [1223.688] master offset         40 s2 freq   -6522 path delay       728
Jan 30 08:18:03 pca ptp4l: [1224.688] master offset         44 s2 freq   -6506 path delay       728
Jan 30 08:18:04 pca ptp4l: [1225.688] master offset          5 s2 freq   -6532 path delay       732
(....)
Jan 30 08:19:11 pca ptp4l: [1292.689] master offset         -6 s2 freq   -6535 path delay       736
Jan 30 08:19:12 pca ptp4l: [1293.689] master offset         -1 s2 freq   -6532 path delay       736
******** Start of phc2sys:
Jan 30 08:19:12 pca phc2sys: [1293.734] phc offset -35192325800 s0 freq      +0 delay   7266
Jan 30 08:19:13 pca ptp4l: [1294.689] master offset         44 s2 freq   -6487 path delay       736
Jan 30 08:19:48 pca phc2sys: [1294.734] phc offset -35192297567 s1 freq  +28228 delay   6665
Jan 30 08:19:49 pca ptp4l: [1295.689] master offset         47 s2 freq   -6471 path delay       736
Jan 30 08:19:49 pca phc2sys: [1295.734] phc offset       706 s2 freq  +28934 delay   6665
Jan 30 08:19:50 pca ptp4l: [1296.689] master offset        -46 s2 freq   -6550 path delay       738
Jan 30 08:19:50 pca phc2sys: [1296.735] phc offset      1343 s2 freq  +29782 delay   6918
Jan 30 08:19:51 pca ptp4l: [1297.689] master offset         40 s2 freq   -6478 path delay       736
Jan 30 08:19:51 pca phc2sys: [1297.735] phc offset        87 s2 freq  +28929 delay   7279
Jan 30 08:19:52 pca ptp4l: [1298.689] master offset        -89 s2 freq   -6595 path delay       734
Jan 30 08:19:52 pca phc2sys: [1298.735] phc offset       102 s2 freq  +28970 delay   7246
Jan 30 08:19:53 pca ptp4l: [1299.689] master offset         49 s2 freq   -6484 path delay       736
Jan 30 08:19:53 pca phc2sys: [1299.735] phc offset      1354 s2 freq  +30253 delay   6624
Jan 30 08:19:54 pca ptp4l: [1300.689] master offset         -4 s2 freq   -6522 path delay       738
Jan 30 08:19:54 pca phc2sys: [1300.735] phc offset     -1532 s2 freq  +27773 delay   7274
Jan 30 08:19:55 pca ptp4l: [1301.689] master offset         40 s2 freq   -6479 path delay       738
Jan 30 08:19:55 pca phc2sys: [1301.735] phc offset       -45 s2 freq  +28801 delay   6823
Jan 30 08:19:56 pca ptp4l: [1302.689] master offset        -51 s2 freq   -6558 path delay       738
(....)
Jan 30 08:26:40 pca phc2sys: [1706.797] phc offset       392 s2 freq  +29395 delay   7273
Jan 30 08:26:41 pca ptp4l: [1707.685] master offset        -18 s2 freq   -6405 path delay       742
Jan 30 08:26:41 pca phc2sys: [1707.798] phc offset      1021 s2 freq  +30142 delay   6896
Jan 30 08:26:42 pca ptp4l: [1708.685] master offset        -25 s2 freq   -6418 path delay       738
Jan 30 08:26:42 pca phc2sys: [1708.798] phc offset      -483 s2 freq  +28944 delay   7244
Jan 30 08:26:43 pca ptp4l: [1709.685] master offset -70368744177618 s2 freq -599999999 path delay       736
Jan 30 08:26:43 pca phc2sys: [1709.798] phc offset -67811266 s2 freq -500000 delay   7278
Jan 30 08:26:44 pca ptp4l: [1710.685] master offset -70368145248865 s2 freq -599999999 path delay      3131
Jan 30 08:26:44 pca phc2sys: [1710.798] phc offset -667045232 s2 freq -500000 delay   6418
Jan 30 08:26:45 pca ptp4l: [1711.685] master offset -70367545570068 s2 freq -599999999 path delay      5610
Jan 30 08:26:45 pca phc2sys: [1711.798] phc offset -1266289231 s2 freq -500000 delay   6651
Jan 30 08:26:46 pca ptp4l: [1712.685] master offset -70366945886718 s2 freq -599999999 path delay      8048


And PCB:

Jan 30 08:18:51 pcb ptp4l: [1167.142] selected /dev/ptp0 as PTP clock
Jan 30 08:18:51 pcb ptp4l: [1167.142] failed to read out the clock frequency adjustment: Operation not supported
Jan 30 08:18:51 pcb ptp4l: [1167.142] port 1: get_ts_info not supported
Jan 30 08:18:51 pcb ptp4l: [1167.143] port 1: INITIALIZING to LISTENING on INITIALIZE
Jan 30 08:18:51 pcb ptp4l: [1167.143] port 0: INITIALIZING to LISTENING on INITIALIZE
Jan 30 08:18:52 pcb ptp4l: [1168.287] port 1: new foreign master 001b21.fffe.84554a-1
Jan 30 08:18:56 pcb ptp4l: [1172.287] selected best master clock 001b21.fffe.84554a
Jan 30 08:18:56 pcb ptp4l: [1172.287] assuming the grand master role
Jan 30 08:18:56 pcb ptp4l: [1172.287] port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER
******** Start of phc2sys:
Jan 30 08:26:41 pcb phc2sys: [1637.218] phc offset 35017079063 s0 freq      +0 delay   4679
Jan 30 08:26:07 pcb phc2sys: [1638.218] phc offset 35017116539 s1 freq  +37466 delay   4679
Jan 30 08:26:08 pcb phc2sys: [1639.219] phc offset       264 s2 freq  +37730 delay   4749
Jan 30 08:26:09 pcb phc2sys: [1640.219] phc offset     -2373 s2 freq  +35173 delay   4749
Jan 30 08:26:10 pcb phc2sys: [1641.219] phc offset     -1372 s2 freq  +35462 delay   4679
Jan 30 08:26:11 pcb phc2sys: [1642.219] phc offset      -803 s2 freq  +35619 delay   4749
Jan 30 08:26:12 pcb phc2sys: [1643.219] phc offset     -1386 s2 freq  +34795 delay   4680
Jan 30 08:26:13 pcb phc2sys: [1644.219] phc offset      1419 s2 freq  +37184 delay   4749
Jan 30 08:26:14 pcb phc2sys: [1645.219] phc offset      1560 s2 freq  +37751 delay   4749
Jan 30 08:26:15 pcb phc2sys: [1646.220] phc offset     -1381 s2 freq  +35278 delay   4749
Jan 30 08:26:16 pcb phc2sys: [1647.220] phc offset      1027 s2 freq  +37272 delay   4749
Jan 30 08:26:17 pcb phc2sys: [1648.220] phc offset      -742 s2 freq  +35811 delay   4749
(...)
Jan 30 08:26:39 pcb phc2sys: [1670.223] phc offset      -432 s2 freq  +35828 delay   4679
Jan 30 08:26:40 pcb phc2sys: [1671.223] phc offset       611 s2 freq  +36741 delay   4749
Jan 30 08:26:41 pcb phc2sys: [1672.223] phc offset       -30 s2 freq  +36284 delay   4749
Jan 30 08:26:42 pcb phc2sys: [1673.223] phc offset       -55 s2 freq  +36250 delay   4679
Jan 30 08:26:43 pcb phc2sys: [1674.223] phc offset -70368743932001 s2 freq -499999 delay   4749
Jan 30 08:26:44 pcb phc2sys: [1675.223] phc offset -70368743642083 s2 freq -499999 delay   4752
Jan 30 08:26:45 pcb phc2sys: [1676.223] phc offset -70368743106050 s2 freq -499999 delay   4682
Jan 30 08:26:46 pcb phc2sys: [1677.223] phc offset -70368742570005 s2 freq -499999 delay   4682
Jan 30 08:26:47 pcb phc2sys: [1678.224] phc offset -70368742033964 s2 freq -499999 delay   4751
Jan 30 08:26:48 pcb phc2sys: [1679.224] phc offset -70368741497965 s2 freq -499999 delay   4681
Jan 30 08:26:49 pcb phc2sys: [1680.224] phc offset -70368740961901 s2 freq -499999 delay   4751
Jan 30 08:26:50 pcb phc2sys: [1681.224] phc offset -70368740425857 s2 freq -499999 delay   4751
Jan 30 08:26:51 pcb phc2sys: [1682.224] phc offset -70368739889757 s2 freq -499999 delay   4682
Jan 30 08:26:52 pcb phc2sys: [1683.224] phc offset -70368739353913 s2 freq -499999 delay   4751

Re: [Linuxptp-users] LOCAL MAP OPTIMIZATION FOR : mail-archive.com (Less Than $99/Month)

[<aur...@go...>]

Good Morning Sir / Mam

Is your business ranking in local maps shown on PAGE 1 of google ? With new
google policies they have specifically asked local business owners to
optimize their website for local maps rather than JUST organics. Do you know
the reason why you are not ranked well on google MAPs or why there is drop
in your website rankings? Prime reason for bad rankings for a busniess is
lack of local presence and local citations ie getting your business listed
on directories like YELP, MANTA & Many more. These websites not just give
your business a push but also help you Maintain a good Online Reputation.

Why you need to optimize your website for local MAP Listings ?

- MAP listings get 10 times more clicks than organic listings
- Increased conversions because of real reviews posted on your Google Plus
Page
- Every year there is 30% increase in searches for local keywords
- Increases legitimacy of a Business

We will help you get your website ranked well on google for the related
keywords in your niche. We specialize in LOCAL SEARCH ENGINE OPTIMIZATION
increasing visibility for small businesses by ranking them for
geographically-related keywords. Say for eg-: you want to search a plumber
in your city, You will be typing in keywords like Plumbers + City Or
Plumbers + IN + City. We make sure your website comes in google MAP listings
shown on page 1 for each such keyword.

Now Google believes in - BE ORIGINAL, HAVE ORIGINAL AND GIVE ORIGINAL which
means that google wants to end up that frustrating experience of users who
are searching for Service Or Product and seeing the results that are not
even close to what they are looking for. Google only wants to give their
user original and relevant results. This makes it even more important that
we showcase our business in the best possible way and make sure our website
in valued high by google.

We at TheLOCALIST will make google feel the importance of your business by
following their guidelines thus ranking your website higher in serach
results. We are presently offering LOCAL OPTIMIZATION to more than 400
websites and they all rank page 1 for all possible keywords !!! Each month
your website is submitted to more than 50 citations and social presence is
controlled by posting videos and blogs all over the web.

Email us back with your website & phone number so we can discuss this
further with you. Our Packages start from as low as 99$/month.


Thanks For Taking Time To Read Our Email

Polly Martin
Local SEO Manager ( THE Localist )
Address : 24 ST Suite 32 Downtown Provo Utah

-------------------
NOT INTERESTED ? REPLY WITH NOT INTERESTED IN THE SUBJECT LINE 

Re: [Linuxptp-users] Red Hat's Users Guide for linuxptp

[Keller, J. E <jac...@in...>]

On Thu, 2014-01-09 at 18:38 +0100, Richard Cochran wrote:
> Dear linuxptp users,
> 
> I just stumbled across this nice documentation from RedHat.
> 
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Configuring_PTP_Using_ptp4l.html
> 
> A little of this is specific to RedHat, but most of it is applicable
> to anyone using linuxptp. It is pretty well written, I think. (Maybe
> we won't have to write a users manual after all ;)
> 
> Thanks,
> Richard
> 
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Neat! :) Is this something we could link from the linuxptp website?

Regards,
Jake

Re: [Linuxptp-users] Red Hat's Users Guide for linuxptp

[Flavio L. <fb...@re...>]

On Thu, Jan 09, 2014 at 06:38:53PM +0100, Richard Cochran wrote:
> Dear linuxptp users,
> 
> I just stumbled across this nice documentation from RedHat.
> 
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Configuring_PTP_Using_ptp4l.html
> 
> A little of this is specific to RedHat, but most of it is applicable
> to anyone using linuxptp. It is pretty well written, I think. (Maybe
> we won't have to write a users manual after all ;)

And if you find any errors or have suggestions, feel free to speak up.
I can forward it to the people responsible for the docs.

fbl

[Linuxptp-users] Red Hat's Users Guide for linuxptp

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

Dear linuxptp users,

I just stumbled across this nice documentation from RedHat.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Configuring_PTP_Using_ptp4l.html

A little of this is specific to RedHat, but most of it is applicable
to anyone using linuxptp. It is pretty well written, I think. (Maybe
we won't have to write a users manual after all ;)

Thanks,
Richard

Re: [Linuxptp-users] Question about hardware receive filter mode

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

On Thu, Dec 19, 2013 at 09:43:47PM +0000, Keller, Jacob E wrote:
 
> The other filters are available as historically the interface supported
> them, even if it wasn't really useful.

The various filters correspond to the available modes in early time
stamping hardware implementations.

As Jake said, only the "all event" filter is interesting. In ptp4l, we
try to use

    HWTSTAMP_FILTER_PTP_V2_EVENT,

but we fall back to

   HWTSTAMP_FILTER_PTP_V2_L4_EVENT, or
   HWTSTAMP_FILTER_PTP_V2_L2_EVENT

depending on the transport. We never use any other filter.

HTH,
Richard

Re: [Linuxptp-users] Question about hardware receive filter mode

[Keller, J. E <jac...@in...>]

On Thu, 2013-12-19 at 09:16 +0000, Ledda William EXT wrote:
> Hi all, 
> 
> I was querying timestamp capabilities of an interface with ethtool -T
> and I found the following
> 
>  
> 
> Hardware Receive Filter Modes:
> 
>                 none                  (HWTSTAMP_FILTER_NONE)
> 
>                 all                   (HWTSTAMP_FILTER_ALL)
> 
>                 ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
> 
>                 ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
> 
>                 ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
> 
>                 ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
> 
>                 ptpv2-l2-sync         (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
> 
>                 ptpv2-l2-delay-req    (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
> 
>                 ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
> 
>                 ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
> 
>                 ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
> 
>  
> 

The above filters are just all the available ones. The 'good' filter is
ptpv2-event and all. The peer delay and request filters aren't even
listed here! (You can see how old and crummy the hwtstamp_ioctl
interface is....)

Essentially you only need ptpv2-event to support timestamping the
correct list. If you're in slave only mode you need to be able to
timestamp only sync (and peer messages in P2P mode). But having extra
filters doesn't really buy anything as if you can timestamp ptpv2-event
packets you can timestamp any packet needed by ptp4l.

The other filters are available as historically the interface supported
them, even if it wasn't really useful.

Regards,
Jake

> 
>  
> 
> I’m curios to understand the meaning of the different filters in
> particular those related to PTP. Can I found some benefit from  them?
> I mean… if an interface with those filter is “better” than one that
> doesn’t has them?
> 
>  

As long as the interface has ptpv2-event it is consistently more useful
than an interface which does not. However the other filters are not
useful (IMHO).

Ofcourse timestamp all packets is the most useful.

> 
> Thank you 
> 
>  
> 
> William
> 
>  
> 
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

[Linuxptp-users] Question about hardware receive filter mode

[Ledda W. E. <Wil...@it...>]

Hi all,
I was querying timestamp capabilities of an interface with ethtool -T and I found the following

Hardware Receive Filter Modes:
                none                  (HWTSTAMP_FILTER_NONE)
                all                   (HWTSTAMP_FILTER_ALL)
                ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
                ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
                ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
                ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
                ptpv2-l2-sync         (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
                ptpv2-l2-delay-req    (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
                ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
                ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
                ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)


I'm curios to understand the meaning of the different filters in particular those related to PTP. Can I found some benefit from  them? I mean... if an interface with those filter is "better" than one that doesn't has them?

Thank you

William

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Keller, J. E <jac...@in...>]

On Tue, 2013-12-17 at 13:44 -0600, Shawn Bohrer wrote:
> > >  I'm not sure how it is done, but should ptp4l recognize
> > > that it is a vlan interface and perform ioctl and ethtool queries
> > > against the actual device interface?  I know the 'ip' tool associates
> > > vlan807 with eth4 so that mapping can be detected somehow:
> > 
> > I think it would be nicer if the kernel did this for us automatically,
> > but I'll have to take this up on the netdev list.
> 
> Cool, I agree that it seems like the kernel should at least pass only
> the ethtool information from the actual device for a vlan interface.
> What is your suggestion for the ioctl?  Should the kernel
> automatically perform that on the correct driver as well?  Are you
> going to raise this on netdev or should I?
> 
> Thanks,
> Shawn

I agree that the kernel could be extended to enable vlans. The trick
being what should be done if the vlan requests it, and the base driver
gets a direct request, which one should be honored? This could get a
little complicated...

When this goes to netdev, I would ilke to be Cc'ed on the discussion.

Regards,
Jake

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Shawn B. <sha...@gm...>]

On Fri, Dec 13, 2013 at 04:54:22PM +0100, Richard Cochran wrote:
> On Wed, Dec 11, 2013 at 03:42:09PM -0600, Shawn Bohrer wrote:
>  
> > I left the message in but let it continue.  It appears to work fine
> > with software timestamps, or at least I don't see any relevant errors
> > and it is adjusting the clock.  I haven't looked into the "port 1:
> > delay timeout" messages yet.
> 
> Those are harmless debug messages that say, "it is time to transmit
> another delay request."

Excellent ptp4l with software timestamps works just fine on the vlan
interface as long as you omit the ethtool check.

> > My end goal though is to use hardware timestamps and that currently
> > does not work on the vlan interface simply because the SIOCSHWTSTAMP
> > ioctl fails.
> 
> For now, if you know the real inteface, you can set the ioctl by hand
> using the hwstamp_ctl program. Then, just hack ptp4l to skip over the
> ioctl, and it might work for you.

I just finished testing ptp4l with hardware timestamps on the vlan as
well and that works as long as you both omit the ethtool check, and
omit the ioctl.  You but then first use the hwstamp_ctl program to
setup the timestamps before you start ptp4l.
 
> >  I'm not sure how it is done, but should ptp4l recognize
> > that it is a vlan interface and perform ioctl and ethtool queries
> > against the actual device interface?  I know the 'ip' tool associates
> > vlan807 with eth4 so that mapping can be detected somehow:
> 
> I think it would be nicer if the kernel did this for us automatically,
> but I'll have to take this up on the netdev list.

Cool, I agree that it seems like the kernel should at least pass only
the ethtool information from the actual device for a vlan interface.
What is your suggestion for the ioctl?  Should the kernel
automatically perform that on the correct driver as well?  Are you
going to raise this on netdev or should I?

Thanks,
Shawn

Re: [Linuxptp-users] using ptp4l on vlan interfaces

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

On Wed, Dec 11, 2013 at 03:42:09PM -0600, Shawn Bohrer wrote:
 
> I left the message in but let it continue.  It appears to work fine
> with software timestamps, or at least I don't see any relevant errors
> and it is adjusting the clock.  I haven't looked into the "port 1:
> delay timeout" messages yet.

Those are harmless debug messages that say, "it is time to transmit
another delay request."

> My end goal though is to use hardware timestamps and that currently
> does not work on the vlan interface simply because the SIOCSHWTSTAMP
> ioctl fails.

For now, if you know the real inteface, you can set the ioctl by hand
using the hwstamp_ctl program. Then, just hack ptp4l to skip over the
ioctl, and it might work for you.

>  I'm not sure how it is done, but should ptp4l recognize
> that it is a vlan interface and perform ioctl and ethtool queries
> against the actual device interface?  I know the 'ip' tool associates
> vlan807 with eth4 so that mapping can be detected somehow:

I think it would be nicer if the kernel did this for us automatically,
but I'll have to take this up on the netdev list.

Thanks,
Richard

Re: [Linuxptp-users] [Linuxptp-devel] [PATCH] sk: update error message for Tx timestamp polling

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

On Thu, Dec 12, 2013 at 06:55:55PM +0000, Keller, Jacob E wrote:
> 
> However, timestamping.c uses ptp v1 packets, which are not used by
> ptp4l. However software timestamping shouldn't care about this.

And it only uses Sync messages.

And it can use three different kind of time stamping.

And so, saying "it works" is not really saying much.

Thanks,
Richard

Re: [Linuxptp-users] [Linuxptp-devel] [PATCH] sk: update error message for Tx timestamp polling

[Keller, J. E <jac...@in...>]

We are still trying to help...

I can't help much without seeing what the failure is. If timestamping.c
is working that's possibly a good indication.

However, timestamping.c uses ptp v1 packets, which are not used by
ptp4l. However software timestamping shouldn't care about this.

You are incorrect regarding software timestamps, as you actually need a
one line change to the MAC driver to support software timestamps.
Receive timestamps don't require a driver change.

One thing you could do is attach a copy of the output from a failed run
of ptp4l.

Regards,
Jake

On Thu, 2013-12-12 at 14:08 +0800, Arnold kang wrote:
> i'm sorry that i asked so much from you guys...... i'll try to solve
> it
> 
> 
> 
> 
> 2013/12/12 Keller, Jacob E <jac...@in...>
>         Can you show us the output of ptp4l?
>         
>         Regards,
>         Jake
>         
>         On Wed, 2013-12-11 at 18:49 +0800, Arnold kang wrote:
>         > hi Richard,
>         >
>         >    i just use a test code  from kernel
>         >
>         https://www.kernel.org/doc/Documentation/networking/timestamping/timestamping.c . and i can receive the send package timestamp back. i i guess this is a bug in linux ptp. can you tell me how to resolve it?
>         >
>         >
>         >
>         > thanks.
>         >
>         >
>         >
>         > 2013/12/11 Arnold kang <arn...@gm...>
>         >         i get the trouble that ptp send  delay  request
>         package, and
>         >         can't get back the send  timestamp back. but when
>         receive
>         >         message for master,  i can get the receive
>         timestamp.  so, i
>         >         think the problem is not in driver. and i don't know
>         why
>         >         cann't  get the send timestamp
>         >
>         >
>         >
>         >         2013/12/11 Arnold kang <arn...@gm...>
>         >                 hi Richard,
>         >
>         >                   my  PTP ts type is software, so there no
>         need MAC
>         >                 driver support, is this right?
>         >
>         >
>         >
>         >                 2013/12/7 Keller, Jacob E
>         <jac...@in...>
>         >
>         >                         FYI, you need kernel 3.5 or later
>         for the
>         >                         ethtool -T to work :)
>         >
>         >                         Regards,
>         >                         Jake
>         >
>         >                         On Fri, 2013-12-06 at 16:50 +0800,
>         Arnold kang
>         >                         wrote:
>         >                         > hi,
>         >                         >
>         >                         >   i find that the mac driver is
>         >                         STMicroelectronics 10/100/1000
>         >                         > Synopsys Ethernet driver which in
>          "
>         >                         linux-3.0.8/drivers/net/stmmac
>         >                         >
>         >                         > " .  and sorry that i can run the
>         'ethtool
>         >                         -T' on my arm linux, and
>         >                         > I'm trying...
>         >                         >
>         >                         >
>         >                         >
>         >                         > Thanks,
>         >                         >
>         >                         > Arnold
>         >                         >
>         >                         >
>         >                         >
>         >                         > 2013/12/5 Richard Cochran
>         >                         <ric...@gm...>
>         >                         >         On Thu, Dec 05, 2013 at
>         09:46:13AM
>         >                         +0800, Arnold kang wrote:
>         >                         >         > hi all,
>         >                         >         >    i just noticed that
>         the
>         >                         previous  can not send
>         >                         >          correctly, so i past it
>         >                         >         > again.
>         >                         >         >
>         >                         >         > Dear Richard:
>         >                         >         >     thanks for your
>         response.
>         >                          here is the detail
>         >                         >         information:
>         >                         >         >    ARCH  : ARM Cortex A9
>         >                         >         >   kernel version : 3.0.8
>         >                         >         >   ethernet card :
>          RTL8211EG
>         >                         >
>         >                         >
>         >                         >         This is a PHY, not a MAC.
>         We need to
>         >                         know what MAC you are
>         >                         >         using.
>         >                         >
>         >                         >         Can you also send the
>         output of
>         >                         'ethtool -T'?
>         >                         >
>         >                         >         Thanks,
>         >                         >         Richard
>         >                         >
>         >                         >
>         >
>         >                         >
>         >
>         ------------------------------------------------------------------------------
>         >                         > Sponsored by Intel(R) XDK
>         >                         > Develop, test and display web and
>         hybrid
>         >                         apps with a single code base.
>         >                         > Download it for free now!
>         >                         >
>         >
>         http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>         >                         >
>         >
>         _______________________________________________
>         >                         > Linuxptp-users mailing list
>         >                         >
>         Lin...@li...
>         >                         >
>         >
>         https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>         >
>         >
>         >
>         >
>         >
>         >
>         >
>         >
>         
>         
>         
> 
> 

Re: [Linuxptp-users] [Linuxptp-devel] [PATCH] sk: update error message for Tx timestamp polling

[Arnold k. <arn...@gm...>]

i'm sorry that i asked so much from you guys...... i'll try to solve it



2013/12/12 Keller, Jacob E <jac...@in...>

> Can you show us the output of ptp4l?
>
> Regards,
> Jake
>
> On Wed, 2013-12-11 at 18:49 +0800, Arnold kang wrote:
> > hi Richard,
> >
> >    i just use a test code  from kernel
> >
> https://www.kernel.org/doc/Documentation/networking/timestamping/timestamping.c. and i can receive the send package timestamp back. i i guess this is a
> bug in linux ptp. can you tell me how to resolve it?
> >
> >
> >
> > thanks.
> >
> >
> >
> > 2013/12/11 Arnold kang <arn...@gm...>
> >         i get the trouble that ptp send  delay  request package, and
> >         can't get back the send  timestamp back. but when receive
> >         message for master,  i can get the receive timestamp.  so, i
> >         think the problem is not in driver. and i don't know why
> >         cann't  get the send timestamp
> >
> >
> >
> >         2013/12/11 Arnold kang <arn...@gm...>
> >                 hi Richard,
> >
> >                   my  PTP ts type is software, so there no need MAC
> >                 driver support, is this right?
> >
> >
> >
> >                 2013/12/7 Keller, Jacob E <jac...@in...>
> >
> >                         FYI, you need kernel 3.5 or later for the
> >                         ethtool -T to work :)
> >
> >                         Regards,
> >                         Jake
> >
> >                         On Fri, 2013-12-06 at 16:50 +0800, Arnold kang
> >                         wrote:
> >                         > hi,
> >                         >
> >                         >   i find that the mac driver is
> >                         STMicroelectronics 10/100/1000
> >                         > Synopsys Ethernet driver which in  "
> >                         linux-3.0.8/drivers/net/stmmac
> >                         >
> >                         > " .  and sorry that i can run the 'ethtool
> >                         -T' on my arm linux, and
> >                         > I'm trying...
> >                         >
> >                         >
> >                         >
> >                         > Thanks,
> >                         >
> >                         > Arnold
> >                         >
> >                         >
> >                         >
> >                         > 2013/12/5 Richard Cochran
> >                         <ric...@gm...>
> >                         >         On Thu, Dec 05, 2013 at 09:46:13AM
> >                         +0800, Arnold kang wrote:
> >                         >         > hi all,
> >                         >         >    i just noticed that the
> >                         previous  can not send
> >                         >          correctly, so i past it
> >                         >         > again.
> >                         >         >
> >                         >         > Dear Richard:
> >                         >         >     thanks for your response.
> >                          here is the detail
> >                         >         information:
> >                         >         >    ARCH  : ARM Cortex A9
> >                         >         >   kernel version : 3.0.8
> >                         >         >   ethernet card :  RTL8211EG
> >                         >
> >                         >
> >                         >         This is a PHY, not a MAC. We need to
> >                         know what MAC you are
> >                         >         using.
> >                         >
> >                         >         Can you also send the output of
> >                         'ethtool -T'?
> >                         >
> >                         >         Thanks,
> >                         >         Richard
> >                         >
> >                         >
> >
> >                         >
> >
> ------------------------------------------------------------------------------
> >                         > Sponsored by Intel(R) XDK
> >                         > Develop, test and display web and hybrid
> >                         apps with a single code base.
> >                         > Download it for free now!
> >                         >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> >                         >
> >                         _______________________________________________
> >                         > Linuxptp-users mailing list
> >                         > Lin...@li...
> >                         >
> >
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Shawn B. <sha...@gm...>]

On Wed, Dec 11, 2013 at 08:29:43AM +0100, Richard Cochran wrote:
> On Tue, Dec 10, 2013 at 12:47:32PM -0600, Shawn Bohrer wrote:
> > 
> > I took a look at the code and can see this is because vlan interfaces
> > do not report that they support SOF_TIMESTAMPING_TX_SOFTWARE.  The
> > underlying device interface eth4 however does claim to support
> > SOF_TIMESTAMPING_TX_SOFTWARE.
> 
> Can you try hacking the code to omit the ethtool check?
> 
> If the time stamping actually works, and the only problem is the
> ethtool reporting, then that would probably be an easy kernel fix.

I left the message in but let it continue.  It appears to work fine
with software timestamps, or at least I don't see any relevant errors
and it is adjusting the clock.  I haven't looked into the "port 1:
delay timeout" messages yet.

root@berbox40:~/linuxptp# ./ptp4l -S -i vlan807 -s -l7 -m -f default.cfg 
interface 'vlan807' does not support requested timestamping mode.
ptp4l[245.983]: PI servo: sync interval 1.000 kp 0.100 ki 0.001000
ptp4l[245.983]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[245.983]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[246.042]: port 1: setting asCapable
ptp4l[247.042]: port 1: new foreign master 0050c2.fffe.de95be-1
ptp4l[251.040]: selected best master clock 0050c2.fffe.de95be
ptp4l[251.040]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[252.174]: port 1: delay timeout
ptp4l[252.174]: path delay         55915      55915
ptp4l[252.174]: port 1: minimum delay request interval 2^3
ptp4l[252.308]: port 1: delay timeout
ptp4l[252.310]: path delay         74143      92372
ptp4l[253.038]: master offset  104525904 s0 freq      +0 path delay     74143
ptp4l[254.038]: master offset  103983280 s0 freq      +0 path delay     74143
ptp4l[255.038]: master offset  103440336 s0 freq      +0 path delay     74143
ptp4l[256.037]: master offset  102900750 s0 freq      +0 path delay     74143
ptp4l[257.037]: master offset  102356489 s0 freq      +0 path delay     74143
ptp4l[258.036]: master offset  101812007 s0 freq      +0 path delay     74143
ptp4l[259.036]: master offset  101270800 s0 freq      +0 path delay     74143
ptp4l[260.035]: master offset  100726417 s0 freq      +0 path delay     74143
ptp4l[261.035]: master offset  100183093 s0 freq      +0 path delay     74143
ptp4l[262.034]: master offset   99642376 s0 freq      +0 path delay     74143
ptp4l[263.034]: master offset   99097737 s0 freq      +0 path delay     74143
ptp4l[264.033]: master offset   98554559 s0 freq      +0 path delay     74143
ptp4l[265.033]: master offset   98013725 s0 freq      +0 path delay     74143
ptp4l[266.032]: master offset   97468859 s0 freq      +0 path delay     74143
ptp4l[267.032]: master offset   96928505 s0 freq      +0 path delay     74143
ptp4l[267.886]: port 1: delay timeout
ptp4l[267.887]: path delay         92372     252146
ptp4l[268.031]: master offset   96367211 s0 freq      +0 path delay     92372
ptp4l[269.031]: master offset   95822598 s1 freq  -44222 path delay     92372
ptp4l[270.031]: master offset        440 s2 freq  -44177 path delay     92372
ptp4l[270.031]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[270.688]: port 1: delay timeout
ptp4l[270.689]: path delay         74143      18259
ptp4l[271.031]: master offset      20279 s2 freq  -42173 path delay     74143
ptp4l[272.031]: master offset      20349 s2 freq  -42146 path delay     74143
ptp4l[273.031]: master offset      20117 s2 freq  -42149 path delay     74143
ptp4l[273.675]: port 1: delay timeout
ptp4l[273.676]: path delay         55915      19779
ptp4l[274.031]: master offset      37265 s2 freq  -40397 path delay     55915
ptp4l[275.031]: master offset      43916 s2 freq  -39688 path delay     55915
ptp4l[276.031]: master offset      32209 s2 freq  -40826 path delay     55915
ptp4l[276.428]: port 1: delay timeout
ptp4l[276.429]: path delay         37856      19798
ptp4l[277.031]: master offset      49835 s2 freq  -39014 path delay     37856
ptp4l[278.032]: master offset      43080 s2 freq  -39646 path delay     37856
ptp4l[279.031]: master offset      40082 s2 freq  -39906 path delay     37856
ptp4l[280.031]: master offset      37553 s2 freq  -40121 path delay     37856
ptp4l[281.031]: master offset      40731 s2 freq  -39763 path delay     37856
ptp4l[282.031]: master offset      31761 s2 freq  -40628 path delay     37856
ptp4l[283.031]: master offset      29417 s2 freq  -40833 path delay     37856

My end goal though is to use hardware timestamps and that currently
does not work on the vlan interface simply because the SIOCSHWTSTAMP
ioctl fails.  I'm not sure how it is done, but should ptp4l recognize
that it is a vlan interface and perform ioctl and ethtool queries
against the actual device interface?  I know the 'ip' tool associates
vlan807 with eth4 so that mapping can be detected somehow:

$ ip addr show vlan807
10: vlan807@eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:02:c9:31:8b:21 brd ff:ff:ff:ff:ff:ff
    inet 10.8.7.20/24 brd 10.8.7.255 scope global vlan807
       valid_lft forever preferred_lft forever
    inet6 fe80::2:c900:131:8b21/64 scope link 
       valid_lft forever preferred_lft forever

--
Shawn