Re: How many null-data probes on connection loss?

[Ben Greear <greearb@candelatech.com>]

On 09/26/2018 11:48 AM, Johannes Berg wrote:
> On Wed, 2018-09-26 at 11:47 -0700, Ben Greear wrote:
>
>>>> I think I'll start by making sure the firmware does not do software retransmits
>>>> for frames from the driver (self-gen frames are OK to be retransmitted I guess).
>>>
>>> You do want it to be doing retries for frames from the driver, since you
>>> want it to recover from temporary collisions with a microwave and
>>> whatnot ... just not *that many*, I guess.
>>
>>  From what I can tell so far, my firmware has this sort of logic:
>>
>> frame from stack to the driver
>>    -> send to firmware
>>    -> in firmware, hardware will do up to X retries (maybe 16 or so, need to check)
>>    -> On failure, the firmware may re-queue the packet (firmware-software retry)
>>    -> back to hardware retries (~32 frames on air at this point)
>>    ...
>>    Eventually tx-fail notification is sent back to the driver one way or another.
>>
>> I am thinking it would be best to have the software retry in the firmware
>> disabled.
>>
>> Then, when mac80211 sends a null-data frame, you would see at most about
>> 16 of them on air, every 500ms or so until it recovers or considers the
>> connection lost.
>
> Yes, that seems reasonable. In fact, I'd argue that such software-retry
> should just be disabled completely - it's better to lose the occasional
> frame than to keep using airtime for it forever ...
>
> Toke is probably getting nightmares reading this - sweet dreams ;-)

I *think* this software-retry does not apply to frames on a block-ack enabled
TID at least...that appeared to be the case with wave-2 firmware I just got through
modifying similar logic.

Just maybe that will help him sleep a bit better :)

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com