|Summary:||ath5k: Decreased throughput in IBSS or 802.11n mode|
|Product:||Drivers||Reporter:||Jeff Cook (jeff)|
|Severity:||normal||CC:||alan, florian, linville, maciej.rutecki, me, mickflemm, pedretti.fabio, rjw|
|Bug Depends on:|
Description Jeff Cook 2011-03-26 20:06:58 UTC
A lot of discussion on this bug has already occurred on Bug #31452. Please refer to that bug for complete detail. Since 2.6.38, throughput on wireless-n and ad-hoc networks has been very poor (unusably poor). Almost 100% packet loss in my ad-hoc setup with a 5k card as host; one would make it through only rarely, a couple times a minute or less (empirically, from watching in Wireshark). Reverting 8aec7af9 (with the patch posted on bug #31452) fixes this problem on ath5k for me. This bug also affects ath9k. I experienced it there on an ad-hoc client. I haven't retested or bisected that kernel yet but still intend to do so if nobody does it before me. Discussion related to ath9k should occur on bug #31452.
Comment 1 John W. Linville 2011-03-28 13:24:37 UTC
Nick, any thoughts on what might be wrong with 8aec7af9?
Comment 2 Nick Kossifidis 2011-03-28 13:41:30 UTC
@Jeff: Do you use fixed-freq when setting up ad-hoc mode ?
Comment 3 Jeff Cook 2011-03-30 23:57:09 UTC
I'm not sure which mode I use as I've just been setting it up through nm-applet. I'm not at the workstation now, but what would be useful to run when I get back after I set up the network? iwconfig, ifconfig, etc.?
Comment 4 Nick Kossifidis 2011-03-31 00:13:47 UTC
Use the iw command when setting up ad-hoc mode etc and use the fixed-freq argument (check out iw's help). Fixed-freq locks the card to a single channel and doesn't do bg scanning so it'll help us see if your problem is related to channel switching as a first step.
Comment 5 Florian Mickler 2011-05-01 14:16:33 UTC
Jeff, any news on this?