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. However, do see TCP flows take a while to ramp up when started from the AP - a short test gets ~70Mbps when run from one hop away and ~50Mbps when run from the AP. how long are you running the tests for? (I seem to recall the ramp-up issue to be there pre-patch as well, though). As for why this would happen... There could be a bug in the dequeue code somewhere, but since you get better performance from sticking everything into one queue, my best guess would be that the client is choking on the interleaved packets? I.e. expending more CPU when it can't stick subsequent packets into the same TCP flow? -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
