Benjamin Beichler <Benjamin.Beichler@xxxxxxxxxxxxxx> writes: >>> For general internet traffic, a retry count of 30 is way too high; that >>> is up to 120 ms of HOL blocking latency. Better to just drop the packet >>> at that point. >>> >>> Ideally, the retry count should be dynamically calculated in units of >>> time (which would depend on the rate and aggregate size), and also take >>> queueing time into account. I've been meaning to experiment with this >>> for minstrel and ath9k, but haven't gotten around to it... > We have running current research on this topic but focused on the > effects in 802.11s mesh networks. With multiple(forwarding) wireless > links, the retry limit have a bigger impact as only in managed mode > setups, since every forwarding step is doing repeated transmissions. > But I also totally agree, that the retry count needs to be considered > in the bufferbloat/airtime queuing stuff, which Toke proposed. Ah, cool. Looking forward to seeing your results. And yeah, it's probably even worse in meshes... > Nonetheless, since this ambiguities are known, wouldn't it be nice to > clean up all this patches to enable at least ath9k and ath10k to do > the right thing, or do anybody can tell why they weren't included the > first time ? No objection from me, certainly! :) -Toke
