[Linuxptp-devel] [PATCH v2 2/2] port: Added TAILQ for sent delay_req

In a ptp unaware network (like the telecom profile for frequency sync G.8265.1), both the RTD and the PDV can be substantially higher than in a ptp aware network. To achieve more accurate measurements, the rate may need to be configured higher to get more data and increase the chance of lucky

[Linuxptp-devel] [PATCH v2 0/2] Add TAILQ for sent delay_req

In a ptp unaware network (like the telecom profile for frequency sync G.8265.1), both the RTD and the PDV can be substantially higher than in a ptp aware network. To achieve more accurate measurements, the rate may need to be configured higher to get more data and increase the chance of lucky

[Linuxptp-devel] [PATCH v2 1/2] port: Fix coding style

We always but braces around 'if' blocks. Signed-off-by: Anders Selhammer --- port.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/port.c b/port.c index 8191e77..635676d 100644 --- a/port.c +++ b/port.c @@ -1331,12 +1331,14 @@

Re: [Linuxptp-devel] [PATCH 0/3] Add TAILQ for sent delay_req

> -Original Message- > From: Anders Selhammer [mailto:anders.selham...@est.tech] > Sent: Tuesday, March 20, 2018 12:14 PM > To: Richard Cochran > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH 0/3] Add TAILQ for sent delay_req >

Re: [Linuxptp-devel] [PATCH 0/3] Add TAILQ for sent delay_req

Tuesday, March 20, 2018 3:27 PM >No, use a time out just like we do in other places, please. Ok, great. I did not notice this. Much better than counter. I will include this, see summary in the end. >> msg: Added missing network to host convertion of for portIdentity in >> received delay

Re: [Linuxptp-devel] [PATCH 0/3] Add TAILQ for sent delay_req

On Tue, Mar 20, 2018 at 08:21:09AM +, Anders Selhammer wrote: > One thing that I might overseen is the growing part. I covered that > some packets might be lost but if all delay resp are lost by some > reason it might be good to have some kind of a limit of how many > delay req the stack

Re: [Linuxptp-devel] [PATCH 3/3] port: Fix coding style in updated functions

On Thu, Mar 15, 2018 at 12:00:28PM +0100, Anders Selhammer wrote: > We always but braces around 'if' blocks. Please put any clean-up patches first in the series. Thanks, Richard -- Check out the vibrant tech community

Re: [Linuxptp-devel] [PATCH 2/3] port: Remove obsolete delay_req in TAILQ

On Thu, Mar 15, 2018 at 12:00:27PM +0100, Anders Selhammer wrote: > @@ -1830,7 +1830,7 @@ out: > static void process_delay_resp(struct port *p, struct ptp_message *m) > { > struct delay_resp_msg *rsp = >delay_resp; > - struct ptp_message *req; > + struct ptp_message *req, *obs;

Re: [Linuxptp-devel] [PATCH 2/3] port: Remove obsolete delay_req in TAILQ

On Thu, Mar 15, 2018 at 12:00:27PM +0100, Anders Selhammer wrote: > This patch will remove all delay requests in queue that is older than the > latest processed. Connected responses to these are either much more delayed > or lost. Any received response derived from an obsolete request will be >

Re: [Linuxptp-devel] [PATCH 2/3] port: Remove obsolete delay_req in TAILQ

On Thu, Mar 15, 2018 at 12:00:27PM +0100, Anders Selhammer wrote: > This patch will remove all delay requests in queue that is older than the > latest processed. Connected responses to these are either much more delayed > or lost. Any received response derived from an obsolete request will be >

Re: [Linuxptp-devel] [PATCH 1/3] port: Added TAILQ for sent delay_req

On Thu, Mar 15, 2018 at 12:00:26PM +0100, Anders Selhammer wrote: > In a ptp unaware network (like the telecom profile for frequency sync > G.8265.1), both the RTD and the PDV can be substantially higher than in a ptp > aware network. To achieve more accurate measurements, the rate may need to

Re: [Linuxptp-devel] [PATCH 0/3] Add TAILQ for sent delay_req

Hi Any other comments on this patch? It needs to be rebased but I will wait with that until I got any other comments. One thing that I might overseen is the growing part. I covered that some packets might be lost but if all delay resp are lost by some reason it might be good to have some kind