On 19/10/23 14:51, Miroslav Lichvar wrote:
On Thu, Oct 19, 2023 at 02:40:30PM +0200, Nils Fuerste wrote:
ptp4l[2023/10/19/12:28:10]: state=2 rms 222 max 518 freq +1020 +/- 0
delay 20436 +/- 13
ptp4l[2023/10/19/12:28:11]: state=2 rms 968245340 max 999999669 freq +992
+/- 0 delay 20507 +/- 36
ptp4l[2023/10/19/12:28:13]: state=2 rms 433012546 max 999999740 freq +921
+/- 28 delay 20559 +/- 31
Those errors are almost exactly 1 second, which is very suspicious. It
could be a driver bug. What kernel version do you use? It would help
if you could get a third device and see if it works better as a server
or client to determine on which side is the problem.
As proposed I have tested some other scenarios. During this process I
have realized that the PTP version on the embedded device is probably
not mainline. I have copied the config to another machine with mainline
PTP and it was complaining about many parameters in the PTP client
config of the embedded device.
I have used some other configuration to narrow down the issue. These are
the results:
- Using other master, same client, same configs -> Same result
- Using other master, other client with config from embedded device ->
Results are worse than before (I had to comment out some config items
that were not recognized by ptp4l.
- Using a proper PTP GM (Qulsar Q2), original client (embedded device)
-> Good sync, around rms 20 +- 5
- I have tested different SFP to Ethernet adapters in all of those tests
above, sync quality stayed the same
What can I do? Since a proper PTP GM can provide a good PTP sync to the
client I guess my config is faulty? Or can it be something else? Can I
maybe do some more tests?
Many thanks!
Nils
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
