rtl8180 Bit Rate regression in 2.6.29

rtl8180 Bit Rate regression in 2.6.29

[Adrian Bassett]

(I'm not currently subscribed so please Cc: in any response ...)

Using PCI device 1799:700f and the rtl8180 kernel wireless driver.

With the vanilla 2.6.29-rc releases (rc8 most recently but also with pr=
edecessors) I've noticed that the Bit Rate of my wireless device appear=
s to be more or less fixed at 1 Mb/s.  Occasionally, iwconfig reports h=
igher values but, as the stats below show, no attempts are successful a=
t higher Bit Rates with this kernel version.

With the 2.6.28 series, however, the Bit Rate will vary in the normal w=
ay, with the majority of the network activity happening at the higher e=
nd, if not the highest(54 Mb /s) point, of the range supported by this =
device.

This is using the minstrel rate control mechanism.

2.6.29 stats:

14:44:02 up  4:10,  2 users,  load average: 0.12, 0.11, 0.06

Stats from /sys/kernel/debug/ieee80211/phy0/stations/xx:xx:xx:xx:xx:xx/=
rc_stats

rate     throughput  ewma prob   this prob  this succ/attempt   success=
    attempts
TtP  1         0.9      103.7      100.0          4(  4)      10040    =
    9806
     2         0.0        0.0        0.0          0(  0)          0    =
      46
     5.5       0.0        0.0        0.0          0(  0)          0    =
      47
    11         0.0        0.0        0.0          0(  0)          0    =
      48
     6         0.0        0.0        0.0          0(  0)          0    =
      47
     9         0.0        0.0        0.0          0(  0)          0    =
      48
    12         0.0        0.0        0.0          0(  0)          0    =
      45
    18         0.0        0.0        0.0          0(  0)          0    =
      46
    24         0.0        0.0        0.0          0(  0)          0    =
      46
    36         0.0        0.0        0.0          0(  0)          0    =
      47
    48         0.0        0.0        0.0          0(  0)          0    =
      48
    54         0.0        0.0        0.0          0(  0)          0    =
      58

Total packet count::    ideal 9399      lookaround 494



2.6.28.7 stats:

19:17:12 up  4:31,  2 users,  load average: 0.32, 0.31, 0.12

Stats from /sys/kernel/debug/ieee80211/phy0/stations/xx:xx:xx:xx:xx:xx/=
rc_stats

rate     throughput  ewma prob   this prob  this succ/attempt   success=
    attempts
  P  1         0.9       99.9      100.0          0(  0)        284    =
     284
     2         1.9       99.9      100.0          0(  0)         78    =
      78
     5.5       5.0       99.9      100.0          0(  0)        152    =
     152
    11         9.5       99.9      100.0          0(  0)         78    =
      78
     6         4.2       74.4        0.0          0(  0)         75    =
      84
     9         8.4       99.9      100.0          0(  0)         78    =
      78
    12        11.0       99.9      100.0          0(  0)         78    =
      78
    18        16.2       99.9      100.0          0(  0)         78    =
      79
    24        21.2       99.9      100.0          0(  0)         78    =
      80
T   36         7.0       99.8      100.0          0(  0)       1454    =
    1486
 t  48         5.6       74.0       44.4          4(  9)       8835    =
   10282
    54         2.5       59.6       20.0          0(  0)       6128    =
    7723

Total packet count::    ideal 6802      lookaround 357


Hope this report is useful.  If it would help I could test any patches =
that might be produced.

regards and thanks,

Adrian Bassett








_________________________________________________________________
View your Twitter and Flickr updates from one place =96 Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rtl8180 Bit Rate regression in 2.6.29

[Larry Finger]

Adrian Bassett wrote:
> 
> (I'm not currently subscribed so please Cc: in any response ...)
> 
> Using PCI device 1799:700f and the rtl8180 kernel wireless driver.
> 
> With the vanilla 2.6.29-rc releases (rc8 most recently but also with predecessors) I've noticed that the Bit Rate of my wireless device appears to be more or less fixed at 1 Mb/s.  Occasionally, iwconfig reports higher values but, as the stats below show, no attempts are successful at higher Bit Rates with this kernel version.
> 
> With the 2.6.28 series, however, the Bit Rate will vary in the normal way, with the majority of the network activity happening at the higher end, if not the highest(54 Mb /s) point, of the range supported by this device.

It would be immensely helpful if you, or someone else with this hardware and the
problem, could use git to download the mainline tree and find the bad commit
using bisection. In a review of the commit log, I found only one change in the
rtl8180 code in the 2.6.28 to 2.6.29-rcX range, and without it the rtl8180 would
not work at all. As a result, I cannot suggest a trial patch.

My system says that there are 6172 commits between 2.6.29-rc8 and 2.6.28, thus
it will take roughly 13 kernel builds to bisect the problem.

Larry

RE: rtl8180 Bit Rate regression in 2.6.29

[Adrian Bassett]

Thanks for the quick response.

I already use git and kernel source from kernel.org so I'll branch out,=
 follow the bisect instructions in git man/docs, and see what I can com=
e up with ...

Adrian Bassett

> Date: Mon, 16 Mar 2009 09:40:15 -0500
> From: Larry.Finger@lwfinger.net
> To: adrian.bassett@hotmail.co.uk
> CC: linux-wireless@vger.kernel.org
> Subject: Re: rtl8180 Bit Rate regression in 2.6.29
>=20
> Adrian Bassett wrote:
>>=20
>> (I'm not currently subscribed so please Cc: in any response ...)
>>=20
>> Using PCI device 1799:700f and the rtl8180 kernel wireless driver.
>>=20
>> With the vanilla 2.6.29-rc releases (rc8 most recently but also with=
 predecessors) I've noticed that the Bit Rate of my wireless device app=
ears to be more or less fixed at 1 Mb/s.  Occasionally, iwconfig report=
s higher values but, as the stats below show, no attempts are successfu=
l at higher Bit Rates with this kernel version.
>>=20
>> With the 2.6.28 series, however, the Bit Rate will vary in the norma=
l way, with the majority of the network activity happening at the highe=
r end, if not the highest(54 Mb /s) point, of the range supported by th=
is device.
>=20
> It would be immensely helpful if you, or someone else with this hardw=
are and the
> problem, could use git to download the mainline tree and find the bad=
 commit
> using bisection. In a review of the commit log, I found only one chan=
ge in the
> rtl8180 code in the 2.6.28 to 2.6.29-rcX range, and without it the rt=
l8180 would
> not work at all. As a result, I cannot suggest a trial patch.
>=20
> My system says that there are 6172 commits between 2.6.29-rc8 and 2.6=
=2E28, thus
> it will take roughly 13 kernel builds to bisect the problem.
>=20
> Larry

_________________________________________________________________
View your Twitter and Flickr updates from one place =96 Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rtl8180 Bit Rate regression in 2.6.29

[Hin-Tak Leung]

On Mon, Mar 16, 2009 at 2:40 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:

> My system says that there are 6172 commits between 2.6.29-rc8 and 2.6.28, thus
> it will take roughly 13 kernel builds to bisect the problem.

I had used a "poor man's git bisect" system once or twice: get a
couple of months of daily compat-wireless tarballs, and
doing manual bisect to find the two tar balls which results in the
regression, then look up the release tags inside and extract the
patches from wireless git (it is about 40 daily) then apply them in
sequence, etc.

The beauty of this scheme is that (1) installing/changing/switching
between compat-wireless snapshot does not require a reboot - you just
need to give up wireless connectivity for a moment during the switch,
(2) building compat-wlreless is a lot faster than building whole
kernel trees, (3) particularly if you don't have or don't intend to
clone the whole of wireless git (a few hundred MB), the tarballs are
relatively small - and just known which two (and their release tags)
spans the regression would narrow the problem down to about 40
changes, many of them are obviously irrelevant, so this info could be
useful to the developers. The release tags (*-release at the top of
the tarball) are at the top of the unpacked tar balls.

This process assumes that one can find a sufficiently old
compat-wireless snapshot which did not have the problem, and a
sufficiently new one which has it...

Re: rtl8180 Bit Rate regression in 2.6.29

[John W. Linville]

On Mon, Mar 16, 2009 at 12:22:50PM +0000, Adrian Bassett wrote:
> 
> 
> (I'm not currently subscribed so please Cc: in any response ...)
> 
> Using PCI device 1799:700f and the rtl8180 kernel wireless driver.
> 
> With the vanilla 2.6.29-rc releases (rc8 most recently but also with predecessors) I've noticed that the Bit Rate of my wireless device appears to be more or less fixed at 1 Mb/s.  Occasionally, iwconfig reports higher values but, as the stats below show, no attempts are successful at higher Bit Rates with this kernel version.
> 
> With the 2.6.28 series, however, the Bit Rate will vary in the normal way, with the majority of the network activity happening at the higher end, if not the highest(54 Mb /s) point, of the range supported by this device.
> 
> This is using the minstrel rate control mechanism.

FWIW, are you sure?  PID was still the default in 2.6.28 IIRC.
The "run to the highest available rate" behavior was typical of PID.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

FW: rtl8180 Bit Rate regression in 2.6.29

[Adrian Bassett]

(Replied to John's note but forgot to Cc: the list so here is):

> FWIW, are you sure?  PID was still the default in 2.6.28 IIRC.
> The "run to the highest available rate" behavior was typical of PID.
=20
I have just gone through all of my preserved 2.6.28 configs (2.6.28 to =
2.6.28.7) and in every case:
=20
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=3Dy
=20
and

CONFIG_MAC80211_RC_DEFAULT=3D"minstrel"
=20
whilst
=20
CONFIG_MAC80211_RC_DEFAULT_PID is not set
=20
Same thing for 2.6.29-rc stuff.
=20
(All my 2.6.27 configs used PID for rate control, probably that's all t=
here was, can't remember).
=20
I'm currently bisecting - at 2.6.29-rc2 at the moment - but with no imp=
rovement so far in the Bit Rate reported by iwconfig.
=20
In all I'm pretty sure it's not a minstrel v. PID rate control issue so=
 much as something different in the underlying stuff between 2.6.28 and=
 2.6.29.
=20
Adrian
=20
=20

_________________________________________________________________
View your Twitter and Flickr updates from one place =96 Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RTL8180 Bit Rate Regression in 2.6.29

[Adrian Bassett]

> It would be immensely helpful if you, or someone else with this hardw=
are and the
> problem, could use git to download the mainline tree and find the bad=
 commit
> using bisection. In a review of the commit log, I found only one chan=
ge in the
> rtl8180 code in the 2.6.28 to 2.6.29-rcX range, and without it the rt=
l8180 would
> not work at all. As a result, I cannot suggest a trial patch.

Ok, I've finished bisecting between a 'good' kernel (2.6.28) and a 'bad=
' one (2.6.29-rc1) and have identified the 'first bad' commit.  It seem=
s that the problem is introduced (perhaps not unsurprisingly) as a resu=
lt of e6a9854b05c1a6af1308fe2b8c68f35abf28a3ee - mac80211/drivers: rewr=
ite the rate control API.  This is the first kernel build in the 2.6.29=
 development series which shows the Bit Rate failing to succeed at anyt=
hing other than 1 Mb/s.  The previous 'good' kernel - faf3994a9f65fd95a=
68bbcc03c318a427cd1e7d3 - succeeds as expected in this respect.  Presum=
ably something is broken/incomplete in the changes introduced to driver=
s/net/wireless/rtl8180_dev.c in e6a9854b05c1a6af1308fe2b8c68f35abf28a3e=
e, but it might be more subtle than that, I don't know.

Again, I can certainly test any patches.

Hardware is 1799:700f (=3D RTL8185vD + rtl8225z2)

Thanks again,

Adrian

git bisect log

# bad: [c59765042f53a79a7a65585042ff463b69cb248c] Linux 2.6.29-rc1
# good: [4a6908a3a050aacc9c3a2f36b276b46c0629ad91] Linux 2.6.28
git bisect start 'v2.6.29-rc1' 'v2.6.28' '--' 'net/wireless/mac80211' '=
drivers/net/wireless'
# bad: [54ac218ae676931813169e0ca074aca2e4adee38] rtl8187: fix 8187B th=
roughput regression
git bisect bad 54ac218ae676931813169e0ca074aca2e4adee38
# bad: [154662a6356ec3ccfea0a22218cf149220ea6373] ath9k: Remove unneces=
sary TSF reset
git bisect bad 154662a6356ec3ccfea0a22218cf149220ea6373
# bad: [9387b7caf3049168fc97a8a9111af8fe2143af18] wireless: use individ=
ual buffers for printing ssid values
git bisect bad 9387b7caf3049168fc97a8a9111af8fe2143af18
# good: [faf3994a9f65fd95a68bbcc03c318a427cd1e7d3] airo: Kill directly =
reference of netdev->priv
git bisect good faf3994a9f65fd95a68bbcc03c318a427cd1e7d3
# bad: [9de5776ff33a006b864341a6ec8d31f1a3c628cf] p54: p54: refactor p5=
4_rx_frame_sent
git bisect bad 9de5776ff33a006b864341a6ec8d31f1a3c628cf
# bad: [3257e5d4eb418e4656542207720aef5f0f547701] iwlwifi: remove host =
commands structures from iwl_cmd
git bisect bad 3257e5d4eb418e4656542207720aef5f0f547701
# bad: [5c7f9b7363bfd10e40cf1a28dfc9048417df7028] ipw2x00: change defau=
lt policy for auto-associate
git bisect bad 5c7f9b7363bfd10e40cf1a28dfc9048417df7028

e6a9854b05c1a6af1308fe2b8c68f35abf28a3ee is first bad commit
commit e6a9854b05c1a6af1308fe2b8c68f35abf28a3ee
Author: Johannes Berg=20
Date:   Tue Oct 21 12:40:02 2008 +0200

    mac80211/drivers: rewrite the rate control API

    So after the previous changes we were still unhappy with how
    convoluted the API is and decided to make things simpler for
    everybody. This completely changes the rate control API, now
    taking into account 802.11n with MCS rates and more control,
    most drivers don't support that though.

    Signed-off-by: Felix Fietkau=20
    Signed-off-by: Johannes Berg=20
    Signed-off-by: John W. Linville=20

:040000 040000 d53bb98b64c968e4c7a352d3ada6fe059980ff98 fa431af31a6904e=
9aef5d501b028fef46def07b5 M      drivers
:040000 040000 5508f50aa57a9d8a7247be6dda9c545f032dbe36 7b718ad01d2b737=
1855af224447f3519b2d636c7 M      include
:040000 040000 35f1ef3a607c1614f3c157446cfd3d8daf102ce2 39f88cd0644e67e=
f4fb3e69d2e80f14687ac3641 M      net


_________________________________________________________________
 25GB of FREE Online Storage =96 Find out more
http://clk.atdmt.com/UKM/go/134665320/direct/01/--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html