> -Original Message-
> From: Richard Cochran
> Sent: Wednesday, July 14, 2021 6:12 AM
> To: Keller, Jacob E
> Cc: Miroslav Lichvar ; linuxptp-
> de...@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH] Increase the default
> tx_timestamp_timeout
&g
> -Original Message-
> From: Richard Cochran
> Sent: Wednesday, July 14, 2021 6:03 AM
> To: Keller, Jacob E
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH] Increase the default
> tx_timestamp_timeout
> to 5
>
> On W
On Wed, Jul 14, 2021 at 11:20:00AM +, Keller, Jacob E wrote:
> I think for Tx the challenges are higher: the timestamp is taken
> after we've filled in the descriptor and sent the frame. The only
> place it could reasonably be stored again is the descriptor
> writeback (since we don't get
On Wed, Jul 14, 2021 at 11:20:23AM +, Keller, Jacob E wrote:
> What about at least checking for the case where a timestamp was never
> started? Drivers are supposed to set a flag in the SKB when they start a
> timestamp (and not set it if they can't start it).
How could that happen?
Putting
> -Original Message-
> From: Richard Cochran
> Sent: Monday, July 12, 2021 6:44 PM
> To: Keller, Jacob E
> Cc: Miroslav Lichvar ; linuxptp-
> de...@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH] Increase the default
> tx_timestamp_timeout
&g
On 7/12/2021 6:36 PM, Richard Cochran wrote:
> On Mon, Jul 12, 2021 at 05:02:58PM -0700, Vinicius Costa Gomes wrote:
>> Speaking of future improvements, wouldn't it be easier if the
>> kernel/driver was able to notify userspace that a timestamping request
>> wasn't able to be serviced?
>
> It
On Mon, Jul 12, 2021 at 03:02:50PM +, Keller, Jacob E wrote:
> Right. Though.. running something like ptp4l on the same connection
> could be problematic if the applications aren't working together
> because most hardware supports a single request at once,
I wouldn't say "most". Surely some
Hi,
Miroslav Lichvar writes:
> On Thu, Jul 08, 2021 at 01:37:38AM +, Eric Decker wrote:
>> If the timestamp is available in less than the timeout (5ms) will it still
>> wait for the timeout, or continue processing after the timestamp is received?
>
> The poll() call is waiting for the
> -Original Message-
> From: Miroslav Lichvar
> Sent: Monday, July 12, 2021 12:35 AM
> To: Keller, Jacob E
> Cc: Eric Decker ; linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH] Increase the default
> tx_timestamp_timeout
> to 5
&
On Thu, Jul 08, 2021 at 07:35:25PM +, Keller, Jacob E wrote:
> > As a future improvement, maybe it could be adaptive, e.g. once in a
> > while try waiting much longer and if that doesn't give a timestamp
> > stick to a shorter interval. That is, try to detect when the hardware
> > is not able
Cochran ; Miroslav Lichvar
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout
to 5
If I recall correctly there is an unconditional 150ms delay in PMC which also
uses poll(). That I why I asked the question. The delay in PMC may
cker
Sent: Friday, 9 July 2021 00:28
To: Richard Cochran ; Miroslav Lichvar
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout
to 5
If I recall correctly there is an unconditional 150ms delay in PMC which also
uses poll(). Th
On Thu, Jul 08, 2021 at 07:15:17PM +, Machnikowski, Maciej wrote:
> Can it be a half of the packet rate?
No!
> Or there is any reason to make a specific tighter
> limit to it?
See the discussion of the effect of computational delay on stability
in John Eidson's "Measurement, Control, and
> -Original Message-
> From: Miroslav Lichvar
> Sent: Thursday, July 08, 2021 4:10 AM
> To: Eric Decker
> Cc: Keller, Jacob E ; linuxptp-
> de...@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH] Increase the default
> tx_timestamp_timeout
> to
> -Original Message-
> From: Eric Decker
> Sent: Wednesday, July 07, 2021 6:38 PM
> To: Keller, Jacob E ; linuxptp-
> de...@lists.sourceforge.net
> Subject: RE: [Linuxptp-devel] [PATCH] Increase the default
> tx_timestamp_timeout
> to 5
>
> If the times
> -Original Message-
> From: Richard Cochran
> Sent: Thursday, July 8, 2021 7:42 PM
> On Thu, Jul 08, 2021 at 01:10:08PM +0200, Miroslav Lichvar wrote:
> > On Thu, Jul 08, 2021 at 01:37:38AM +, Eric Decker wrote:
> > > If the timestamp is available in less than the timeout (5ms)
On Thu, Jul 08, 2021 at 01:10:08PM +0200, Miroslav Lichvar wrote:
> On Thu, Jul 08, 2021 at 01:37:38AM +, Eric Decker wrote:
> > If the timestamp is available in less than the timeout (5ms) will it still
> > wait for the timeout, or continue processing after the timestamp is
> > received?
>
On Thu, Jul 08, 2021 at 01:37:38AM +, Eric Decker wrote:
> If the timestamp is available in less than the timeout (5ms) will it still
> wait for the timeout, or continue processing after the timestamp is received?
The poll() call is waiting for the descriptor, so it should return as
soon as
If the timestamp is available in less than the timeout (5ms) will it still wait
for the timeout, or continue processing after the timestamp is received?
Eric
-Original Message-
From: Jacob Keller
Sent: Wednesday, July 7, 2021 8:02 PM
To: linuxptp-devel@lists.sourceforge.net
Subject:
On Wed, Jul 07, 2021 at 05:02:21PM -0700, Jacob Keller wrote:
> diff --git a/config.c b/config.c
> index 4472d3d9d6f9..f33f177c696a 100644
> --- a/config.c
> +++ b/config.c
> @@ -323,7 +323,7 @@ struct config_item config_tab[] = {
> GLOB_ITEM_INT("ts2phc.pulsewidth", 5, 100,
20 matches
Mail list logo
