Re: TCP performance regression in mac80211 triggered by the fq code

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Toke Høiland-Jørgensen <toke@toke.dk> writes:

> Felix Fietkau <nbd@nbd.name> writes:
>
>> Hi,
>>
>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>> regression when running local iperf on an AP (running the txq stuff) to
>> a wireless client.
>>
>> Here's some things that I found:
>> - when I use only one TCP stream I get around 90-110 Mbit/s
>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>> - fairness between TCP streams looks completely fine
>> - there's no big queue buildup, the code never actually drops any packets
>> - if I put a hack in the fq code to force the hash to a constant value
>> (effectively disabling fq without disabling codel), the problem
>> disappears and even multiple streams get proper performance.
>>
>> Please let me know if you have any ideas.
>
> Hmm, I see two TCP streams get about the same aggregate throughput as
> one, both when started from the AP and when started one hop away.

So while I have still not been able to reproduce the issue you
described, I have seen something else that is at least puzzling, and may
or may not be related:

When monitoring the output of /sys/kernel/debug/ieee80211/phy0/aqm I see
that all stations have their queues empty all the way to zero several
times per second. This is a bit puzzling; the queue should be kept under
control, but really shouldn't empty completely. I figure this might also
be the reason why you're seeing degraded performance...

Since the stats output doesn't include a counter for drops, I haven't
gotten any further with figuring out if it's CoDel that's being too
aggressive, or what is happening. But will probably add that in and take
another look.

-Toke