[BISECTED][NEXT] Wifi downloads capped at 105Kbytes/s

[BISECTED][NEXT] Wifi downloads capped at 105Kbytes/s

[Sitsofe Wheeler]

Download speeds are never more than 105Kbytes/s even though the bit rate is
54Mb/s in at least linux-net kernels from next-20080523 onwards. I have
bisected it down to commit [2e92e6f2c50b4baf85cca968f0e6f1b5c0df7d39]:

commit 2e92e6f2c50b4baf85cca968f0e6f1b5c0df7d39
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Thu May 15 12:55:27 2008 +0200

    mac80211: use rate index in TX control

    This patch modifies struct ieee80211_tx_control to give band
    info and the rate index (instead of rate pointers) to drivers.
    This mostly serves to reduce the TX control structure size to
    make it fit into skb->cb so that the fragmentation code can
    put it there and we can think about passing it to drivers that
    way in the future.

    The rt2x00 driver update was done by Ivo, thanks.

    Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

Reverting this seemed to allow speeds up to 1.3Mbytes/s (which is expected
on this network). I believe I see this behaviour with both iwl3945 and
rt2x00 drivers. Here is the bisection log:

# bad: [7b6c98f0853b86c101948f1bf4e0a21d3065944f] Add linux-next specific
files
# good: [703d73f83f3329ebf5108553017b4a1b66b8fe19] Add linux-next specific
files
git-bisect start 'next-20080523' 'next-20080515'
# good: [3ebc2a4ec3a093e76e402c40ce8e2e5e5f04d86d] Merge
commit 'x86/auto-x86-next'
git-bisect good 3ebc2a4ec3a093e76e402c40ce8e2e5e5f04d86d
# bad: [e290a752da9c074a1a0cf32f404ccf6c7193abcd] Merge
commit 'wireless/master'
git-bisect bad e290a752da9c074a1a0cf32f404ccf6c7193abcd
# good: [8183b598a8acd441c7d7dca5fdc33fbb292ebdf2] Merge commit 'acpi/test'
git-bisect good 8183b598a8acd441c7d7dca5fdc33fbb292ebdf2
# good: [b679aeb304e3070626750c15e043a40da0e942fc] libertas: sysfs interface
for accessing default mesh channel
git-bisect good b679aeb304e3070626750c15e043a40da0e942fc
# good: [4ce50b6156635f2cffbf8961975c2e0b437dbcd9] Merge commit '4xx/next'
git-bisect good 4ce50b6156635f2cffbf8961975c2e0b437dbcd9
# good: [189a2b5942d62bd18e1e01772c4c784253f5dd16] iwlwifi: trigger event
log from debugfs
git-bisect good 189a2b5942d62bd18e1e01772c4c784253f5dd16
# good: [6d4a6672c8263f98544d2b91690dc7074b144090] tipc: Update "previous
node" indicators when node address changes
git-bisect good 6d4a6672c8263f98544d2b91690dc7074b144090
# bad: [e48b0eeb0ab508021b654a45f332b30cac2163b9] b43: Add hooks for
firmware debugging
git-bisect bad e48b0eeb0ab508021b654a45f332b30cac2163b9
# bad: [e039fa4a4195ac4ee895e6f3d1334beed63256fe] mac80211: move TX info
into skb->cb
git-bisect bad e039fa4a4195ac4ee895e6f3d1334beed63256fe
# good: [36d6825b91bc492b65b6333c369cd96a2fc8c903] mac80211: let drivers
wake but not start queues
git-bisect good 36d6825b91bc492b65b6333c369cd96a2fc8c903
# bad: [e24549485f859be6518929bb1c9c0257d79f033d] mac80211: reorder some
transmit handlers
git-bisect bad e24549485f859be6518929bb1c9c0257d79f033d
# bad: [2e92e6f2c50b4baf85cca968f0e6f1b5c0df7d39] mac80211: use rate index
in TX control
git-bisect bad 2e92e6f2c50b4baf85cca968f0e6f1b5c0df7d39

Perhaps a change was made but drivers have yet to be updated?

-- 
Sitsofe | http://sucs.org/~sits/

Re: [BISECTED][NEXT] Wifi downloads capped at 105Kbytes/s

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

Hi,

On Sun, 2008-06-01 at 17:22 +0100, Sitsofe Wheeler wrote:
> Download speeds are never more than 105Kbytes/s even though the bit rate is
> 54Mb/s in at least linux-net kernels from next-20080523 onwards. I have
> bisected it down to commit [2e92e6f2c50b4baf85cca968f0e6f1b5c0df7d39]:

[...]

> Reverting this seemed to allow speeds up to 1.3Mbytes/s (which is expected
> on this network). I believe I see this behaviour with both iwl3945 and
> rt2x00 drivers. Here is the bisection log:

[...]

> Perhaps a change was made but drivers have yet to be updated?

Thanks for your report. It looks like I forgot to initialise some
variables that now had a special 'unassigned' meaning with the value -1
while previously that was the value NULL (hence implicitly initialised
with a memset()). Patch in a minute, please test.

johannes


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

[PATCH] mac80211: fix rate control initialisation

[Johannes Berg]

In commit 2e92e6f2c50b4baf85cca968f0e6f1b5c0df7d39 ("mac80211: use rate
index in TX control") I forgot to initialise a few new variables to -1 which
means that the rate control algorithm is never triggered and 0 is used as
the only rate index, effectively fixing the transmit bitrate at the lowest
supported.

This patch adds the missing initialisation.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Bisected-by: Sitsofe Wheeler <sitsofe@yahoo.com>
---
 net/mac80211/tx.c |    2 ++
 1 file changed, 2 insertions(+)

--- everything.orig/net/mac80211/tx.c	2008-06-02 09:25:05.000000000 +0200
+++ everything/net/mac80211/tx.c	2008-06-02 09:31:34.000000000 +0200
@@ -947,6 +947,8 @@ __ieee80211_tx_prepare(struct ieee80211_
 	tx->local = local;
 	tx->sdata = IEEE80211_DEV_TO_SUB_IF(dev);
 	tx->channel = local->hw.conf.channel;
+	tx->rate_idx = -1;
+	tx->last_frag_rate_idx = -1;
 	/*
 	 * Set this flag (used below to indicate "automatic fragmentation"),
 	 * it will be cleared/left by radiotap as desired.

Re: [BISECTED][NEXT] Wifi downloads capped at 105Kbytes/s

[Pavel Roskin]

On Sun, 2008-06-01 at 17:22 +0100, Sitsofe Wheeler wrote:
> Download speeds are never more than 105Kbytes/s even though the bit rate is
> 54Mb/s in at least linux-net kernels from next-20080523 onwards. I have
> bisected it down to commit [2e92e6f2c50b4baf85cca968f0e6f1b5c0df7d39]:
> 
> commit 2e92e6f2c50b4baf85cca968f0e6f1b5c0df7d39
> Author: Johannes Berg <johannes@sipsolutions.net>
> Date:   Thu May 15 12:55:27 2008 +0200
> 
>     mac80211: use rate index in TX control
> 
>     This patch modifies struct ieee80211_tx_control to give band
>     info and the rate index (instead of rate pointers) to drivers.
>     This mostly serves to reduce the TX control structure size to
>     make it fit into skb->cb so that the fragmentation code can
>     put it there and we can think about passing it to drivers that
>     way in the future.
> 
>     The rt2x00 driver update was done by Ivo, thanks.

This patch also causes panic in b43 when using WEP.  I've just posted a
patch for that.

Please provide more details about your setup, in particular whether you
are using any encryption.

No need to cross-post so generously, linux-wireless is where it's
discussed.

-- 
Regards,
Pavel Roskin

Re: [PATCH] mac80211: fix rate control initialisation

[Sitsofe Wheeler]

Johannes Berg wrote:

> In commit 2e92e6f2c50b4baf85cca968f0e6f1b5c0df7d39 ("mac80211: use rate
> index in TX control") I forgot to initialise a few new variables to -1
> which means that the rate control algorithm is never triggered and 0 is
> used as the only rate index, effectively fixing the transmit bitrate at
> the lowest supported.
> 
> This patch adds the missing initialisation.

This is far better (the rate sets itself to 24Mb/s or 36 Mb/s rather than
being fixed on 54 Mb/s). However when using iwl3945 the rate could not be
forced using iwconfig wlan0 rate 54M fixed and it took a little . The rate
it chooses also seems to bounce about a bit - simply telling networkmanager
to reconnect results in a different speed (although it's hard to tell how
good the connection is while this is happening).

-- 
Sitsofe | http://sucs.org/~sits/

Re: [PATCH] mac80211: fix rate control initialisation

[Filippo Zangheri]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Sitsofe and everybody,

Sitsofe Wheeler ha scritto:
> This is far better (the rate sets itself to 24Mb/s or 36 Mb/s rather than
> being fixed on 54 Mb/s). However when using iwl3945 the rate could not be
> forced using iwconfig wlan0 rate 54M fixed and it took a little . The rate

Here I have the same behaviour with iwl3945 from
compat-wireless-2008-06-03, I cannot force the bitrate with iwconfig
(Wireless-Tools v29).

But the interface automatically sets the speed to 54M. And it worked
 nominally even before this latest patch by Johannes. I'm pretty
near the access point's antenna; signal strength varies between 99%
and 100% and noise power oscillates between -24 and -19 dBm.

So, maybe, the problem does not reside in the device driver?

Best regards.

- --
Filippo Zangheri

GPG key ID: 0x6C1F2F2F
Key fingerprint: E0A6 2A28 04EF EE13 5C5F 8BB8 8F3C 4C1B 6C1F 2F2F
Key server: pgp.mit.edu

- -----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GE d- s+:- a-- C++ UL+++ P+ L+++ E-- W+ N* o-- K- w--- O-- M--
V- PS++ PE+ Y+ PGP++ t 5-- X++ R* tv b+ DI-- D---- G-- e++ h--
r++ z*
- ------END GEEK CODE BLOCK------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIRP+/jzxMG2wfLy8RApbpAJ9JuyRPjBfn5h+cnIvJKL1W8LPotACdFe9G
BDW2z00i8j1Djt6xzTz6LiM=
=egTP
-----END PGP SIGNATURE-----