Am 03.12.18 um 22:41 schrieb Keller, Jacob E:
-----Original Message-----
From: Thomas Behn [mailto:thomas.b...@meinberg.de]
Sent: Monday, December 03, 2018 11:31 AM
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] PHC delay when calling clock_gettime
Hi everyone,
While developing a PTP slave using the Linux PHC, I noticed, that everytime I
call
clock_gettime with the PHC ID, the time on the PHC jumps or at least changes by
around 200-300ns. I noticed this, because I have implemented an algorithm
reading
the PHC time ten times in a row to find a best possible assumption of the
offset to the
system time (as done in Ohly's timecompare). The second before the ten
readings, my
measured PTP offset is a few ns, while directly after the readings it is around
2.5us.
The offset is stable below 200ns when not reading the PHC and leaving the system
time unsynchronized.
Just for further information, this is an excerpt of the linuxptp output.
phc2sys has been started before 288.414 and stopped before 302.415.
ptp4l[280.414]: master offset 43 s2 freq +14385 path delay 787
ptp4l[281.414]: master offset -2 s2 freq +14353 path
delay 791
ptp4l[282.414]: master offset -42 s2 freq +14312 path
delay 791
ptp4l[283.414]: master offset -39 s2 freq +14302 path
delay 791
ptp4l[284.414]: master offset -35 s2 freq +14295 path
delay 788
ptp4l[285.414]: master offset -19 s2 freq +14300 path
delay 788
ptp4l[286.414]: master offset -26 s2 freq +14288 path
delay 792
ptp4l[287.414]: master offset -30 s2 freq +14276 path
delay 793
ptp4l[288.414]: master offset -1523 s2 freq +12774 path
delay 793
ptp4l[289.414]: master offset -1340 s2 freq +12500 path
delay 793
ptp4l[290.414]: master offset -907 s2 freq +12531 path
delay 793
ptp4l[291.414]: master offset -510 s2 freq +12656 path
delay 793
ptp4l[292.414]: master offset -204 s2 freq +12809 path
delay 792
ptp4l[293.414]: master offset -149 s2 freq +12803 path
delay 792
ptp4l[294.414]: master offset 37 s2 freq +12944 path
delay 773
ptp4l[295.414]: master offset -32 s2 freq +12886 path
delay 773
ptp4l[296.415]: master offset -3 s2 freq +12905 path
delay 733
ptp4l[297.415]: master offset -75 s2 freq +12832 path
delay 729
ptp4l[298.415]: master offset -34 s2 freq +12851 path
delay 713
ptp4l[299.415]: master offset -45 s2 freq +12830 path
delay 713
ptp4l[300.415]: master offset -59 s2 freq +12802 path
delay 711
ptp4l[301.415]: master offset 40 s2 freq +12884 path
delay 711
ptp4l[302.415]: master offset 1445 s2 freq +14301 path
delay 644
ptp4l[303.415]: master offset 1371 s2 freq +14660 path
delay 644
ptp4l[304.415]: master offset 955 s2 freq +14655 path
delay 647
ptp4l[305.415]: master offset 435 s2 freq +14422 path
delay 729
ptp4l[306.415]: master offset 216 s2 freq +14333 path
delay 749
ptp4l[307.415]: master offset 121 s2 freq +14303 path
delay 755
ptp4l[308.415]: master offset 22 s2 freq +14240 path
delay 788
That seems like a bug in either the driver implementation, or in the hardware.
Might be. I am not using own hardware, though. I saw this behaviour on a
desktop PC running Linux Mint 19 (Kernel 4.15.0-38-generic) with onboard
Intel 82579V (rev 05) NIC as well as on a similar system running
openSUSE Leap 42.1 (Kernel 4.1.39-56-default) with the same NIC. Maybe
this is a problem with that specific ethernet controller?
I just found out, that I am not seeing it on my HP notebook running
Ubuntu 18.10 (Kernel 4.18.0-12-generic) with Intel I219-V (rev 21) NIC.
All of the NICs are using the Intel e1000e driver.
While trying to find the mistake in my implementation, I found out that the same
thing happens if I use linuxptp and phc2sys. As long as phc2sys is not running,
linuxptp
reports a pretty stable offset below 200ns, but as soon as I start phc2sys, the
offset
increases to about 1us for a short time and is corrected by linuxptp a few
seconds
later. Stopping phc2sys again results in the same behaviour, now with -1us
offset.
From what I have seen in the code of phc2sys, it reads the PHC only five times
in a
row, which explains that the offset is only 1us, compared to my 2.5us.
phc2sys is likely to call gettime at least once, so this I think is the same
problem as above.
My conclusion is, that each call of clock_gettime with the PHC ID, delays the
time of
the clock by around 200-300ns. Is this a bug or expected behaviour? Or am I
doing
something wrong?
I suggest you read your hardware spec sheet and see if somehow reading the
clock time causes it to be paused? That, or you've got something weird going on
in your gettime implementation.
Unfortunately, none of us on the list are going to be experts in your hardware
or software. I would be incredibly surprised if this was a bug in linuxptp or
the PTP kernel subsystem.
So would I. But as I am not using own hardware or software and am seeing
it on different systems, I would also be surprised if it was something
on my side.
Thanks in advance for your help!
Good luck!
Thanks, my temporary solution is to always read the clock ten times per
second (even if not needed at all).
This leads to the delay arising from the clock readings being included
in my frequency offset calculation/correction.
Works fine.
Regards,
Jake
Best Regards,
Thomas
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
