[Linuxptp-users] Restoring unicast grants?
I was doing some testing on my network of 50 devices and wanted to see how the network responded to a flood of broadcast packets (need my solution to be robust to things like this - floods are not likely but high bandwidth usage is). Jitter / lack of good sync was an expected result, but after I stopped the flood test I noticed some of the slave ptp4l processes were no longer syncing at all. I looked back through the logs and saw this: port 1 (eno1): server unilaterally canceled unicast ANNOUNCE grant port 1 (eno1): server unilaterally canceled unicast ANNOUNCE grant port 1 (eno1): server unilaterally canceled unicast DELAY_RESP grant port 1 (eno1): server unilaterally canceled unicast DELAY_RESP grant port 1 (eno1): server unilaterally canceled unicast SYNC grant port 1 (eno1): server unilaterally canceled unicast SYNC grant After this, no further syncing was done and the ptp4l client just sat idle. Is there anything I can do to make sure these clients re-attempt to establish sync with the unicast master? I can of course monitor the output for messages like this and restart the process.. but I'm hoping maybe there's a configuration option? or perhaps a place in the code I can patch to get the behavior I'm wanting? Thanks, Trey ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Fwd: First delay request message on GM failure
On Tue, Sep 05, 2023 at 04:45:14AM +0530, Karthick Gunasekaran via Linuxptp-users wrote: > Kindly let me know, if this waiting for 3 announce packets to send first > delay request can be modified (or) this is as per standard and cannot be > modified. This is specified in IEEE 1588. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
[Linuxptp-users] Fwd: First delay request message on GM failure
Hi PTP experts, I have the following topology: PTP-source-1 — Boundary-clock PTP-source-2 - Initially PTP-source-1 is acting as Grandmaster to both Boundary clock and PTP-source-2 due to higher priority1 - When I disable PTP-source-1 I see that PTP-source-2 becomes grandmaster(due to second higher priority1) and sends out announce, sync packet once announce timeout expires. - Boundary clock is waiting for 3 announce packets before sending out its first delay request packet Kindly let me know, if this waiting for 3 announce packets to send first delay request can be modified (or) this is as per standard and cannot be modified. Regards, Karthick ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
