Thanks for the ideas.

I've found one information regarding this switch on a different forum (https://www.xcore.com/viewtopic.php?p=35080&sid=f5377f21b0d593b77a4c5dbf44823298#p35080) - according to one user, for P2P to work over this switch, it might be required to connect a host CPU to the MII port. I don't quite understand why it should be a different port that would be creating the PDelay messages on regard of the downstream ports, but that would quite plausibly explain the behavior of the switch (but would not explain why the datasheet tells it can act as P2P TC, if it actually needs a linux computer next to it to gain this functionality).

Regarding the E2E sync problems, I've done the tests Miroslav suggested. Results are attached below. I don't see any difference in the sent/received PTP event messages except for the correction field. Yet the sync performance is still quite different, regardless of hardware or software timestamping.

PTP support in switch disabled:
===============================

Free-running:

ptp4l[4062.955]: rms 1198061538 max 1198063070 freq   +217 +/-  62 delay 38898 +/- 106 ptp4l[4079.014]: rms 1198064040 max 1198067020 freq   +235 +/- 2395 delay 38963 +/-  82 ptp4l[4095.073]: rms 1198068990 max 1198070394 freq   +216 +/-  37 delay 38910 +/-  74 ptp4l[4111.131]: rms 1198072621 max 1198074236 freq   +232 +/-  74 delay 38824 +/-  89 ptp4l[4127.190]: rms 1198076029 max 1198077365 freq   +193 +/-  77 delay 38829 +/-  56

Software timestamping:

ptp4l[86.569]: rms 1541288489 max 1541301491 freq     +0 +/-   0 delay 131269 +/-   0 ptp4l[87.572]: rms 1541277976 max 1541316025 freq     +0 +/-   0 delay 130847 +/-   0 ptp4l[88.575]: rms 1334792213 max 1541314255 freq  +1154 +/- 1619 delay 130369 +/-   0 ptp4l[89.579]: rms 44370 max 114055 freq  +1276 +/- 8280 delay 130847 +/-   0 ptp4l[90.582]: rms 37259 max 100715 freq  +3651 +/- 6675 delay 130847 +/-   0 ptp4l[91.586]: rms 45847 max 125267 freq  -2090 +/- 7701 delay 130387 +/-   0
ptp4l[92.589]: rms 4917 max 8677 freq  +1979 +/- 849 delay 130594 +/-   0
ptp4l[93.592]: rms 11095 max 22429 freq  +2975 +/- 1590 delay 130594 +/-   0
ptp4l[94.596]: rms 57863 max 117710 freq  -3202 +/- 9679 delay 130360 +/-   0

Hardware timestamping:

ptp4l[163.700]: rms 49504 max 99010 freq    +16 +/-  94 delay 39097 +/-   0
ptp4l[164.703]: rms   74 max  127 freq     +5 +/- 100 delay 39119 +/-   0
ptp4l[165.706]: rms   68 max  137 freq    +45 +/-  91 delay 39097 +/-   0
ptp4l[166.709]: rms  104 max  217 freq   +120 +/- 128 delay 39055 +/-   0
ptp4l[167.713]: rms  106 max  180 freq    +43 +/- 144 delay 39014 +/-   0
ptp4l[168.716]: rms   86 max  168 freq   +101 +/- 114 delay 38922 +/-   0
ptp4l[169.720]: rms  101 max  155 freq    +26 +/- 134 delay 39014 +/-   0

TShark dump on client (Type Correction Control Flags.TwoStep TransportSpecific VersionPTP)

Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
PDelay Req      0       5       0       0x00000001      2
PDelay Resp     0       5       1       0x00000001      2
PDelay FUP      0       5       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2

TShark dump on server (Type Correction Control Flags.TwoStep TransportSpecific VersionPTP)

Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
PDelay Req      0       5       0       0x00000001      2
PDelay Resp     0       5       1       0x00000001      2
PDelay FUP      0       5       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2


PTP support in switch enabled:
==============================

Free-running:

ptp4l[295.010]: rms 4673668 max 9236162 freq   -395 +/- 6141 delay 3064425 +/- 3221454 ptp4l[311.064]: rms 9847501 max 12174372 freq   -110 +/- 2296 delay 10608932 +/- 4087700 ptp4l[327.117]: rms 8342468 max 10464919 freq   +710 +/- 38749 delay 8047344 +/- 1985325 ptp4l[343.170]: rms 27539125 max 30509505 freq  +5248 +/- 16397 delay 26183736 +/- 6584428 ptp4l[359.223]: rms 31727865 max 46107661 freq  -5805 +/- 15737 delay 30336973 +/- 8869483 ptp4l[375.275]: rms 15872347 max 37921571 freq   +694 +/- 27436 delay 13233430 +/- 10128779 ptp4l[391.329]: rms 14712183 max 20936948 freq     -8 +/- 29317 delay 14550616 +/- 3062505

Software timestamping:

ptp4l[74.641]: rms 107901895 max 107930753 freq     +0 +/-   0 delay 5477811 +/-   0
ptp4l[75.644]: rms 107903065 max 107950258 freq     +0 +/-   0
ptp4l[76.647]: rms 93436214 max 107966965 freq +197623 +/- 255199 delay 5477811 +/-   0
ptp4l[77.650]: rms 316869 max 485854 freq +466526 +/- 22534
ptp4l[78.653]: rms 1737706 max 3595533 freq +228096 +/- 146025 delay 7188080 +/- 1109224 ptp4l[79.656]: rms 3547786 max 3688728 freq -153525 +/- 13044 delay 8297303 +/-   0 ptp4l[80.660]: rms 4003255 max 6936867 freq -217926 +/- 221838 delay 11914188 +/-   0 ptp4l[81.664]: rms 6222892 max 6823543 freq -657257 +/- 245710 delay 8320723 +/-   0 ptp4l[82.668]: rms 2598023 max 2691956 freq -21288 +/- 10346 delay 8320723 +/-   0 ptp4l[83.670]: rms 2925169 max 4719644 freq -75054 +/- 134955 delay 10482304 +/-   0 ptp4l[84.674]: rms 4260589 max 4764434 freq -283324 +/- 326060 delay 5421826 +/-   0

Hardware timestamping:

ptp4l[224.019]: rms 736603 max 1344727 freq -2360881 +/- 1001302 delay 15169169 +/-   0 ptp4l[225.023]: rms 1122144 max 1174407 freq  +9409 +/- 364867 delay 15169169 +/-   0 ptp4l[226.028]: rms 783320 max 973505 freq +559982 +/- 74436 delay 15169169 +/-   0 ptp4l[227.032]: rms 350975 max 493788 freq +153717 +/- 433255 delay 15810972 +/-   0 ptp4l[228.037]: rms 289297 max 404680 freq -120141 +/- 396286 delay 15317557 +/-   0 ptp4l[229.041]: rms 500916 max 1034595 freq -124871 +/- 698773 delay 16407699 +/-   0 ptp4l[230.045]: rms 1356042 max 2875705 freq -1738250 +/- 1526266 delay 19233951 +/-   0 ptp4l[231.050]: rms 891558 max 1785442 freq -2328719 +/- 837949 delay 19233951 +/-   0 ptp4l[232.054]: rms 1520751 max 3074557 freq -1595725 +/- 2112171 delay 23153302 +/-   0

TShark dump on client (Type Correction Control Flags.TwoStep TransportSpecific VersionPTP)

Sync Message    1460    0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    1460    0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
PDelay Req      0       5       0       0x00000001      2
PDelay Resp     1524    5       1       0x00000001      2
PDelay FUP      1500    5       0       0x00000001      2
Sync Message    1460    0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    1460    0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    1460    0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2

TShark dump on server (Type Correction Control Flags.TwoStep TransportSpecific VersionPTP)

Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
PDelay Req      1500    5       0       0x00000001      2
PDelay Resp     0       5       1       0x00000001      2
PDelay FUP      1500    5       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2
Sync Message    0       0       1       0x00000001      2
Follow_Up       0       2       0       0x00000001      2



Dne 27. 06. 22 v 10:27 Miroslav Lichvar napsal(a):

On Fri, Jun 24, 2022 at 03:50:46PM +0200, Martin Pecka wrote:
38000 ns. But when I turn filling the corrections on, it seems linuxptp is
really struggling to understand what is going on. The master offset always
oscillates in the order of millions, as well as the estimated path delay.
What can be a reason for this happening? I'm testing this with default.cfg,
and also with our customized "Automotive profile with E2E delay mechanism".
Both behave the same in this regard. The testing setup consists of two
computers connected via the switch, each computer having a
hardware-timestamping-capable NIC.
Interesting issue. To me that sounds like a synchronization loop, e.g.
the server or the switch is somehow synchronizing to the client.

If you compare packet captures with the TC disabled and enabled, is
the only difference in the correction field? On both the server and
client side?

Can you try it with software timestamping and also the free-running
mode?

The only idea I came with is that the computers are two-step clocks, while
the switch behaves as one-step clock. But I thought this does not matter to
the PTP protocol.
That shouldn't matter. The switch should forward unmodified follow-up
messages.


Attachment: smime.p7s
Description: Elektronicky podpis S/MIME

_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Reply via email to