jacob.e.kel...@intel.com said:
> We get into the kthread function within a few hundred usec or less, and then
> the firmware read takes a long time, sometimes over 2 milliseconds.
Why is it taking so long?
How long does it take when things go well? Is there anything complicated
going on with a
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, 99900
On Wed, Jul 07, 2021 at 11:46:16PM +, Keller, Jacob E wrote:
> Either way, I found that whether I used a kthread or not I was
> unable to avoid the timeout issue with ice hardware because the
> delay is caused by the method we must use to access the Tx
> timestamps :( We get into the kthread f
The tx_timestamp_timeout configuration defines the number of
milliseconds to wait for a Tx timestamp from the kernel stack. This
delay is necessary as Tx timestamps are captured after a packet is sent
and reported back via the socket error queue.
The current default is to poll for up to 1 millisec
> -Original Message-
> From: Richard Cochran
> Sent: Wednesday, July 07, 2021 4:29 PM
> To: Keller, Jacob E
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] tx_timestamp_timeout default
>
> On Wed, Jul 07, 2021 at 10:22:59PM +, Keller, Jacob E wrote:
> >
On Wed, Jul 07, 2021 at 10:22:59PM +, Keller, Jacob E wrote:
> I am wondering if there would be support for either (a) increasing
> the default timeout, or (b) adding something to the PTP get
> capabilities for indicating a sort of default timeout for the
> device, and if it's not set in the co
Hi,
I've been working on implementing support for PTP in the E810 and E822 devices
for Intel's ice driver. As part of this work we've discovered that (again...)
timestamps can sometimes take longer than the 1millisecond default delay.
Although we get an interrupt within 10usec, the timestamp ha
