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

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

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