[Linuxptp-users] The List Has Moved

2023-12-06 Thread Richard Cochran 
Dear LinuxPTP Users,

New posts to this list has been disabled.  If you want to continue to
participate on the mailing lists, please subscribe to the new list at
the Network Time Foundation.

https://lists.nwtime.org/sympa/info/linuxptp-users

Thanks,
Richard


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

Re: [Linuxptp-users] Wrong source IP Address in Multicast

2023-12-06 Thread gntech hweng 
Any ideas as to why the patch previously posted was necessary to resolve
the incorrect source IP address in multicast packets?  Is this more
appropriate for the development list?  I posted here based on
https://lists.nwtime.org/sympa/info/linuxptp-users.

Thank you,
gthweng

On Mon, Dec 4, 2023 at 3:08 PM geontech hweng  wrote:

> Hi everyone,
>
> I am standing up PTP between an Ubuntu 20.04 system (server) and the 1GbE
> PS interface of an AMD Ultrascale+ MPSoC board (client).  The client has
> PTP enabled as part of the Petalinux build v3.1.1.  On the Ubuntu host,
> v3.1.1 was built from source and installed because v1.9.2 that is packaged
> for 20.04 has published vulnerabilities.  Tests were performed with the
> systems connected using a small desktop switch and connected directly.  In
> both cases, the interfaces are configured for static IP addresses and the
> interfaces of both systems have multicast enabled.  The client never prints
> anything beyond the following.
>
> ```bash
> sudo ptp4l -i eth0 --slaveOnly=1 -m --tx_timestamp_timeout=10
> Password:
> ptp4l[6063.829]: selected /dev/ptp0 as PTP clock
> ptp4l[6063.830]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[6063.830]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[6066.310]: port 1: new foreign master f4939f.fffe.f45b6d-1
> ptp4l[6070.310]: selected best master clock f4939f.fffe.f45b6d
> ```
> The command used on the Ubuntu server is 'sudo ptp4l -i eno1
> --masterOnly=1 -m --logSyncInterval=-3 --tx_timestamp_timeout=10"
>
> Using wireshark and tcpdump, we have ascertained that the source IP
> address for the multicast packets from the server contains the IP address
> for another interface of the Ubuntu system.  The source IP address is
> incorrect.  During the investigation, we discovered a post on this list is
> 2017 that described the same issue and included a patch that fixed the
> issue.  The post is titled "Wrong Interface" and was posted on 017-06-22
> 20:59:12.  The links to the original message and patch are below.
>
> https://sourceforge.net/p/linuxptp/mailman/message/35907900/
>
> https://sourceforge.net/p/linuxptp/mailman/attachment/CAP6mCQSva38taSYXvXZaW2JoQ2YzZxfk3scM8QfYMxDFjqg68g%40mail.gmail.com/1/
>
> Application of the changes in the patch corrected the issue for v3.1.1 on
> the Ubuntu system.  The client now converges to sub-100ns rms offsets with
> HWTS enabled on both systems.  A comparison of udp.c for v3.1.1 and v4.1
> indicates that nothing was changed to address this behavior in the most
> recent release.  Do you consider this an issue?  If yes, will it be
> corrected?  If not, how do you recommend that users mitigate this issue?
>
> Thank you!
>
> gthweng
>
>
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] Multi-profile grandmaster

2023-12-06 Thread Miroslav Lichvar 
On Wed, Dec 06, 2023 at 08:19:49AM +, Erling Rennemo Jellum wrote:
> We are in the situation where we want to synchronize multiple devices where 
> some only support the E2E delay mechanism and others only support the P2P 
> delay mechanism (the gPTP profile specifically). Ideally, we would just use a 
> single network interface on the grandmaster. See below for a Figure 
> illustrating a possible topology. It would mean that the GM should exchange 
> Peer Delay messages with the switch (which is a Transparent Clock), while 
> also replying to Delay Request messages from the E2E slave, and sending out 
> Sync+Follow Up to both the E2E and the P2P slave.
> 
> Has anyone looked into this before? I guess it would be possible with two 
> isolated networks and two instances of linuxPTP operating on two different 
> network interfaces, but can it work on a single network?

>From the PTP point of view it could work with two different PTP domain
numbers. The GM can run multiple ptp4l instances. They can even share
the same PHC, no need for vclocks.

But practically I think it will depend on the switch whether it can be
configured for such operation.

-- 
Miroslav Lichvar



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

[Linuxptp-users] Multi-profile grandmaster

2023-12-06 Thread Erling Rennemo Jellum 
Hi all.

We are in the situation where we want to synchronize multiple devices where 
some only support the E2E delay mechanism and others only support the P2P delay 
mechanism (the gPTP profile specifically). Ideally, we would just use a single 
network interface on the grandmaster. See below for a Figure illustrating a 
possible topology. It would mean that the GM should exchange Peer Delay 
messages with the switch (which is a Transparent Clock), while also replying to 
Delay Request messages from the E2E slave, and sending out Sync+Follow Up to 
both the E2E and the P2P slave.

Has anyone looked into this before? I guess it would be possible with two 
isolated networks and two instances of linuxPTP operating on two different 
network interfaces, but can it work on a single network?

Thanks for any suggestions.
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users