Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > Felix Fietkau <nbd@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
