Hi Patrick, > On Jul 25, 2020, at 9:53 AM, Patrick Nowak <patrick.no...@nordsys.de> wrote: > > Hi Axel and Richard, > > thank you for your replies! > > Huh, good question. Our setup includes four machines, all using NICs with > IEEE 1588 capable chips. The little switch that connects all the machines is > not capable to my knowledge, but the LAN is exclusively used for PTP > synchronization. Could this still be a problem? >
Yes. A switch that is not a transparent clock will not update the correction field of PTP messages, meaning that the time that each packet resides inside the switch will not be accounted for. If you’re looking for synchronization to a few 10µs then that is good enough. If you want <1µs accuracy, you need to get a switch that is a transparent clock. Note that there is E2E PTP where the switch just update the correction fields and P2P PTP where the switch synchronizes an internal clock and synchronizes with the nodes on each port individually. I assume you’re using E2E. > Before we were evaluating a Windows host as the PTP Master, a machine with > linuxptp was declared as the master through the algorithm. With the new PTP > Master on the Windows machine all the other machines running linuxptp are > slave-only. The only difference I can see is, that the PTP Master seems to be > broadcasting the PTP multicasts to all NICs. This includes a NIC that is > connected to another LAN that we’re using for data transfer. All the other > nodes are also connected tot hat LAN, but configured through linuxptp to only > use the NIC that is connected to the PTP LAN. > > Could this also be an issue that the master seems to broadcast the PTP > messages to all connected LANs? No, it should not be an issue. The master is supposed to use broadcast packets (multicast, actually, but dumb switches will treat that as broadcast). Cheers, Axel > > Best regards, > Patrick > > Von: Axel Simon <axelsi...@waymo.com <mailto:axelsi...@waymo.com>> > Gesendet: Mittwoch, 22. Juli 2020 15:27 > An: Patrick Nowak <patrick.no...@nordsys.de <mailto:patrick.no...@nordsys.de>> > Cc: linuxptp-users@lists.sourceforge.net > <mailto:linuxptp-users@lists.sourceforge.net> > Betreff: Re: [Linuxptp-users] Problems syncing linuxptp slaves with Domain II > Time GM > > Hi Patrick, > > the time received by ptp4l is wobbling. This could just be the effect of a > network switch that is not a transparent clock and thereby delays some PTP > packets more than others. You can try to connect the master and the slave > directly to see if this problem goes away. > > Cheers, > Axel > > > On Jul 22, 2020, at 1:13 AM, Patrick Nowak <patrick.no...@nordsys.de > <mailto:patrick.no...@nordsys.de>> wrote: > > Hello, > > we are currently evaluating the usage of the Greyware Domain II Time software > server as a GM in our small local network. We have a seperate LAN with four > nodes. One machine is running Windows and should act as a GM, getting time > from NTP and serving the time via PTP. The other three nodes run linuxptp > with the standard configuration. All nodes use NICs with IEEE 1588 support. > > The ptp4l on all nodes currently shows a frequently jumping master offset and > frequency. Sometimes a message like „running in a temporal vortex" appears. > An example from the syslog for the jumping values: > > Jul 22 10:02:50 machine1 ptp4l: [1691104.796] [0:eno1] master offset > -91671 s2 freq -57292 path delay 185856 > Jul 22 10:02:51 machine1 ptp4l: [1691105.695] [0:eno1] master offset > -43204 s2 freq -36326 path delay 168982 > Jul 22 10:02:52 machine1 ptp4l: [1691106.596] [0:eno1] master offset > 54956 s2 freq +48873 path delay 168982 > Jul 22 10:02:53 machine1 ptp4l: [1691107.496] [0:eno1] master offset > -42141 s2 freq -31737 path delay 168982 > Jul 22 10:02:54 machine1 ptp4l: [1691108.396] [0:eno1] master offset > 120684 s2 freq +118445 path delay 168982 > Jul 22 10:02:55 machine1 ptp4l: [1691109.296] [0:eno1] master offset > -181193 s2 freq -147226 path delay 168982 > Jul 22 10:02:56 machine1 ptp4l: [1691110.196] [0:eno1] master offset > 47053 s2 freq +26662 path delay 168982 > Jul 22 10:02:57 machine1 ptp4l: [1691111.096] [0:eno1] master offset > 35055 s2 freq +28780 path delay 168982 > Jul 22 10:02:57 machine1 ptp4l: [1691111.996] [0:eno1] master offset > 80957 s2 freq +85198 path delay 168982 > Jul 22 10:02:58 machine1 ptp4l: [1691112.896] [0:eno1] master offset > -73222 s2 freq -44694 path delay 168982 > Jul 22 10:02:59 machine1 ptp4l: [1691113.797] [0:eno1] master offset > -35597 s2 freq -29035 path delay 168982 > > It seems that the nodes are communicating the network. I’ve also added a PCAP > file of the PTP traffic. > > I am currently not really sure whats going on here or what to look for. Does > anybody with a little bit more knowledge of PTP/IEEE 1588 have any ideas as > to what I could further debug or change in either configurations? > > Best regards, > Patrick > > > <ptp.pcap.pcapng>_______________________________________________ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > <mailto:Linuxptp-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > <https://lists.sourceforge.net/lists/listinfo/linuxptp-users> > > _______________________________________________ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > <mailto:Linuxptp-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > <https://lists.sourceforge.net/lists/listinfo/linuxptp-users>
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
