Re: [Linuxptp-devel] Two ptp4l processes working on the same network interface
On Wed, Mar 15, 2023 at 01:14:50PM +0200, Kamil Zaripov wrote: > The issue is ptp4l does not support out of the box creating two > ports on the same network interfaces with different > network_transport configuration values. I want to discuss how > linuxptp code can be patched so user can do such thing? I think this can be pretty simple. Allow interface names like: eth0 eth0:foo eth0:bar Then simply drop :xyz suffix when actually calling the ioctl. The only difficulty is sanity checking that: - At most one UDPv4 and one UDPv6 are present. - The inferface supports HWTSTAMP_FILTER_PTP_V2_EVENT. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v1] ntpshm: Invalidate SHM data before releasing the servo
On 15/03/2023 13:51, Miroslav Lichvar wrote: > On Wed, Mar 15, 2023 at 12:55:56PM +0100, Maciek Machnikowski wrote: >> The SHM is not cleared upon servo release when exiting the tool. This leaves >> the last update in the shared memory region marked as valid. As a result, the >> NTP daemon starting later may consume stale data if the producer process >> exited. >> >> To prevent such behavior - invalidate the SHM data when releasing the SHM >> servo. > > It probably doesn't matter much either way, but this doesn't seem > right to me. The sample stays valid after ptp4l/phc2sys exited. There > is a timestamp when the measurement was made. It's up to the consumer > to check if it's still acceptable. > It depends on why you terminated the process. If you start the synchronization process and see that it doesn't work correctly then, this cleanup will prevent leaving invalid timestamps in memory. If timestamps were correct, it doesn't matter only as long as no one else touches the clocks. If the NTP process restarts, gets the time from a different source, and returns to the stale timestamp (which will sit in memory forever) it may incorrectly interpret this value as the right one. It also may backfire on embedded systems that stop the clock when going to sleep. After resuming, the value kept in there will be incorrect as well. > The same situation happens when the servo stops due the port switching > to another PTP state without exiting. The last sample was made when > the source clock was considered synchronized and it can be used for > synchronization of the system clock. > Here we are a bit safer, as that's (theoretically) a transitional state, and the "fundamental" system configuration shouldn't change while it happens. Regards, Maciek ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v1] ntpshm: Invalidate SHM data before releasing the servo
On Wed, Mar 15, 2023 at 12:55:56PM +0100, Maciek Machnikowski wrote: > The SHM is not cleared upon servo release when exiting the tool. This leaves > the last update in the shared memory region marked as valid. As a result, the > NTP daemon starting later may consume stale data if the producer process > exited. > > To prevent such behavior - invalidate the SHM data when releasing the SHM > servo. It probably doesn't matter much either way, but this doesn't seem right to me. The sample stays valid after ptp4l/phc2sys exited. There is a timestamp when the measurement was made. It's up to the consumer to check if it's still acceptable. The same situation happens when the servo stops due the port switching to another PTP state without exiting. The last sample was made when the source clock was considered synchronized and it can be used for synchronization of the system clock. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH v1] ntpshm: Invalidate SHM data before releasing the servo
The SHM is not cleared upon servo release when exiting the tool. This leaves
the last update in the shared memory region marked as valid. As a result, the
NTP daemon starting later may consume stale data if the producer process
exited.
To prevent such behavior - invalidate the SHM data when releasing the SHM servo.
Signed-off-by: Maciek Machnikowski
---
ntpshm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ntpshm.c b/ntpshm.c
index 3b62a3f..6453ac4 100644
--- a/ntpshm.c
+++ b/ntpshm.c
@@ -69,6 +69,9 @@ static void ntpshm_destroy(struct servo *servo)
{
struct ntpshm_servo *s = container_of(servo, struct ntpshm_servo,
servo);
+ /* Invalidate the SHM data before exiting */
+ s->shm->valid = 0;
+
shmdt(s->shm);
free(s);
}
--
2.37.1 (Apple Git-137.1)
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] Two ptp4l processes working on the same network interface
I have a setup where a local network has host with both IEEE 802.3 & UDP PTP slaves and linux host that should run as PTP master. I used to run two ptp4l processes (one with -2 argument and another one with -4 argument) on the master host, but my network card cannot simultaneously timestamp several outgoing packages. So sometimes they race with each other for tx timestamp resources and one of them get timeout waiting for tx timestamp. I have asked what can I do with this issue in linuxptp-users@ mailing list and got an answer from Richard that you can launch one ptp4l process that serves both IEEE 802.3 and UDP PTP slaves. The issue is ptp4l does not support out of the box creating two ports on the same network interfaces with different network_transport configuration values. I want to discuss how linuxptp code can be patched so user can do such thing? I have a dirty solution where I add some suffix to the interface name in configuration file just to create several independent interfaces in configs, but It has several drawbacks. I think that there must be a better solution. Cheers, Zaripov Kamil.___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH] port: Don't switch to PHC with SW timestamping.
When ptp4l was configured to use SW timestamping, but the interface
supported also HW timestamping, ptp4l detected a change of the PHC on
start, switched to it from the system clock, and tried to control the
PHC using SW timestamps.
Don't switch the PHC if the current PHC index is -1, which is expected
with SW timestamping and in the free-running mode.
Fixes: afeabf3c90ed ("ptp4l: add VLAN over bond support")
Signed-off-by: Miroslav Lichvar
---
port.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/port.c b/port.c
index 3453716..9746df8 100644
--- a/port.c
+++ b/port.c
@@ -2765,6 +2765,7 @@ static void port_change_phc(struct port *p)
/* Try to switch only if the interface is up, it has HW time stamping
using a non-vclock PHC, and the PHC actually changed. */
if (!(p->link_status & LINK_UP) ||
+ p->phc_index < 0 ||
!interface_tsinfo_valid(p->iface) ||
interface_get_vclock(p->iface) >= 0 ||
interface_phc_index(p->iface) < 0 ||
--
2.39.2
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Add option to bind raw and UDP sockets to interface
> On 15 Mar 2023, at 01:55, Vladimir Oltean wrote: > > What will happen if the bridge floods the frame to 2 bridge ports, and > both supports hardware TX timestamping? How many TX timestamps will be > collected by the kernel, and more importantly, which ones? How many of > those will be delivered to user space? Is ptp4l prepared to process more > than one hardware TX timestamp per sent packet? Yes, this is good question and now I see that this changes will not work in general case. We can drop this patch. Regards, Zaripov Kamil___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH] phc2sys: Add multi-domain synchronization.
Hi Miroslav, I tested this patch and it looks good! Basic redundancy works too: line 25 - ens1f0 goes to LISTENING, line 29 - ens1f1 is selected line 44 - ens1f0 goes to SLAVE, line 48 - ens1f0 is selected Log: 5 sh-4.4# /usr/sbin/phc2sys -a -r -n 24 -u 8 -m -z /var/run/ptp4l.0.socket -z /var/run/ptp4l.1.socket 6 phc2sys[10030.934]: reconfiguring after port state change 7 phc2sys[10030.934]: selecting ens1f0 as domain source clock 8 phc2sys[10030.934]: selecting ens1f1 as domain source clock 9 phc2sys[10030.934]: selecting ens1f0 as out-of-domain source clock 10 phc2sys[10037.935]: CLOCK_REALTIME rms 31292 max 62598 freq +29808 +/- 11 delay 516 +/- 4 11 phc2sys[10045.935]: CLOCK_REALTIME rms7 max 14 freq +29812 +/- 6 delay 512 +/- 2 12 phc2sys[10053.936]: CLOCK_REALTIME rms 12 max 18 freq +29812 +/- 11 delay 514 +/- 4 13 phc2sys[10061.937]: CLOCK_REALTIME rms6 max 13 freq +29813 +/- 5 delay 516 +/- 5 14 phc2sys[10069.938]: CLOCK_REALTIME rms 10 max 17 freq +29813 +/- 8 delay 520 +/- 3 15 phc2sys[10077.938]: CLOCK_REALTIME rms8 max 15 freq +29816 +/- 7 delay 522 +/- 2 16 phc2sys[10085.939]: CLOCK_REALTIME rms8 max 14 freq +29815 +/- 7 delay 516 +/- 3 17 phc2sys[10093.940]: CLOCK_REALTIME rms4 max9 freq +29811 +/- 3 delay 517 +/- 4 18 phc2sys[10101.941]: CLOCK_REALTIME rms 10 max 17 freq +29813 +/- 9 delay 521 +/- 3 19 phc2sys[10109.941]: CLOCK_REALTIME rms 10 max 13 freq +29809 +/- 9 delay 516 +/- 6 20 phc2sys[10117.942]: CLOCK_REALTIME rms 11 max 23 freq +29814 +/- 9 delay 521 +/- 2 21 phc2sys[10125.943]: CLOCK_REALTIME rms7 max 13 freq +29813 +/- 7 delay 520 +/- 4 22 phc2sys[10133.944]: CLOCK_REALTIME rms 11 max 17 freq +29808 +/- 9 delay 521 +/- 4 23 phc2sys[10141.944]: CLOCK_REALTIME rms8 max 12 freq +29811 +/- 7 delay 522 +/- 4 24 phc2sys[10149.945]: CLOCK_REALTIME rms 10 max 24 freq +29806 +/- 9 delay 513 +/- 2 25 phc2sys[10155.946]: port ac1f6b.fffe.e17d12-1 changed state 26 phc2sys[10155.946]: reconfiguring after port state change 27 phc2sys[10155.946]: selecting ens1f0 for synchronization 28 phc2sys[10155.946]: selecting ens1f1 as domain source clock 29 phc2sys[10155.946]: selecting ens1f1 as out-of-domain source clock 30 phc2sys[10157.946]: CLOCK_REALTIME rms8 max 15 freq +29808 +/- 8 delay 516 +/- 4 31 phc2sys[10162.947]: ens1f0 rms6 max 12 freq +467 +/- 5 delay 2439 +/- 5 32 phc2sys[10165.947]: CLOCK_REALTIME rms3 max4 freq +29808 +/- 2 delay 516 +/- 4 33 phc2sys[10170.948]: ens1f0 rms 13 max 23 freq +467 +/- 12 delay 2449 +/- 45 34 phc2sys[10173.948]: CLOCK_REALTIME rms5 max9 freq +29806 +/- 5 delay 516 +/- 5 35 phc2sys[10178.949]: ens1f0 rms6 max 10 freq +468 +/- 5 delay 2473 +/- 87 36 phc2sys[10181.949]: CLOCK_REALTIME rms7 max 13 freq +29808 +/- 6 delay 515 +/- 4 37 phc2sys[10186.950]: ens1f0 rms 10 max 15 freq +469 +/- 9 delay 2464 +/- 69 38 phc2sys[10189.950]: CLOCK_REALTIME rms5 max 11 freq +29804 +/- 5 delay 514 +/- 2 39 phc2sys[10194.951]: ens1f0 rms9 max 18 freq +464 +/- 6 delay 2442 +/- 7 40 phc2sys[10197.951]: CLOCK_REALTIME rms4 max8 freq +29805 +/- 4 delay 513 +/- 2 41 phc2sys[10200.953]: port ac1f6b.fffe.e17d12-1 changed state 42 phc2sys[10200.953]: reconfiguring after port state change 43 phc2sys[10200.953]: master clock not ready, waiting... 44 phc2sys[10201.953]: port ac1f6b.fffe.e17d12-1 changed state 45 phc2sys[10201.953]: reconfiguring after port state change 46 phc2sys[10201.954]: selecting ens1f0 as domain source clock 47 phc2sys[10201.954]: selecting ens1f1 as domain source clock 48 phc2sys[10201.954]: selecting ens1f0 as out-of-domain source clock 49 phc2sys[10205.954]: CLOCK_REALTIME rms9 max 17 freq +29806 +/- 9 delay 514 +/- 2 50 phc2sys[10213.955]: CLOCK_REALTIME rms 15 max 29 freq +29805 +/- 13 delay 516 +/- 4 51 phc2sys[10221.955]: CLOCK_REALTIME rms7 max 15 freq +29807 +/- 6 delay 522 +/- 2 Thanks, Vitaly ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
