Re: [Linuxptp-devel] [PATCH 0/7] Use tmv_t abstraction for hardware timestamps

2018-03-15 Thread Michael Brown
On 12/03/18 12:36, Michael Brown wrote: This is a revised patch series to ensure that the tmv_t operations are used consistently for calculations involving hardware timestamps. The ugly hwts_to_tmv() and hwts_sw_to_tmv() wrappers from the previous patch series are gone. Instead we convert

Re: [Linuxptp-devel] [PATCH] differ message printed when local clock is best master

2018-03-15 Thread Keller, Jacob E
> -Original Message- > From: Richard Cochran [mailto:richardcoch...@gmail.com] > Sent: Thursday, March 15, 2018 1:56 PM > To: Keller, Jacob E > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH] differ message printed when local

Re: [Linuxptp-devel] [PATCH] differ message printed when local clock is best master

2018-03-15 Thread Richard Cochran
On Thu, Mar 15, 2018 at 01:31:38PM -0700, Jacob Keller wrote: > I've often been looking at log output from ptp4l and wondered which > clock id was which port. This patch helps ease the mental burden by > explicitly stating when we selected the local clock as the best choice. Me too. Thanks for

[Linuxptp-devel] [PATCH] differ message printed when local clock is best master

2018-03-15 Thread Jacob Keller
Make the log output a bit more clear by changing how we inform the user when the local clock is the best master clock. This allows easier parsing of the log and identifying when the local clock is being selected as the best clock. Signed-off-by: Jacob Keller --- I've

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

2018-03-15 Thread Anders Selhammer
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 neglected. Signed-off-by: Anders Selhammer

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

2018-03-15 Thread Anders Selhammer
We always but braces around 'if' blocks. Signed-off-by: Anders Selhammer --- port.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/port.c b/port.c index 2edfb26..5f333be 100644 --- a/port.c +++ b/port.c @@ -1347,12 +1347,14 @@

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

2018-03-15 Thread Anders Selhammer
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 0/3] Add TAILQ for sent delay_req

2018-03-15 Thread Anders Selhammer
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

Re: [Linuxptp-devel] [PATCH] Added TAILQ for sent delay_req

2018-03-15 Thread Richard Cochran
On Thu, Mar 15, 2018 at 06:43:00AM +, Anders Selhammer wrote: > How do I send a PATCH 0/X where I can explain the patches? An empty commit > with just comments? Here is how I do that: * Exporting Patches git format-patch \ --subject-prefix="PATCH" \ --output-directory

Re: [Linuxptp-devel] [PATCH 1/4] phc2sys: long options / cfg file / transportSpecific

2018-03-15 Thread Richard Cochran
On Wed, Mar 14, 2018 at 05:17:01PM +0100, Peter Schneider wrote: > diff --git a/phc2sys.c b/phc2sys.c > index 5c54055..c2f0d8e 100644 > --- a/phc2sys.c > +++ b/phc2sys.c > @@ -1286,6 +1286,7 @@ static void usage(char *progname) > " -O [offset]slave-master time offset (0)\n" >

Re: [Linuxptp-devel] [PATCH] Added TAILQ for sent delay_req

2018-03-15 Thread Anders Selhammer
On Wed, Mar 14, 2018 at 09:17:35PM +, Keller, Jacob E wrote: > This seems like a reasonable thing to want... However, a bit more > explanation on how the storage helps solve this problem, and possibly > how you prevent the list from growing too large in the worst case > might be good. >