Re: [Linuxptp-users] can't get linux PTP to run

[<Tim...@de...>]

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