On Wed, Aug 18, 2021 at 05:25:53PM +0000, Eric Decker wrote: > So the proper fix would be to ensure the ptp4l's write() is non blocking. > EDecker: I wonder if that approach would have unexpected consequences.
No, it would not. ptp4l should never block because of issues at the other end of the UDS. The fact that it does is a bug in ptp4l. > EDecker: If a non-blocking write fixes the problem with no side > effects then perhaps that is a better solution. The use case I am > using is requesting data using pmc. A host attempting to access > data using PMC will not benefit from another host having previously > requested the same data. How would the host requesting data using > pmc know that ptp4l previously received a similar response, Because it receives all responses. The responses are multicast! > and how would it know how recently that response was received? By looking at the time when it receives the message? > EDecker: The problem is pmc executes as a new process each time it > is called. The sequence count sent from pmc to ptp4l is always the > same (0 or 1), so ptp4l always sends management messages from pmc > with the same sequence count. So, it would be nice to be able to script the pmc program, invoking it over and over again, but having the sequence number increase. The proper fix would be to add a command line argument to pmc that specifies the first sequence number to be used. However, the present patch hacks something into ptp4l, which is the wrong place to do it. > EDecker: Some end nodes I work with monitor the sequence count to > make sure it is not a duplicate or "malformed" packet and do not > process the management message unless the sequence count is unique > as compared to previous management messages from the same > clock/module. This behavior is neither required nor recommended by the 1588 standard. Still, I agree having pmc increment the sequence number when scripted would look nicer. > EDecker: Ideally pmc would produce sequential sequence counts, but > since is executes as a new process each time it is called, it > cannot. I don't think there is another option without significant > changes to pmc. Just add a command line option. That would be an easy change. > EDecker: Why would you require the caller of pmc to specify the > source clock ID? As I said earlier I would expect the source clock > ID to be the clock ID of the clock that sends the message. Perhaps > there are other use cases which I am not aware of. You can choose any clockId that you want. Therefore it must be configurable. The ID is not necessarily the MAC address of the port, but that is merely a convenient default. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
