linuxptp-users Mailing List for linuxptp (Page 155)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: <Tim...@de...> - 2013-04-09 07:09:50
|
The output of ptp4l is: ptp4l[1286.117]: master offset -32 s2 freq +31447 path delay 718 ptp4l[1287.117]: master offset -13 s2 freq +31456 path delay 718 ptp4l[1288.118]: master offset 47 s2 freq +31512 path delay 716 ptp4l[1289.118]: master offset -31 s2 freq +31449 path delay 718 ptp4l[1290.118]: master offset -12 s2 freq +31458 path delay 717 ptp4l[1291.118]: master offset 8 s2 freq +31475 path delay 717 ptp4l[1292.118]: master offset -29 s2 freq +31440 path delay 717 ptp4l[1293.118]: master offset 28 s2 freq +31488 path delay 720 ptp4l[1294.118]: master offset -57 s2 freq +31412 path delay 726 ptp4l[1295.118]: master offset 43 s2 freq +31495 path delay 726 ptp4l[1296.118]: master offset -35 s2 freq +31430 path delay 726 ptp4l[1297.118]: master offset 25 s2 freq +31479 path delay 726 ptp4l[1298.118]: master offset -14 s2 freq +31448 path delay 727 ptp4l[1299.118]: master offset 45 s2 freq +31502 path delay 727 ptp4l[1300.118]: master offset 3 s2 freq +31474 path delay 731 ptp4l[1301.118]: master offset -35 s2 freq +31437 path delay 733 ptp4l[1302.118]: master offset -16 s2 freq +31445 path delay 733 ptp4l[1303.118]: master offset 94 s2 freq +31550 path delay 722 ptp4l[1304.118]: master offset 16 s2 freq +31501 path delay 722 ptp4l[1305.118]: master offset -18 s2 freq +31471 path delay 720 ptp4l[1306.118]: master offset -55 s2 freq +31429 path delay 718 ptp4l[1307.118]: master offset 45 s2 freq +31513 path delay 718 I measure as well using an I/O pin on my board. Therefore I wrote a little C program that sets the pin at every full second using clock_gettime() and clock_nanosleep(). The C program and the I/O's are running in Real Time. The I/O pins are connected to an oscilloscope. The strange thing is that it seems to be quite accurate in the first time. Very often the output seems to be exactly the same, but then it jumps for a second to an offset of about +-25usec and then back again. See the output here: http://s14.postimg.org/gvjscmj35/PRINT.jpg I know that there is time "lost" during the measurement with an C program but it should not be that much. I realy appreciate your help. Benny -----Ursprüngliche Nachricht----- Von: Keller, Jacob E [mailto:jac...@in...] Gesendet: Montag, 8. April 2013 20:05 An: Rapp, Tim-Benjamin; ric...@gm... Cc: lin...@li... Betreff: RE: [Linuxptp-users] can't get linux PTP to run > -----Original Message----- > From: Tim...@de... [mailto:Tim- > Ben...@de...] > Sent: Monday, April 08, 2013 7:22 AM > To: ric...@gm... > Cc: lin...@li... > Subject: Re: [Linuxptp-users] can't get linux PTP to run > > I'm not on kernel 3.9 maybe that's why I get the 25usec offset. > My master clock is using hardware time stamping with kernel 3.2 (with > RT support) and the patched e1000e driver. > (http://sourceforge.net/projects/e1000/files/e1000e%20stable/) > > What offset do you get and how do you measure it? Maybe I do get the > error because of my way to measure the offset. > > Benny > > -----Ursprüngliche Nachricht----- > Von: Richard Cochran [mailto:ric...@gm...] > Gesendet: Samstag, 6. April 2013 11:58 > An: Rapp, Tim-Benjamin > Cc: lin...@li... > Betreff: Re: [Linuxptp-users] can't get linux PTP to run > > On Wed, Apr 03, 2013 at 06:44:30AM +0000, Tim- > Ben...@de... wrote: > > > > Well I'm testing on a custom board. It's the control for a laser > > machine- > tool. > > > > The Ethernet modules and drivers are: "e1000e version: 2.3.2-NAPI, > Intel Corporation 82574L Gigabit Network Connection, Intel(R) PRO/1000 > Network Connection" > > I've tried to turn a little bit at the servo number but to be honest > > I can't > really figure out what the different numbers are. > > Today I tried my 82574 card with kernel 3.9-rc2 and the lastest ptp4l, > and it seems to be working fine. Perhaps the 25 usec offset error you > see is because your master clock is using software time stamping? > > HTH, > Richard > We measure offset using what ptp4l displays. More accurate measurement can be done with some hardware setups which actually directly output clock to a pin, etc. But most cards I have cannot do this, and even then ptp4l is pretty accurate. Is ptp4l itself displaying +/-25 on the screen? Here is example log for my cards - ptp4l[499579.068]: selected /dev/ptp1 as PTP clock ptp4l[499579.070]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[499579.070]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[499585.070]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[499592.971]: port 1: new foreign master a0369f.fffe.0e2288-1 ptp4l[499596.971]: selected best master clock a0369f.fffe.0e2288 ptp4l[499596.971]: port 1: MASTER to UNCALIBRATED on RS_SLAVE ptp4l[499597.973]: master offset 64733 s0 freq +0 path delay 2240 ptp4l[499598.973]: master offset 64733 s1 freq +0 path delay 2240 ptp4l[499599.973]: master offset -1632 s2 freq -1632 path delay 2240 ptp4l[499599.973]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[499600.973]: master offset 64 s2 freq -426 path delay 2174 ptp4l[499601.973]: master offset 503 s2 freq +33 path delay 2161 ptp4l[499602.973]: master offset 472 s2 freq +152 path delay 2161 ptp4l[499603.973]: master offset 285 s2 freq +107 path delay 2196 ptp4l[499604.973]: master offset 158 s2 freq +66 path delay 2215 ptp4l[499605.973]: master offset 93 s2 freq +48 path delay 2215 ptp4l[499606.973]: master offset 44 s2 freq +27 path delay 2216 ptp4l[499607.974]: master offset 16 s2 freq +12 path delay 2217 ptp4l[499608.974]: master offset 4 s2 freq +5 path delay 2217 ptp4l[499609.974]: master offset -8 s2 freq -6 path delay 2225 ptp4l[499610.974]: master offset -21 s2 freq -21 path delay 2243 ptp4l[499611.974]: master offset 0 s2 freq -7 path delay 2243 ptp4l[499612.974]: master offset -4 s2 freq -11 path delay 2253 ptp4l[499613.974]: master offset 11 s2 freq +3 path delay 2248 ptp4l[499614.974]: master offset 8 s2 freq +3 path delay 2247 ptp4l[499615.974]: master offset 5 s2 freq +3 path delay 2247 Note that the master offset is measured in *nanoseconds* not microseconds. And that offset is as measured by PTP4l, but does not necessarily directly match offset of two pins set to create a clock signal. That is a much more complicated setup. It is also the only way to get more accurate information. If you just "read clock A, read clock B" you have a lot of slop between reads. And even if you "read clock A, read clock B, read clock A" and average the times you are really not accurate either. - Jake |
|
From: Richard C. <ric...@gm...> - 2013-04-08 18:41:03
|
On Mon, Apr 08, 2013 at 04:17:46PM +0200, Mozhdeh Kamel wrote: > I mean, I am thinking of having several virtual machines (such as VBox), > run the linux PTP project on each on them. and I can connect them together > through GRE or other tunnel. Use TC on linux or NeteM to add delay and > jitter . But without hardware time stamping, you are not going to get very good synchronization performance. Here is another simulation idea you could explore. It would be very interesting to be able to test the BMC in a simulated network, and to test the clock servos as well. Take a look at Miroslav Lichvar's clock and network simulator to get an idea of what can be done. http://mlichvar.fedorapeople.org/clknetsim It would be a fair amount of programming, but you could then simulate the hardware timestamping as exactly as you wish. HTH, Richard |
|
From: Keller, J. E <jac...@in...> - 2013-04-08 18:05:35
|
> -----Original Message----- > From: Tim...@de... [mailto:Tim- > Ben...@de...] > Sent: Monday, April 08, 2013 7:22 AM > To: ric...@gm... > Cc: lin...@li... > Subject: Re: [Linuxptp-users] can't get linux PTP to run > > I'm not on kernel 3.9 maybe that's why I get the 25usec offset. > My master clock is using hardware time stamping with kernel 3.2 (with > RT support) and the patched e1000e driver. > (http://sourceforge.net/projects/e1000/files/e1000e%20stable/) > > What offset do you get and how do you measure it? Maybe I do get the > error because of my way to measure the offset. > > Benny > > -----Ursprüngliche Nachricht----- > Von: Richard Cochran [mailto:ric...@gm...] > Gesendet: Samstag, 6. April 2013 11:58 > An: Rapp, Tim-Benjamin > Cc: lin...@li... > Betreff: Re: [Linuxptp-users] can't get linux PTP to run > > On Wed, Apr 03, 2013 at 06:44:30AM +0000, Tim- > Ben...@de... wrote: > > > > Well I'm testing on a custom board. It's the control for a laser machine- > tool. > > > > The Ethernet modules and drivers are: "e1000e version: 2.3.2-NAPI, > Intel Corporation 82574L Gigabit Network Connection, Intel(R) PRO/1000 > Network Connection" > > I've tried to turn a little bit at the servo number but to be honest I can't > really figure out what the different numbers are. > > Today I tried my 82574 card with kernel 3.9-rc2 and the lastest ptp4l, and > it seems to be working fine. Perhaps the 25 usec offset error you see is > because your master clock is using software time stamping? > > HTH, > Richard > We measure offset using what ptp4l displays. More accurate measurement can be done with some hardware setups which actually directly output clock to a pin, etc. But most cards I have cannot do this, and even then ptp4l is pretty accurate. Is ptp4l itself displaying +/-25 on the screen? Here is example log for my cards - ptp4l[499579.068]: selected /dev/ptp1 as PTP clock ptp4l[499579.070]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[499579.070]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[499585.070]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[499592.971]: port 1: new foreign master a0369f.fffe.0e2288-1 ptp4l[499596.971]: selected best master clock a0369f.fffe.0e2288 ptp4l[499596.971]: port 1: MASTER to UNCALIBRATED on RS_SLAVE ptp4l[499597.973]: master offset 64733 s0 freq +0 path delay 2240 ptp4l[499598.973]: master offset 64733 s1 freq +0 path delay 2240 ptp4l[499599.973]: master offset -1632 s2 freq -1632 path delay 2240 ptp4l[499599.973]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[499600.973]: master offset 64 s2 freq -426 path delay 2174 ptp4l[499601.973]: master offset 503 s2 freq +33 path delay 2161 ptp4l[499602.973]: master offset 472 s2 freq +152 path delay 2161 ptp4l[499603.973]: master offset 285 s2 freq +107 path delay 2196 ptp4l[499604.973]: master offset 158 s2 freq +66 path delay 2215 ptp4l[499605.973]: master offset 93 s2 freq +48 path delay 2215 ptp4l[499606.973]: master offset 44 s2 freq +27 path delay 2216 ptp4l[499607.974]: master offset 16 s2 freq +12 path delay 2217 ptp4l[499608.974]: master offset 4 s2 freq +5 path delay 2217 ptp4l[499609.974]: master offset -8 s2 freq -6 path delay 2225 ptp4l[499610.974]: master offset -21 s2 freq -21 path delay 2243 ptp4l[499611.974]: master offset 0 s2 freq -7 path delay 2243 ptp4l[499612.974]: master offset -4 s2 freq -11 path delay 2253 ptp4l[499613.974]: master offset 11 s2 freq +3 path delay 2248 ptp4l[499614.974]: master offset 8 s2 freq +3 path delay 2247 ptp4l[499615.974]: master offset 5 s2 freq +3 path delay 2247 Note that the master offset is measured in *nanoseconds* not microseconds. And that offset is as measured by PTP4l, but does not necessarily directly match offset of two pins set to create a clock signal. That is a much more complicated setup. It is also the only way to get more accurate information. If you just "read clock A, read clock B" you have a lot of slop between reads. And even if you "read clock A, read clock B, read clock A" and average the times you are really not accurate either. - Jake |
|
From: <Tim...@de...> - 2013-04-08 14:22:04
|
I'm not on kernel 3.9 maybe that's why I get the 25usec offset. My master clock is using hardware time stamping with kernel 3.2 (with RT support) and the patched e1000e driver. (http://sourceforge.net/projects/e1000/files/e1000e%20stable/) What offset do you get and how do you measure it? Maybe I do get the error because of my way to measure the offset. Benny -----Ursprüngliche Nachricht----- Von: Richard Cochran [mailto:ric...@gm...] Gesendet: Samstag, 6. April 2013 11:58 An: Rapp, Tim-Benjamin Cc: lin...@li... Betreff: Re: [Linuxptp-users] can't get linux PTP to run On Wed, Apr 03, 2013 at 06:44:30AM +0000, Tim...@de... wrote: > > Well I'm testing on a custom board. It's the control for a laser machine-tool. > > The Ethernet modules and drivers are: "e1000e version: 2.3.2-NAPI, Intel Corporation 82574L Gigabit Network Connection, Intel(R) PRO/1000 Network Connection" > I've tried to turn a little bit at the servo number but to be honest I can't really figure out what the different numbers are. Today I tried my 82574 card with kernel 3.9-rc2 and the lastest ptp4l, and it seems to be working fine. Perhaps the 25 usec offset error you see is because your master clock is using software time stamping? HTH, Richard |
|
From: Mozhdeh K. <kam...@gm...> - 2013-04-08 14:18:18
|
I mean, I am thinking of having several virtual machines (such as VBox), run the linux PTP project on each on them. and I can connect them together through GRE or other tunnel. Use TC on linux or NeteM to add delay and jitter . BR, Mozhdeh On Sat, Apr 6, 2013 at 12:18 PM, Richard Cochran <ric...@gm...>wrote: > On Thu, Apr 04, 2013 at 01:04:49PM +0200, Mozhdeh Kamel wrote: > > > > Actually I am going to design a network to run the PTP protocol(with BC). > > But the main problem for me is I don't access to real hardware. I though > > maybe using a PC with several network card (HW time stamping) would help. > > But, share clock is another problem!!! > > With a small modification to ptp4l, you might be able to use multiple, > separate PCI cards together as a BC. We just need to disable* the check > in ptp4l that makes sure all the PHC clocks are the save. For example: > > port1 eth0 /dev/ptp0 - ptp4l controls this clock, port connected to GM > port2 eth1 /dev/ptp1 - phc2sys instance 1 slaves this clock to /dev/ptp0 > port3 eth2 /dev/ptp2 - phc2sys instance 2 slaves this clock to /dev/ptp0 > > In order to test how well phc2sys synchronizes the internal clocks, > you could run three separate ptp4l instances, one per port, and > connect all the ports to the same master through a switch. If you set > the ptp4l "free running" option on ports 2 and 3, then you can measure > the time error between the phc2sys servo and the PTP network time. > > What PTP hardware do you have to choose from? > > > Now, I am thinking of possibility to use of virtual switch, router and > NIC > > .. Is anyone have experience of it?? Is it possible? > > I am not sure what you mean by "virtual" here. > > HTH, > Richard > > * Or you could use a Linux kernel version before 3.5, without > ETHTOOL_GET_TS_INFO support. > > -- *Mozhdeh * |
|
From: Richard C. <ric...@gm...> - 2013-04-06 10:18:22
|
On Thu, Apr 04, 2013 at 01:04:49PM +0200, Mozhdeh Kamel wrote: > > Actually I am going to design a network to run the PTP protocol(with BC). > But the main problem for me is I don't access to real hardware. I though > maybe using a PC with several network card (HW time stamping) would help. > But, share clock is another problem!!! With a small modification to ptp4l, you might be able to use multiple, separate PCI cards together as a BC. We just need to disable* the check in ptp4l that makes sure all the PHC clocks are the save. For example: port1 eth0 /dev/ptp0 - ptp4l controls this clock, port connected to GM port2 eth1 /dev/ptp1 - phc2sys instance 1 slaves this clock to /dev/ptp0 port3 eth2 /dev/ptp2 - phc2sys instance 2 slaves this clock to /dev/ptp0 In order to test how well phc2sys synchronizes the internal clocks, you could run three separate ptp4l instances, one per port, and connect all the ports to the same master through a switch. If you set the ptp4l "free running" option on ports 2 and 3, then you can measure the time error between the phc2sys servo and the PTP network time. What PTP hardware do you have to choose from? > Now, I am thinking of possibility to use of virtual switch, router and NIC > .. Is anyone have experience of it?? Is it possible? I am not sure what you mean by "virtual" here. HTH, Richard * Or you could use a Linux kernel version before 3.5, without ETHTOOL_GET_TS_INFO support. |
|
From: Richard C. <ric...@gm...> - 2013-04-06 09:58:38
|
On Wed, Apr 03, 2013 at 06:44:30AM +0000, Tim...@de... wrote: > > Well I'm testing on a custom board. It's the control for a laser machine-tool. > > The Ethernet modules and drivers are: "e1000e version: 2.3.2-NAPI, Intel Corporation 82574L Gigabit Network Connection, Intel(R) PRO/1000 Network Connection" > I've tried to turn a little bit at the servo number but to be honest I can't really figure out what the different numbers are. Today I tried my 82574 card with kernel 3.9-rc2 and the lastest ptp4l, and it seems to be working fine. Perhaps the 25 usec offset error you see is because your master clock is using software time stamping? HTH, Richard |
|
From: Mozhdeh K. <mo...@us...> - 2013-04-04 11:05:16
|
Thank you for the reply. Actually I am going to design a network to run the PTP protocol(with BC). But the main problem for me is I don't access to real hardware. I though maybe using a PC with several network card (HW time stamping) would help. But, share clock is another problem!!! Now, I am thinking of possibility to use of virtual switch, router and NIC .. Is anyone have experience of it?? Is it possible? BR, Mozhdeh On Thu, Mar 21, 2013 at 9:33 PM, Keller, Jacob E <jac...@in...>wrote: > > -----Original Message----- > > From: Richard Cochran [mailto:ric...@gm...] > > Sent: Thursday, March 21, 2013 11:58 AM > > To: Mozhdeh Kamel > > Cc: lin...@li... > > Subject: Re: [Linuxptp-users] List of Boundary clocks > > > > 2. Get a computer with true HW time stamping support. Note that you > > cannot just use a box with multiple PCI cards, for example. The > > ports must all share *one* clock. > > > > > > HTH, > > Richard > > > > Also, just because the ports are on the same PCI card also does not mean > they share a clock. You have to be sure the hardware supports a single > clock for multiple ports. > > - Jake > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: Keller, J. E <jac...@in...> - 2013-04-03 20:20:47
|
> -----Original Message----- > From: Tim...@de... [mailto:Tim- > Ben...@de...] > Sent: Tuesday, April 02, 2013 11:45 PM > To: lin...@li... > Subject: Re: [Linuxptp-users] can't get linux PTP to run > > > Well I'm testing on a custom board. It's the control for a laser machine- > tool. > > The Ethernet modules and drivers are: "e1000e version: 2.3.2-NAPI, > Intel Corporation 82574L Gigabit Network Connection, Intel(R) PRO/1000 > Network Connection" > I've tried to turn a little bit at the servo number but to be honest I can't > really figure out what the different numbers are. > > - Benny > Understanding the clock servo is definitely a challenge. It looks like the part you have, the 82574L based part may not have as high a precision as the parts that I normally work with. I will ask and see if I can find out what numbers are expected. Thanks - Jake |
|
From: <Tim...@de...> - 2013-04-03 06:44:39
|
Well I'm testing on a custom board. It's the control for a laser machine-tool. The Ethernet modules and drivers are: "e1000e version: 2.3.2-NAPI, Intel Corporation 82574L Gigabit Network Connection, Intel(R) PRO/1000 Network Connection" I've tried to turn a little bit at the servo number but to be honest I can't really figure out what the different numbers are. - Benny -----Ursprüngliche Nachricht----- Von: Keller, Jacob E [mailto:jac...@in...] Gesendet: Dienstag, 2. April 2013 22:31 An: Rapp, Tim-Benjamin; lin...@li... Betreff: RE: [Linuxptp-users] can't get linux PTP to run > -----Original Message----- > From: Tim...@de... [mailto:Tim- > Ben...@de...] > Sent: Tuesday, April 02, 2013 1:45 AM > To: lin...@li... > Subject: Re: [Linuxptp-users] can't get linux PTP to run > > Thanks guys, > with your help I got ptp4l to run an my 3.2 Kernel. > > The only strange thing is that I get a jitter (measured every second) > of about +- 25 microseconds this should be less with hw timestamps. > Maybe I have to play around with the settings a little bit. > > But you have been a great help to me Thanks Benny >Which device are you using? It could also be your P/I servo numbers. >- Jake |
|
From: Keller, J. E <jac...@in...> - 2013-04-02 20:31:36
|
> -----Original Message----- > From: Tim...@de... [mailto:Tim- > Ben...@de...] > Sent: Tuesday, April 02, 2013 1:45 AM > To: lin...@li... > Subject: Re: [Linuxptp-users] can't get linux PTP to run > > Thanks guys, > with your help I got ptp4l to run an my 3.2 Kernel. > > The only strange thing is that I get a jitter (measured every second) of > about +- 25 microseconds this should be less with hw timestamps. > Maybe I have to play around with the settings a little bit. > > But you have been a great help to me Thanks > Benny Which device are you using? It could also be your P/I servo numbers. - Jake |
|
From: <Tim...@de...> - 2013-04-02 08:45:34
|
Thanks guys, with your help I got ptp4l to run an my 3.2 Kernel. The only strange thing is that I get a jitter (measured every second) of about +- 25 microseconds this should be less with hw timestamps. Maybe I have to play around with the settings a little bit. But you have been a great help to me Thanks Benny -----Ursprüngliche Nachricht----- Von: Richard Cochran [mailto:ric...@gm...] Gesendet: Dienstag, 26. März 2013 19:53 An: Rapp, Tim-Benjamin Cc: lin...@li... Betreff: Re: [Linuxptp-users] can't get linux PTP to run On Tue, Mar 26, 2013 at 04:00:11PM +0000, Tim...@de... wrote: > Hi, > > > I tested the ptp test porgramm. > > capabilities: > 599999999 maximum frequency adjustment (ppb) > 0 programmable alarms > 0 external time stamp channels > 0 programmable periodic signals > 0 pulse per second > > What i can do: > I can adjust the frequency, > get ptp clock time > set/get the ptp clock from and to system time. > time shift okay > > What i can not do: > timer_create: Operation not supported > PTP_ENABLE_PPS: Operation not supported This all looks good. > I also tested /Documentation/networking/timestamping this seems fine: But here you should see some output about getting time stamps from the transmitted packets. Also, if you run a second instance of the program on another host, then you should also see time stamps on the received packets. HTH, Richard |
|
From: Keller, J. E <jac...@in...> - 2013-03-28 21:17:42
|
> -----Original Message----- > From: Jim Baxter [mailto:jim...@uk...] > Sent: Thursday, March 28, 2013 1:55 PM > To: Keller, Jacob E > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Validating PTP > > > On 28/03/13 20:44, Keller, Jacob E wrote: > >> -----Original Message----- > >> From: Jim Baxter [mailto:jim...@uk...] > >> Sent: Thursday, March 28, 2013 5:01 AM > >> To: lin...@li... > >> Subject: [Linuxptp-users] Validating PTP > >> > >> Is there a way to test the PTP time received by a ptp4l slave device? > >> > >> I am trying to test it is working correctly. > >> > >> Thank you for your help, > >> Jim > >> > >> > > It really depends on what you mean by this? You want to know > whether the hardware timestamp is correct? Only way to reliably do > that would be a bus analyzer I expect... > > > > You need to clarify what goal you are trying to achieve here.. > > > > Thanks > > > > - Jake > > > Hi, > > Perhaps I was misunderstanding PTP, I wanted to be able to use or view > the timestamp so I know it is working correctly. > > Can it be used by phc2sys to set the CLOCK_REALTIME? > > Thanks, > Jim Yes. There is also available in the Documentation/ptp of the linux kernel which lets you run commands on any ptp device. That is probably what you are looking for. As for setting clock_realtime, you can do this via running "./phc2sys -i ethX" if you are running on kernel 3.5 or newer. Else you need to determine which /dev/ptpX device you are setting in ptp4l, and use "./phc2sys -d /dev/ptpX" That should begin tuning the CLOCK_REALTIME, which will set the kernel time to match that PPS, and keep it in track. You will probably want to disable the ntp/etc services that would conflict with this. Also note that you may not see a time update in something like a panel update for a little while. Those applets I have noticed taking a bit to update to the new time. You can tweak the settings on this but the defaults should be alright. It might be handy for someone to right daemon init scripts or systemd scripts, but I do not have time to do this at present. Hope that information helps Thanks - Jake |
|
From: Jim B. <jim...@uk...> - 2013-03-28 20:54:50
|
On 28/03/13 20:44, Keller, Jacob E wrote: >> -----Original Message----- >> From: Jim Baxter [mailto:jim...@uk...] >> Sent: Thursday, March 28, 2013 5:01 AM >> To: lin...@li... >> Subject: [Linuxptp-users] Validating PTP >> >> Is there a way to test the PTP time received by a ptp4l slave device? >> >> I am trying to test it is working correctly. >> >> Thank you for your help, >> Jim >> >> > It really depends on what you mean by this? You want to know whether the hardware timestamp is correct? Only way to reliably do that would be a bus analyzer I expect... > > You need to clarify what goal you are trying to achieve here.. > > Thanks > > - Jake > Hi, Perhaps I was misunderstanding PTP, I wanted to be able to use or view the timestamp so I know it is working correctly. Can it be used by phc2sys to set the CLOCK_REALTIME? Thanks, Jim |
|
From: Keller, J. E <jac...@in...> - 2013-03-28 20:44:19
|
> -----Original Message----- > From: Jim Baxter [mailto:jim...@uk...] > Sent: Thursday, March 28, 2013 5:01 AM > To: lin...@li... > Subject: [Linuxptp-users] Validating PTP > > Is there a way to test the PTP time received by a ptp4l slave device? > > I am trying to test it is working correctly. > > Thank you for your help, > Jim > > It really depends on what you mean by this? You want to know whether the hardware timestamp is correct? Only way to reliably do that would be a bus analyzer I expect... You need to clarify what goal you are trying to achieve here.. Thanks - Jake |
|
From: Jim B. <jim...@uk...> - 2013-03-28 12:19:25
|
Is there a way to test the PTP time received by a ptp4l slave device? I am trying to test it is working correctly. Thank you for your help, Jim |
|
From: Richard C. <ric...@gm...> - 2013-03-26 18:53:25
|
On Tue, Mar 26, 2013 at 04:00:11PM +0000, Tim...@de... wrote: > Hi, > > > I tested the ptp test porgramm. > > capabilities: > 599999999 maximum frequency adjustment (ppb) > 0 programmable alarms > 0 external time stamp channels > 0 programmable periodic signals > 0 pulse per second > > What i can do: > I can adjust the frequency, > get ptp clock time > set/get the ptp clock from and to system time. > time shift okay > > What i can not do: > timer_create: Operation not supported > PTP_ENABLE_PPS: Operation not supported This all looks good. > I also tested /Documentation/networking/timestamping this seems fine: But here you should see some output about getting time stamps from the transmitted packets. Also, if you run a second instance of the program on another host, then you should also see time stamps on the received packets. HTH, Richard |
|
From: Keller, J. E <jac...@in...> - 2013-03-26 18:34:00
|
FYI, the PTP4l does not directly modify the system (kernel) time, except in the case of Software timestamping. Each ptp device actually represents its own clock. You should use phc2sys application to modify the system time in addition. The reason for this design is because the clock on the adapter is completely disconnected from the system time in the kernel (The source is completely different). What version of the kernel are you using? If you don't have v3.5 with the get_ts_info ethtool support, you need to ensure that the /dev/ptp0 device is actually the device for the port you are using. Intel's Ethernet adapters create one ptp device per port due to being unable to represent multiple ports using the same clock. If you have a multi-port adapter that could be part of why you are seeing some issues. Do those negative adjust values go away over time? As in does it stabilize? - Jake > -----Original Message----- > From: Tim...@de... [mailto:Tim- > Ben...@de...] > Sent: Tuesday, March 26, 2013 7:51 AM > To: lin...@li... > Subject: Re: [Linuxptp-users] can't get linux PTP to run > > Hi, > > ok it seems that the driver works now (down ask me what I have > changed, don't know). I can now use HW stamping. > > But the time does not change at all. If I start the master clock it shows: > ptp4l -f ptp.cfg -p /dev/ptp0 -i eth2 > ptp4l[7470.955]: selected /dev/ptp0 as PTP clock > ptp4l[7470.955]: failed to read out the clock frequency > adjustment: Operation not supported > ptp4l[7470.955]: port 1: get_ts_info not supported > ptp4l[7470.958]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[7470.958]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[7476.958]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > And if I start the slave it shows: > ptp4l -f ptp.cfg -p /dev/ptp0 -i eth2 -s > ptp4l[8394.096]: selected /dev/ptp0 as PTP clock > ptp4l[8394.096]: failed to read out the clock frequency > adjustment: Operation not supported > ptp4l[8394.096]: port 1: get_ts_info not supported > ptp4l[8394.098]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[8394.098]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[8395.985]: port 1: new foreign master 745798.fffe.000021-1 > ptp4l[8399.987]: selected best master clock 745798.fffe.000021 > ptp4l[8399.987]: port 1: LISTENING to UNCALIBRATED on > RS_SLAVE > ptp4l[8401.429]: negative path delay -5520 > ptp4l[8401.429]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8401.429]: t2 - t3 = -427837600 > ptp4l[8401.429]: t4 - t1 = +427826560 > ptp4l[8401.429]: c1 0 > ptp4l[8401.429]: c2 0 > ptp4l[8401.429]: c3 0 > ptp4l[8402.001]: master offset -1637602062061189501 s0 freq > +0 path delay -5520 > ptp4l[8402.750]: negative path delay -10180 > ptp4l[8402.750]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8402.750]: t2 - t3 = -748785600 > ptp4l[8402.750]: t4 - t1 = +748765240 > ptp4l[8402.750]: c1 0 > ptp4l[8402.750]: c2 0 > ptp4l[8402.750]: c3 0 > ptp4l[8403.002]: master offset -1637602062061158011 s1 freq > +31485 path delay -7850 > ptp4l[8404.002]: master offset -1637602062061128851 s2 freq - > 32767999 path delay -7850 > ptp4l[8404.002]: port 1: UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > ptp4l[8404.216]: negative path delay -2380 > ptp4l[8404.216]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8404.216]: t2 - t3 = -213503440 > ptp4l[8404.216]: t4 - t1 = +213498680 > ptp4l[8404.216]: c1 0 > ptp4l[8404.216]: c2 0 > ptp4l[8404.216]: c3 0 > ptp4l[8405.003]: master offset -1637602062061101475 s2 freq - > 32767999 path delay -6026 > ptp4l[8405.072]: negative path delay -280 > ptp4l[8405.072]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8405.072]: t2 - t3 = -69388320 > ptp4l[8405.072]: t4 - t1 = +69387760 > ptp4l[8405.072]: c1 0 > ptp4l[8405.072]: c2 0 > ptp4l[8405.072]: c3 0 > ptp4l[8405.778]: negative path delay -10560 > ptp4l[8405.778]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8405.778]: t2 - t3 = -774949920 > ptp4l[8405.778]: t4 - t1 = +774928800 > ptp4l[8405.778]: c1 0 > ptp4l[8405.778]: c2 0 > ptp4l[8405.778]: c3 0 > ptp4l[8406.003]: master offset -1637602062061072517 s2 freq - > 32767999 path delay -5784 > ptp4l[8406.374]: negative path delay -4680 > ptp4l[8406.374]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8406.374]: t2 - t3 = -370912120 > ptp4l[8406.374]: t4 - t1 = +370902760 > ptp4l[8406.374]: c1 0 > ptp4l[8406.374]: c2 0 > ptp4l[8406.374]: c3 0 > ptp4l[8406.885]: negative path delay -12120 > ptp4l[8406.885]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8406.885]: t2 - t3 = -881060360 > ptp4l[8406.885]: t4 - t1 = +881036120 > ptp4l[8406.885]: c1 0 > ptp4l[8406.885]: c2 0 > ptp4l[8406.885]: c3 0 > ptp4l[8407.004]: master offset -1637602062061042610 s2 freq - > 32767999 path delay -6531 > > My config is: > [global] > # > # Port Data Set > # > logAnnounceInterval 1 > logSyncInterval 0 > logMinDelayReqInterval 0 > logMinPdelayReqInterval 0 > announceReceiptTimeout 3 > delayAsymmetry 0 > fault_reset_interval 4 > # > # Run time options > # > assume_two_step 0 > logging_level 6 > path_trace_enabled 1 > follow_up_info 0 > tx_timestamp_retries 100 > use_syslog 0 > verbose 1 > summary_interval 0 > # > # Servo Options > # > pi_proportional_const 0.0 > pi_integral_const 0.0 > pi_offset_const 0.0 > clock_servo pi > # > # Default interface options > # > network_transport UDPv4 > delay_mechanism E2E > time_stamping hardware > > If I check the time (both date and hwclock) on both PCs, one says (for > example) 10:12:11 and the other says 08:45:00. Even after an hour > running ptp4l the time difference is the same. > > I think it got something to do with the clock frequency adjustment. > > I'm getting closer to success but what am I doing wrong now? > > Thanks, > Benny > > > -----Ursprüngliche Nachricht----- > Von: Richard Cochran [mailto:ric...@gm...] > Gesendet: Montag, 25. März 2013 19:20 > An: Rapp, Tim-Benjamin > Cc: lin...@li... > Betreff: Re: [Linuxptp-users] can't get linux PTP to run > > On Mon, Mar 25, 2013 at 08:11:12AM +0000, Tim- > Ben...@de... wrote: > > Hi, > > > > well im using the modified driver from sourceforge (see post of Jake). > > Therfore I only can use software timetamping, because HW- > timespamps are not supported. If i dont use HW timestamping then I > dont need to pick an /dev/ptp (I dont have one). > > Looking at the code, in e1000e-2.3.2.tar.gz, and in its README, HW time > stamps *are* supported, but you need to add flag when building. > > IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC) > ------------------------------------------------------------ > Support for the IEEE 1588 Precision Time Protocol (PTP) Hardware Clock > (PHC) > is disabled by default in this out-of-tree driver even if it is enabled for > the in-kernel driver. > > The feature is available only on a subset of devices supported by the > driver, and can only be enabled on 3.0 and newer kernels that also > have > the PTP_1588_CLOCK support compiled in statically or as a module. To > enable > the feature when compiling the driver, add 'CFLAGS_EXTRA=- > DE1000E_PTP' to > the command line. > > > After your information I changed to using a config file. Did I do it like > you ment? Adding the tx_timestamp_retries? I tried several different > numbers. Always the same error. > > > > The command I use is: > > ptp4l -i eht2 -f /etc/ptp4l.cfg > > > > the config is: > > [global] > > # > > logging_level 6 > > tx_timestamp_retries 100 > > use_syslog 0 > > verbose 1 > > time_stamping software > > When using SW time stamping, the tx_timestamp_retries has no effect, > since the time stamp is taken during the 'send' call. > > I can only suggest to recheck if: > > - you are really using the out-of-tree driver > - that eth2 is really, truely serviced by the e1000e driver > > There is a Linux test program for time stamping in > > Documentation/networking/timestamping > > Can you test your interface with that program like so: > > timestamping eth2 SOF_TIMESTAMPING_TX_SOFTWARE > SOF_TIMESTAMPING_RX_SOFTWARE SOF_TIMESTAMPING_SOFTWARE > > and post the results? > > Thanks, > Richard > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: <Tim...@de...> - 2013-03-26 16:00:21
|
Hi, I tested the ptp test porgramm. capabilities: 599999999 maximum frequency adjustment (ppb) 0 programmable alarms 0 external time stamp channels 0 programmable periodic signals 0 pulse per second What i can do: I can adjust the frequency, get ptp clock time set/get the ptp clock from and to system time. time shift okay What i can not do: timer_create: Operation not supported PTP_ENABLE_PPS: Operation not supported I also tested /Documentation/networking/timestamping this seems fine: SO_TIMESTAMP 0 SO_TIMESTAMPNS 0 SO_TIMESTAMPING 0 873.135483: sent 124 bytes 873.135517: select 1864483us 875.000334: select returned: 0, success 875.000423: sent 124 bytes 875.000441: select 4999559us 880.004323: select returned: 0, success 880.004497: sent 124 bytes 880.004521: select 4995479us I also set both clocks to nealy the same nothing changed. Thanks, Benny >>Hi, >> >> >>I'm not an expert, but the log seems to indicate a systematically decreasing master time offset, with a maxed out freq. adjustment. I would say the >>PHC is somehow unable to properly step to a new value (clock_settime/adjtime fails). >> >>You could try setting both clocks nearly equal and see if they eventually converge. >> >>You could also compile and try the testptp program (/Documentation/ptp/testptp.c) to see if your PHC clock actually works. >> >>I'm not sure if support of the get_ts_info() call is required. >> >> >>J. |
|
From: Jeroen V. d. K. <jer...@gm...> - 2013-03-26 15:11:51
|
Hi, I'm not an expert, but the log seems to indicate a systematically decreasing master time offset, with a maxed out freq. adjustment. I would say the PHC is somehow unable to properly step to a new value (clock_settime/adjtime fails). You could try setting both clocks nearly equal and see if they eventually converge. You could also compile and try the testptp program (/Documentation/ptp/testptp.c) to see if your PHC clock actually works. I'm not sure if support of the get_ts_info() call is required. J. 2013/3/26 <Tim...@de...> > Hi, > > ok it seems that the driver works now (down ask me what I have changed, > don't know). I can now use HW stamping. > > But the time does not change at all. If I start the master clock it shows: > ptp4l -f ptp.cfg -p /dev/ptp0 -i eth2 > ptp4l[7470.955]: selected /dev/ptp0 as PTP clock > ptp4l[7470.955]: failed to read out the clock frequency > adjustment: Operation not supported > ptp4l[7470.955]: port 1: get_ts_info not supported > ptp4l[7470.958]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[7470.958]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[7476.958]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > And if I start the slave it shows: > ptp4l -f ptp.cfg -p /dev/ptp0 -i eth2 -s > ptp4l[8394.096]: selected /dev/ptp0 as PTP clock > ptp4l[8394.096]: failed to read out the clock frequency > adjustment: Operation not supported > ptp4l[8394.096]: port 1: get_ts_info not supported > ptp4l[8394.098]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[8394.098]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[8395.985]: port 1: new foreign master 745798.fffe.000021-1 > ptp4l[8399.987]: selected best master clock 745798.fffe.000021 > ptp4l[8399.987]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[8401.429]: negative path delay -5520 > ptp4l[8401.429]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8401.429]: t2 - t3 = -427837600 > ptp4l[8401.429]: t4 - t1 = +427826560 > ptp4l[8401.429]: c1 0 > ptp4l[8401.429]: c2 0 > ptp4l[8401.429]: c3 0 > ptp4l[8402.001]: master offset -1637602062061189501 s0 freq > +0 path delay -5520 > ptp4l[8402.750]: negative path delay -10180 > ptp4l[8402.750]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8402.750]: t2 - t3 = -748785600 > ptp4l[8402.750]: t4 - t1 = +748765240 > ptp4l[8402.750]: c1 0 > ptp4l[8402.750]: c2 0 > ptp4l[8402.750]: c3 0 > ptp4l[8403.002]: master offset -1637602062061158011 s1 freq > +31485 path delay -7850 > ptp4l[8404.002]: master offset -1637602062061128851 s2 freq > -32767999 path delay -7850 > ptp4l[8404.002]: port 1: UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > ptp4l[8404.216]: negative path delay -2380 > ptp4l[8404.216]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8404.216]: t2 - t3 = -213503440 > ptp4l[8404.216]: t4 - t1 = +213498680 > ptp4l[8404.216]: c1 0 > ptp4l[8404.216]: c2 0 > ptp4l[8404.216]: c3 0 > ptp4l[8405.003]: master offset -1637602062061101475 s2 freq > -32767999 path delay -6026 > ptp4l[8405.072]: negative path delay -280 > ptp4l[8405.072]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8405.072]: t2 - t3 = -69388320 > ptp4l[8405.072]: t4 - t1 = +69387760 > ptp4l[8405.072]: c1 0 > ptp4l[8405.072]: c2 0 > ptp4l[8405.072]: c3 0 > ptp4l[8405.778]: negative path delay -10560 > ptp4l[8405.778]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8405.778]: t2 - t3 = -774949920 > ptp4l[8405.778]: t4 - t1 = +774928800 > ptp4l[8405.778]: c1 0 > ptp4l[8405.778]: c2 0 > ptp4l[8405.778]: c3 0 > ptp4l[8406.003]: master offset -1637602062061072517 s2 freq > -32767999 path delay -5784 > ptp4l[8406.374]: negative path delay -4680 > ptp4l[8406.374]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8406.374]: t2 - t3 = -370912120 > ptp4l[8406.374]: t4 - t1 = +370902760 > ptp4l[8406.374]: c1 0 > ptp4l[8406.374]: c2 0 > ptp4l[8406.374]: c3 0 > ptp4l[8406.885]: negative path delay -12120 > ptp4l[8406.885]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[8406.885]: t2 - t3 = -881060360 > ptp4l[8406.885]: t4 - t1 = +881036120 > ptp4l[8406.885]: c1 0 > ptp4l[8406.885]: c2 0 > ptp4l[8406.885]: c3 0 > ptp4l[8407.004]: master offset -1637602062061042610 s2 freq > -32767999 path delay -6531 > > My config is: > [global] > # > # Port Data Set > # > logAnnounceInterval 1 > logSyncInterval 0 > logMinDelayReqInterval 0 > logMinPdelayReqInterval 0 > announceReceiptTimeout 3 > delayAsymmetry 0 > fault_reset_interval 4 > # > # Run time options > # > assume_two_step 0 > logging_level 6 > path_trace_enabled 1 > follow_up_info 0 > tx_timestamp_retries 100 > use_syslog 0 > verbose 1 > summary_interval 0 > # > # Servo Options > # > pi_proportional_const 0.0 > pi_integral_const 0.0 > pi_offset_const 0.0 > clock_servo pi > # > # Default interface options > # > network_transport UDPv4 > delay_mechanism E2E > time_stamping hardware > > If I check the time (both date and hwclock) on both PCs, one says (for > example) 10:12:11 and the other says 08:45:00. Even after an hour running > ptp4l the time difference is the same. > > I think it got something to do with the clock frequency adjustment. > > I'm getting closer to success but what am I doing wrong now? > > Thanks, > Benny > > > -----Ursprüngliche Nachricht----- > Von: Richard Cochran [mailto:ric...@gm...] > Gesendet: Montag, 25. März 2013 19:20 > An: Rapp, Tim-Benjamin > Cc: lin...@li... > Betreff: Re: [Linuxptp-users] can't get linux PTP to run > > On Mon, Mar 25, 2013 at 08:11:12AM +0000, Tim...@de...wrote: > > Hi, > > > > well im using the modified driver from sourceforge (see post of Jake). > > Therfore I only can use software timetamping, because HW-timespamps are > not supported. If i dont use HW timestamping then I dont need to pick an > /dev/ptp (I dont have one). > > Looking at the code, in e1000e-2.3.2.tar.gz, and in its README, HW time > stamps *are* supported, but you need to add flag when building. > > IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC) > ------------------------------------------------------------ > Support for the IEEE 1588 Precision Time Protocol (PTP) Hardware Clock > (PHC) > is disabled by default in this out-of-tree driver even if it is enabled > for > the in-kernel driver. > > The feature is available only on a subset of devices supported by the > driver, and can only be enabled on 3.0 and newer kernels that also have > the PTP_1588_CLOCK support compiled in statically or as a module. To > enable > the feature when compiling the driver, add 'CFLAGS_EXTRA=-DE1000E_PTP' to > the command line. > > > After your information I changed to using a config file. Did I do it > like you ment? Adding the tx_timestamp_retries? I tried several different > numbers. Always the same error. > > > > The command I use is: > > ptp4l -i eht2 -f /etc/ptp4l.cfg > > > > the config is: > > [global] > > # > > logging_level 6 > > tx_timestamp_retries 100 > > use_syslog 0 > > verbose 1 > > time_stamping software > > When using SW time stamping, the tx_timestamp_retries has no effect, since > the time stamp is taken during the 'send' call. > > I can only suggest to recheck if: > > - you are really using the out-of-tree driver > - that eth2 is really, truely serviced by the e1000e driver > > There is a Linux test program for time stamping in > > Documentation/networking/timestamping > > Can you test your interface with that program like so: > > timestamping eth2 SOF_TIMESTAMPING_TX_SOFTWARE > SOF_TIMESTAMPING_RX_SOFTWARE SOF_TIMESTAMPING_SOFTWARE > > and post the results? > > Thanks, > Richard > > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: <Tim...@de...> - 2013-03-26 14:50:53
|
Hi, ok it seems that the driver works now (down ask me what I have changed, don't know). I can now use HW stamping. But the time does not change at all. If I start the master clock it shows: ptp4l -f ptp.cfg -p /dev/ptp0 -i eth2 ptp4l[7470.955]: selected /dev/ptp0 as PTP clock ptp4l[7470.955]: failed to read out the clock frequency adjustment: Operation not supported ptp4l[7470.955]: port 1: get_ts_info not supported ptp4l[7470.958]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[7470.958]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[7476.958]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES And if I start the slave it shows: ptp4l -f ptp.cfg -p /dev/ptp0 -i eth2 -s ptp4l[8394.096]: selected /dev/ptp0 as PTP clock ptp4l[8394.096]: failed to read out the clock frequency adjustment: Operation not supported ptp4l[8394.096]: port 1: get_ts_info not supported ptp4l[8394.098]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[8394.098]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[8395.985]: port 1: new foreign master 745798.fffe.000021-1 ptp4l[8399.987]: selected best master clock 745798.fffe.000021 ptp4l[8399.987]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[8401.429]: negative path delay -5520 ptp4l[8401.429]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[8401.429]: t2 - t3 = -427837600 ptp4l[8401.429]: t4 - t1 = +427826560 ptp4l[8401.429]: c1 0 ptp4l[8401.429]: c2 0 ptp4l[8401.429]: c3 0 ptp4l[8402.001]: master offset -1637602062061189501 s0 freq +0 path delay -5520 ptp4l[8402.750]: negative path delay -10180 ptp4l[8402.750]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[8402.750]: t2 - t3 = -748785600 ptp4l[8402.750]: t4 - t1 = +748765240 ptp4l[8402.750]: c1 0 ptp4l[8402.750]: c2 0 ptp4l[8402.750]: c3 0 ptp4l[8403.002]: master offset -1637602062061158011 s1 freq +31485 path delay -7850 ptp4l[8404.002]: master offset -1637602062061128851 s2 freq -32767999 path delay -7850 ptp4l[8404.002]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[8404.216]: negative path delay -2380 ptp4l[8404.216]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[8404.216]: t2 - t3 = -213503440 ptp4l[8404.216]: t4 - t1 = +213498680 ptp4l[8404.216]: c1 0 ptp4l[8404.216]: c2 0 ptp4l[8404.216]: c3 0 ptp4l[8405.003]: master offset -1637602062061101475 s2 freq -32767999 path delay -6026 ptp4l[8405.072]: negative path delay -280 ptp4l[8405.072]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[8405.072]: t2 - t3 = -69388320 ptp4l[8405.072]: t4 - t1 = +69387760 ptp4l[8405.072]: c1 0 ptp4l[8405.072]: c2 0 ptp4l[8405.072]: c3 0 ptp4l[8405.778]: negative path delay -10560 ptp4l[8405.778]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[8405.778]: t2 - t3 = -774949920 ptp4l[8405.778]: t4 - t1 = +774928800 ptp4l[8405.778]: c1 0 ptp4l[8405.778]: c2 0 ptp4l[8405.778]: c3 0 ptp4l[8406.003]: master offset -1637602062061072517 s2 freq -32767999 path delay -5784 ptp4l[8406.374]: negative path delay -4680 ptp4l[8406.374]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[8406.374]: t2 - t3 = -370912120 ptp4l[8406.374]: t4 - t1 = +370902760 ptp4l[8406.374]: c1 0 ptp4l[8406.374]: c2 0 ptp4l[8406.374]: c3 0 ptp4l[8406.885]: negative path delay -12120 ptp4l[8406.885]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[8406.885]: t2 - t3 = -881060360 ptp4l[8406.885]: t4 - t1 = +881036120 ptp4l[8406.885]: c1 0 ptp4l[8406.885]: c2 0 ptp4l[8406.885]: c3 0 ptp4l[8407.004]: master offset -1637602062061042610 s2 freq -32767999 path delay -6531 My config is: [global] # # Port Data Set # logAnnounceInterval 1 logSyncInterval 0 logMinDelayReqInterval 0 logMinPdelayReqInterval 0 announceReceiptTimeout 3 delayAsymmetry 0 fault_reset_interval 4 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 1 follow_up_info 0 tx_timestamp_retries 100 use_syslog 0 verbose 1 summary_interval 0 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_offset_const 0.0 clock_servo pi # # Default interface options # network_transport UDPv4 delay_mechanism E2E time_stamping hardware If I check the time (both date and hwclock) on both PCs, one says (for example) 10:12:11 and the other says 08:45:00. Even after an hour running ptp4l the time difference is the same. I think it got something to do with the clock frequency adjustment. I'm getting closer to success but what am I doing wrong now? Thanks, Benny -----Ursprüngliche Nachricht----- Von: Richard Cochran [mailto:ric...@gm...] Gesendet: Montag, 25. März 2013 19:20 An: Rapp, Tim-Benjamin Cc: lin...@li... Betreff: Re: [Linuxptp-users] can't get linux PTP to run On Mon, Mar 25, 2013 at 08:11:12AM +0000, Tim...@de... wrote: > Hi, > > well im using the modified driver from sourceforge (see post of Jake). > Therfore I only can use software timetamping, because HW-timespamps are not supported. If i dont use HW timestamping then I dont need to pick an /dev/ptp (I dont have one). Looking at the code, in e1000e-2.3.2.tar.gz, and in its README, HW time stamps *are* supported, but you need to add flag when building. IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC) ------------------------------------------------------------ Support for the IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC) is disabled by default in this out-of-tree driver even if it is enabled for the in-kernel driver. The feature is available only on a subset of devices supported by the driver, and can only be enabled on 3.0 and newer kernels that also have the PTP_1588_CLOCK support compiled in statically or as a module. To enable the feature when compiling the driver, add 'CFLAGS_EXTRA=-DE1000E_PTP' to the command line. > After your information I changed to using a config file. Did I do it like you ment? Adding the tx_timestamp_retries? I tried several different numbers. Always the same error. > > The command I use is: > ptp4l -i eht2 -f /etc/ptp4l.cfg > > the config is: > [global] > # > logging_level 6 > tx_timestamp_retries 100 > use_syslog 0 > verbose 1 > time_stamping software When using SW time stamping, the tx_timestamp_retries has no effect, since the time stamp is taken during the 'send' call. I can only suggest to recheck if: - you are really using the out-of-tree driver - that eth2 is really, truely serviced by the e1000e driver There is a Linux test program for time stamping in Documentation/networking/timestamping Can you test your interface with that program like so: timestamping eth2 SOF_TIMESTAMPING_TX_SOFTWARE SOF_TIMESTAMPING_RX_SOFTWARE SOF_TIMESTAMPING_SOFTWARE and post the results? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-03-25 18:20:51
|
On Mon, Mar 25, 2013 at 08:11:12AM +0000, Tim...@de... wrote: > Hi, > > well im using the modified driver from sourceforge (see post of Jake). > Therfore I only can use software timetamping, because HW-timespamps are not supported. If i dont use HW timestamping then I dont need to pick an /dev/ptp (I dont have one). Looking at the code, in e1000e-2.3.2.tar.gz, and in its README, HW time stamps *are* supported, but you need to add flag when building. IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC) ------------------------------------------------------------ Support for the IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC) is disabled by default in this out-of-tree driver even if it is enabled for the in-kernel driver. The feature is available only on a subset of devices supported by the driver, and can only be enabled on 3.0 and newer kernels that also have the PTP_1588_CLOCK support compiled in statically or as a module. To enable the feature when compiling the driver, add 'CFLAGS_EXTRA=-DE1000E_PTP' to the command line. > After your information I changed to using a config file. Did I do it like you ment? Adding the tx_timestamp_retries? I tried several different numbers. Always the same error. > > The command I use is: > ptp4l -i eht2 -f /etc/ptp4l.cfg > > the config is: > [global] > # > logging_level 6 > tx_timestamp_retries 100 > use_syslog 0 > verbose 1 > time_stamping software When using SW time stamping, the tx_timestamp_retries has no effect, since the time stamp is taken during the 'send' call. I can only suggest to recheck if: - you are really using the out-of-tree driver - that eth2 is really, truely serviced by the e1000e driver There is a Linux test program for time stamping in Documentation/networking/timestamping Can you test your interface with that program like so: timestamping eth2 SOF_TIMESTAMPING_TX_SOFTWARE SOF_TIMESTAMPING_RX_SOFTWARE SOF_TIMESTAMPING_SOFTWARE and post the results? Thanks, Richard |
|
From: <Tim...@de...> - 2013-03-25 08:11:23
|
Hi, well im using the modified driver from sourceforge (see post of Jake). Therfore I only can use software timetamping, because HW-timespamps are not supported. If i dont use HW timestamping then I dont need to pick an /dev/ptp (I dont have one). After your information I changed to using a config file. Did I do it like you ment? Adding the tx_timestamp_retries? I tried several different numbers. Always the same error. The command I use is: ptp4l -i eht2 -f /etc/ptp4l.cfg the config is: [global] # logging_level 6 tx_timestamp_retries 100 use_syslog 0 verbose 1 time_stamping software And I still get the same error than before: > ptp4l[98.033]: port 1: get_ts_info not supported > ptp4l[98.035]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[98.035]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[104.035]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[105.041]: recvmsg tx timestamp failed: Resource temporarily > unavailable > ptp4l[105.041]: port 1: send sync failed > ptp4l[105.041]: port 1: MASTER to FAULTY on FAULT_DETECTED > ptp4l[121.043]: port 1: FAULTY to LISTENING on FAULT_CLEARED > ptp4l[127.043]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[128.049]: recvmsg tx timestamp failed: Resource temporarily > unavailable Thanks, Benny -----Ursprüngliche Nachricht----- Von: Keller, Jacob E [mailto:jac...@in...] Gesendet: Dienstag, 19. März 2013 21:21 An: Rapp, Tim-Benjamin; lin...@li... Betreff: Re: [Linuxptp-users] can't get linux PTP to run Yes. You first of all need to determine which /dev/ptp device you are supposed to use. Can you show me the command you use to run ptp4l? Second, you may need to modify the config file to increase the tx_retries value in the config file (and pass that config to ptp4l's command option) Basically, the part may not be returning the tx timestamp on the socket fast enough. If you increase the tx_retries count to a fair bit higher that may resolve the particular error. - Jake > -----Original Message----- > From: Tim...@de... [mailto:Tim- > Ben...@de...] > Sent: Tuesday, March 19, 2013 1:42 AM > To: lin...@li... > Subject: Re: [Linuxptp-users] can't get linux PTP to run > > First of all thanks for your help. > > >There may be a kernel module released on sourceforge with support if > you don't need in-kernel driver, this should >work with the PTP > framework in 3.2 > > >http://sourceforge.net/projects/e1000/files/e1000e%20stable/ > > Now I have set up this driver and compiled it with PTP support but > there is nothing different than before still > > ptp4l[98.033]: port 1: get_ts_info not supported > ptp4l[98.035]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[98.035]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[104.035]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[105.041]: recvmsg tx timestamp failed: Resource temporarily > unavailable > ptp4l[105.041]: port 1: send sync failed > ptp4l[105.041]: port 1: MASTER to FAULTY on FAULT_DETECTED > ptp4l[121.043]: port 1: FAULTY to LISTENING on FAULT_CLEARED > ptp4l[127.043]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[128.049]: recvmsg tx timestamp failed: Resource temporarily > unavailable > > As you can see below that the new driver is working: > > ~$ ethtool -i eth2 > driver: e1000e > version: 2.3.2-NAPI > firmware-version: 2.1-2 > bus-info: 0000:07:00.0 > > changing the kernel to 3.5 or 3.9 would take a lot of time because a > lot of realtime support is bound into it. So I would prefer staying on 3.2. > > Is there something I still can try? > > Thanks, > Benny > > -----Ursprüngliche Nachricht----- > Von: Keller, Jacob E [mailto:jac...@in...] > Gesendet: Freitag, 15. März 2013 17:33 > An: Richard Cochran; Rapp, Tim-Benjamin > Cc: lin...@li... > Betreff: RE: [Linuxptp-users] can't get linux PTP to run > > > -----Original Message----- > > From: Richard Cochran [mailto:ric...@gm...] > > Sent: Friday, March 15, 2013 8:37 AM > > To: Tim...@de... > > Cc: lin...@li... > > Subject: Re: [Linuxptp-users] can't get linux PTP to run > > > > On Fri, Mar 15, 2013 at 01:24:16PM +0000, Tim- > > Ben...@de... wrote: > > > > > I'm using a custom x86 3.2.37 Kernel with Real Time support. I'm > > > using an "e1000e Intel 82574" with should be supported. > > > > The e1000e driver will have PHC and HW timestamping in kernel 3.9, > and > > it has SW time stamping as of kernel 3.5. So it is not supported on > > your kernel version. > > > > The easiest way to get going with your 3.2 kernel is to back port > > the SW time stamping patch. > > > > [ See the table of supported hardware at the linuxptp home page. ] > > > > HTH, > > Richard > > > > > > >There may be a kernel module released on sourceforge with support if > you don't need in-kernel driver, this should >work with the PTP > framework in 3.2 > > >http://sourceforge.net/projects/e1000/files/e1000e%20stable/ > > >- Jake > > ---------------------------------------------------------------------- > -------- Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics Download AppDynamics Lite > for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Keller, J. E <jac...@in...> - 2013-03-21 20:33:54
|
> -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Thursday, March 21, 2013 11:58 AM > To: Mozhdeh Kamel > Cc: lin...@li... > Subject: Re: [Linuxptp-users] List of Boundary clocks > > 2. Get a computer with true HW time stamping support. Note that you > cannot just use a box with multiple PCI cards, for example. The > ports must all share *one* clock. > > > HTH, > Richard > Also, just because the ports are on the same PCI card also does not mean they share a clock. You have to be sure the hardware supports a single clock for multiple ports. - Jake |
|
From: Richard C. <ric...@gm...> - 2013-03-21 18:58:41
|
On Thu, Mar 21, 2013 at 01:28:04PM +0100, Mozhdeh Kamel wrote: > > Can anyone help me with the list of boundary clocks?I wonder whether > boundary clocks are simple switch with hardware time stamping? what special > characteristics it must have? A boundary clock (BC) is more like a router than a switch. It must intercept incoming PTP messages, and it does not forward them (except for management messages). Although linuxptp is designed to work as a BC, I don't know of any that are using linuxptp. If you want to try the code out, then you need a computer with two or more ports, all of which share a common PTP Hardware Clock (PHC). I can think of two ways to do this. 1. Use a computer whose ports all support SW time stamping. This will not perform very well, but at least you can see how it works. 2. Get a computer with true HW time stamping support. Note that you cannot just use a box with multiple PCI cards, for example. The ports must all share *one* clock. Some ready made system on chips have this, like the Freescale P2020, the MPC8306, and the MPC8309. If you have one of these kits, then the ptp4l program should work fine. Another possibility is to use the DP83640 PHY, but you must make sure to connect the GPIOs in your design so that the PHYs can synchronize each other. HTH, Richard |
27 messages has been excluded from this view by a project administrator.
