(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/-
(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/-
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: [email protected]
> To: [email protected]
> CC: [email protected]
> 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/-
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
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
[email protected] might be all we have. Be ready.
On Mon, Mar 16, 2009 at 2:40 PM, Larry Finger <[email protected]> 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...