Thread: Re: [Linuxptp-users] can't get linux PTP to run
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
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-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: 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: <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: 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-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-09 10:39:29
|
On Tue, Apr 09, 2013 at 07:09:40AM +0000, Tim...@de... wrote: > 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[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 So your PTP Hardware Clock is synchronized to within about +- 100 nanoseconds. This is good, and it is also the expected performance. > 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 Okay, so what you show here is produced by a user program, and the result is in fact quite typical and expected, in my experience. > I know that there is time "lost" during the measurement with an C program but it should not be that much. Getting this output to jitter +- 25 usec is really pretty good, even for RT_PREEMPT Linux. The jitter is caused by latencies within the OS, like interrupts, scheduling latency, and so forth. It has nothing (or very little) to do with the PTP clock. There are ways to try and improve on this result, but that is really off topic for this list. You might want to try the linux-rt-users mailing list. One common way to accomplish what you are trying to do is: 1. measure the worst case scheduling latency by using the cyclictest program under heavy load, over a long period of time. 2. run your task at the highest priority 3. set the timer to expire before your deadline, a bit more than the worst case scheduling latency. 4. after waking up, do a busy wait until the deadline, before setting the IO pin. HTH, Richard |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X