[Make-wifi-fast] mesh deployment with ath9k driver changes

[Toke Høiland-Jørgensen]

Pete Heist <pete at eventide.io> writes:

>> On Apr 24, 2018, at 3:51 PM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> 
>> Assuming you have debugfs enabled you should be able to get aggregate
>> statistics from /sys/kernel/debug/ieee80211/phy0/ath9k/xmit - at least
>> that contains retries, but not backoff data, unfortunately.
>
> If it’s the ratio of "AMPDUs Completed” to "AMPDUs Retried” or “AMPDUs
> XRetried” we’re looking at, there’s a stark difference between Cabin
> 12 and Cabin 28. That said, they have quite different traffic
> patterns, so I’ll have to evaluate this in a situation where traffic
> patterns are more similar...

Yeah. I'm not actually sure how exactly those numbers reflect what
happens on the medium (nor what the difference between retried and
xretried is), but it's an indication at least.

>>> I wish I could cable everything, but it isn’t physically practical.
>>> The next possibility is dual channel APs, or separate backhaul links,
>>> all costing something...
>> 
>> Yeah, a separate backhaul on a different channel would cut you
>> contention in half, basically. Right now, each transmission has to
>> occupy the channel twice...
>
> Could that cause mean RTT to go up 10x? :) In combination with having
> two repeaters on one gateway…

Not sure. You do get HOL blocking while a packet is retried, basically.
And ath9k will keep trying way after it should have given up (up to 30
retries per packet). If you combine this with a lot of backoff for each
transmission (which is also quite likely in a very congested setting),
and I suppose it might be possible...

-Toke