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 fixed the firmware....
Now only 4 retries per frame, but it seems mac80211 is all 5 of its
null-data probes within a few miliseconds. Is that expected, or should
there be a bit more pause between each of the probe requests to better
weather periodic network glitches?
Thanks,
Ben
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
