Response below tagged as EDecker:
Eric Decker
-----Original Message-----
From: Richard Cochran <richardcoch...@gmail.com>
Sent: Wednesday, August 18, 2021 12:23 PM
To: Eric Decker <edec...@oldi.com>
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Only forward responses to UDS port with
corresponding requests on the UDS port, and always send with a unique sequence
count from uds.
On Mon, Aug 16, 2021 at 03:38:21PM +0000, Eric Decker wrote:
> Subject: [PATCH] Only forward responses to UDS port with corresponding
> requests on the UDS port, and always send management with a unique sequence
> count from uds.
The subject line should be ONE sentence, please.
EDecker: It is one sentence.
>
> 1. Only forward responses to UDS port with a corresponding requests on
> the UDS port.
This is one "issue", and you have a second issue, below. That means you should
make (at least) two patches that address the issues independently.
> When ptp4l is configured as a boundary clock and a host on ethernet is
> issuing excessive management requests (a PTP monitoring tool) then the
> requests get forwarded across the boundary clock and the subsequent
> responses get forwarded to the UDS port. The UDS code sends messages
> to the uds address of the last process it received a message from.
> The phc2sys daemon is not expecting these responses which causes its
> receive buffers to get full and then the ptp4l send buffers get full
> which causes ptp4l to lock until phc2sys reads the messages from its
> uds port. ptp4l will lock until phc2sys reads messages from the uds
> port which happens every 60sec.
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.
> How the proposed solution fixes the problem:
>
> Ptp4l will only forward ptp management response messages to the uds
> port if it was requested by the uds port. This will prevent the uds
> port buffers from getting full and causing ptp4l to hang until the
> buffers are read.
Actually, this is wrong. Why? Because the management scheme in 1588 is
multicast on purpose. All of the clients benefit from the replies.
For example, if a client wants to monitor CURRENT_DATA_SET periodically, it can
set a timer. If a reply from *another* client arrives before the timer
expires, the client simply uses the information in the reply and resets the
timer. This scheme will reduce duplicated queries in the network.
So ptp4l must not filter the replies.
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, and how would it know how recently that response was received?
> 2. PTP management messages originated from UDS (pmc) do not have the
> correct source clock id,
I can't agree with this statement. There is no such thing a "correct"
clockId. They are arbitrary.
EDecker: I would expect the source clock ID of a management message to be the
clock ID of the module which sent the message.
> and always have the same sequence count
untrue. See line 540 of pmc_common.c:
msg->header.sequenceId = pmc->sequence_id++;
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.
> which prevents end nodes on ethernet from responding.
Why should that prevent nodes from responding?
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.
> Ptp4l will now maintain a static sequence count and send PTP
> management messages using this sequence count so each PTP management
> message will have a unique sequential sequence count.
ptp4l does not generate the messages, and so it has no business "correcting"
them.
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.
> The correct
> source clock ID is also included in the management messages.
The proper fix is to allow configuration of the clockId in the pmc program via
the config mechanism, just like we have in ptp4l.
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.
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
