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
