Re: [Linuxptp-users] Fw: “Resource temporarily unavailable” errors during flood ping test

[Jacob K. <jac...@in...>]

On 11/01/2012 01:53 AM, Richard Cochran wrote:
> On Tue, Oct 30, 2012 at 11:02:21PM +0000, Keller, Jacob E wrote:
>>
>> It would take an insane amount of work to move to a model that
>> allows receive handling inside sk.c, and I believe it isn't worth
>> the effort. I would however like to increase the default
>> tx_timestamp_retries value, as 2 tries rarely works for anything
>> I've tested, as it generates false positive errors a lot.
>
> Okay, what value is a safe default, in your experience?
>
>> What hardware are you using that doesn't have issues at 2 retries?
>
> The PHYTER almost never loses a Tx time stamp, and the TI CPTS seems
> to be working perfectly, too. I don't have the Freescale eTSEC (gianfar)
> for testing, but I remember that it always worked, since the Tx time
> stamp is delivered into packet buffer's padding.
>
> With the IGB, sometimes it seemed that 2 retries is okay, but
> sometimes I needed to ramp this up.
>
>> And have you attempted testing this under moderate stress?
>
> I just retested the PHYTER under a ping flood, and there were no
> hiccups. I will test the CPTS again when I get a chance.
>
> Thanks,
> Richard
>

At 10Gbe link, I've only needed to go up to about 20 or 25 to remove 
most of the contention. Our validation team increased this to 200 as 
they really didn't want to see false positives and it seemed better to 
wait longer.

the 1Gb ones I haven't got a figure personally but I will ask Matthew.

I am ok with needing to ramp up the value sometimes, but I would much 
prefer a default which meant fewer users had to change something as the 
value seemed cryptic to the people I had to explain it too.


An interesting thought I just had was how difficult would it be for the 
software to automatically increase the timing if it misses a bunch of tx 
timestamps in a row? So if would increase a counter as it missed tx 
timestamps, so that it would start low but would increase to the value 
the hardware needs to respond in time. I'm thinking it would only 
trigger if you missed a few in a row as a one time mistake isn't really 
a big deal.

Thanks

- Jake