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 Wed, Aug 18, 2021 at 05:25:53PM +, 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
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 Thu, Aug 19, 2021 at 02:32:49PM +, Eric Decker wrote: > I can see now how to use interactive mode. I suggest considering > documenting this in the manpages and the help for pmc. Some > examples in the manpages would be helpful. I agree. Any patches with documentation improvements will be much appreciated! Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
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.
Thank you, Erez. I can see now how to use interactive mode. I suggest considering documenting this in the manpages and the help for pmc. Some examples in the manpages would be helpful. Eric Decker -Original Message- From: Geva, Erez Sent: Thursday, August 19, 2021 5:19 AM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran 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. Hi, Entering the pmc tool interactive mode is simple. Run the pmc tool without a management command. For example: Using direct mode: # pmc -u -f /etc/linuxptp/ptp4l.conf 'get VERSION_NUMBER' 'get PRIORITY1' Using interactive mode: # pmc -u -f /etc/linuxptp/ptp4l.conf Now you can enter: get VERSION_NUMBER Regarding the https://sf.net/projects/libpmc project. It is a separate project, aim to provide a pmc library with LGPL licence. Sort of filling the gap. Both the pmc tool and the libpmc uses standard IEEE 1558 management messages, and can be used with any IEEE 1558 entity that supports IEEE 1558 management messages. :-) Erez -Original Message- From: Eric Decker Sent: Thursday, 19 August 2021 04:56 To: Geva, Erez (ext) (DI PA DCP R 3) Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran 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. Hi Erez, I thought it might be better to take this part of the conversation offline, but maybe it will benefit others. How do you run pmc in interactive mode? I do not see that in the documentation. What is libpmc? Is it a part of the standard Linux PTP distribution, or is it a supplement to it? Would others people be aware it is available? I thought I reviewed all of the documentation and I never heard of it. Thanks, Eric Decker -Original Message- From: Geva, Erez Sent: Wednesday, August 18, 2021 8:37 PM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran 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. Hi, Regarding: "pmc executes as a new process each time it is called". 1. No you can run the pmc tool in interactive mode. Then send new requests, line by line and with increasing the sequence ID. 2. You can use the libpmc library https://sf.net/projects/libpmc, The library allow you to set any sequence ID you wish. I do not see why is that an issue for the ptp4l project. Erez -Original Message- From: Eric Decker Sent: Wednesday, 18 August 2021 19:26 To: Richard Cochran 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. Response below tagged as EDecker: Eric Decker -Original Message- From: Richard Cochran Sent: Wednesday, August 18, 2021 12:23 PM To: Eric Decker 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 +, 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
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.
Hi, Entering the pmc tool interactive mode is simple. Run the pmc tool without a management command. For example: Using direct mode: # pmc -u -f /etc/linuxptp/ptp4l.conf 'get VERSION_NUMBER' 'get PRIORITY1' Using interactive mode: # pmc -u -f /etc/linuxptp/ptp4l.conf Now you can enter: get VERSION_NUMBER Regarding the https://sf.net/projects/libpmc project. It is a separate project, aim to provide a pmc library with LGPL licence. Sort of filling the gap. Both the pmc tool and the libpmc uses standard IEEE 1558 management messages, and can be used with any IEEE 1558 entity that supports IEEE 1558 management messages. :-) Erez -Original Message- From: Eric Decker Sent: Thursday, 19 August 2021 04:56 To: Geva, Erez (ext) (DI PA DCP R 3) Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran 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. Hi Erez, I thought it might be better to take this part of the conversation offline, but maybe it will benefit others. How do you run pmc in interactive mode? I do not see that in the documentation. What is libpmc? Is it a part of the standard Linux PTP distribution, or is it a supplement to it? Would others people be aware it is available? I thought I reviewed all of the documentation and I never heard of it. Thanks, Eric Decker -Original Message- From: Geva, Erez Sent: Wednesday, August 18, 2021 8:37 PM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran 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. Hi, Regarding: "pmc executes as a new process each time it is called". 1. No you can run the pmc tool in interactive mode. Then send new requests, line by line and with increasing the sequence ID. 2. You can use the libpmc library https://sf.net/projects/libpmc, The library allow you to set any sequence ID you wish. I do not see why is that an issue for the ptp4l project. Erez -Original Message- From: Eric Decker Sent: Wednesday, 18 August 2021 19:26 To: Richard Cochran 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. Response below tagged as EDecker: Eric Decker -Original Message- From: Richard Cochran Sent: Wednesday, August 18, 2021 12:23 PM To: Eric Decker 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 +, 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
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.
Hi Erez, I thought it might be better to take this part of the conversation offline, but maybe it will benefit others. How do you run pmc in interactive mode? I do not see that in the documentation. What is libpmc? Is it a part of the standard Linux PTP distribution, or is it a supplement to it? Would others people be aware it is available? I thought I reviewed all of the documentation and I never heard of it. Thanks, Eric Decker -Original Message- From: Geva, Erez Sent: Wednesday, August 18, 2021 8:37 PM To: Eric Decker Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran 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. Hi, Regarding: "pmc executes as a new process each time it is called". 1. No you can run the pmc tool in interactive mode. Then send new requests, line by line and with increasing the sequence ID. 2. You can use the libpmc library https://sf.net/projects/libpmc/, The library allow you to set any sequence ID you wish. I do not see why is that an issue for the ptp4l project. Erez -Original Message- From: Eric Decker Sent: Wednesday, 18 August 2021 19:26 To: Richard Cochran 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. Response below tagged as EDecker: Eric Decker -Original Message- From: Richard Cochran Sent: Wednesday, August 18, 2021 12:23 PM To: Eric Decker 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 +, 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
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.
Hi, Regarding: "pmc executes as a new process each time it is called". 1. No you can run the pmc tool in interactive mode. Then send new requests, line by line and with increasing the sequence ID. 2. You can use the libpmc library https://sf.net/projects/libpmc/, The library allow you to set any sequence ID you wish. I do not see why is that an issue for the ptp4l project. Erez -Original Message- From: Eric Decker Sent: Wednesday, 18 August 2021 19:26 To: Richard Cochran 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. Response below tagged as EDecker: Eric Decker -Original Message- From: Richard Cochran Sent: Wednesday, August 18, 2021 12:23 PM To: Eric Decker 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 +, 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
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.
Response below tagged as EDecker: Eric Decker -Original Message- From: Richard Cochran Sent: Wednesday, August 18, 2021 12:23 PM To: Eric Decker 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 +, 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
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 +, 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. > > 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. > 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. > 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. > and always have the same sequence count untrue. See line 540 of pmc_common.c: msg->header.sequenceId = pmc->sequence_id++; > which prevents end nodes on ethernet from responding. Why should that prevent nodes from responding? > 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. > 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. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[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.
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.
1. Only forward responses to UDS port with a corresponding requests on the
UDS port.
The context of the issue/feature:
See the problem description below.
The problem that needs fixing (or missing feature):
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.
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.
2. PTP management messages originated from UDS (pmc) do not have the
correct source clock id, and always have the same sequence count which prevents
end nodes on ethernet from responding.
The context of the issue/feature:
See the problem description below.
The problem that needs fixing (or missing feature):
PTP management messages originated from UDS (pmc) do not have the correct
source clock id, and always have the same sequence count which prevents end
nodes on ethernet from responding.
How the proposed solution fixes the problem:
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. The correct source clock ID is also included
in the management messages.
Signed-off-by: Eric Decker
---
clock.c | 86 +
1 file changed, 81 insertions(+), 5 deletions(-)
diff --git a/clock.c b/clock.c
index d428ae2..897a623 100644
--- a/clock.c
+++ b/clock.c
@@ -981,7 +981,7 @@ struct clock *clock_create(enum clock_type type, struct
config *config,
}
c->default_dataset.localPriority =
config_get_int(config, NULL, "G.8275.defaultDS.localPriority");
- c->max_steps_removed = config_get_int(config, NULL,"maxStepsRemoved");
+ c->max_steps_removed = config_get_int(config, NULL, "maxStepsRemoved");
c->clock_class_threshold = config_get_int(config, NULL,
"clock_class_threshold");
/* Harmonize the twoStepFlag with the time_stamping option. */
@@ -1381,7 +1381,9 @@ static int clock_do_forward_mgmt(struct clock *c,
return 0;
/* Don't forward any requests to the UDS-RW port
- (the UDS-RO port doesn't allow any forwarding). */
+* (the UDS-RO port doesn't allow any forwarding).
+* Do forward responses.
+*/
if (out == c->uds_rw_port) {
switch (management_action(msg)) {
case GET:
@@ -1393,7 +1395,8 @@ static int clock_do_forward_mgmt(struct clock *c,
if (!*pre_sent) {
/* delay calling msg_pre_send until
-* actually forwarding */
+* actually forwarding
+*/
msg_pre_send(msg);
*pre_sent = 1;
}
@@ -1404,17 +1407,90 @@ static void clock_forward_mgmt_msg(struct clock *c,
struct port *p, struct ptp_m
{
struct port *piter;
int pdulen = 0, msg_ready = 0;
+ static UInteger16 mgmt_seq_count;
+ UInteger16 temp_seq_count = 0;
+
+ struct uds_mgmt_req {
+ UInteger16 seqId;
+ Enumeration16 id;
+ };
+ #define MGMT_REQ_Q_SIZE 4
+ static struct uds_mgmt_req uds_req[MGMT_REQ_Q_SIZE] = {0};
+ static unsigned int uds_req_index;
+ int forward_to_uds = 0;
+ struct management_tlv *mgt =
+ (struct management_tlv *) msg->management.suffix;
if (forwarding(c, p) && msg->management.boundaryHops) {
pdulen = msg->header.messageLength;
msg->management.boundaryHops--;
+
+ if (p == c->uds_rw_port) {
+ /* Send with a unique sequence count and correct clock
identity.
+* If ingress port is uds port (pmc) increment sequence
count.
+*/
+ temp_seq_count = msg->header.sequenceId;
+ msg->header.sequenceId = mgmt_seq_count++;
+ msg->header.sourcePortIdentity.clockIdentity =
clock_identity(c);
+
+
