2008-11-09 06:01:05

by Hin-Tak Leung

[permalink] [raw]
Subject: throughput problem Re: [RFC/RFT PATCH v2 2/2] rtl8187: feedback transmitted packets using tx close descriptor for 8187B

Without any additional modification, just compat-wireless and wireles-testing v2.6.28-rc3-4651-gb53846d has a preculiar problem - the rate is
stuck at 54Mb (known issue to be addressed by Herton's feedback patch) as shown by iwconfig, but sftp doesn't transfer file much higher than 30-40kB/s.
blowing away /lib/module/`uname -r`/updates (i.e. reverting to the as shipped 2.6.27.5 rtl8187 & mac80211 ) gives easily over 10 times that
speed. anybody seen this problem (with rtl8187 or other mac80211 driver
with wireless testing)?





2008-11-12 21:35:13

by Larry Finger

[permalink] [raw]
Subject: Re: throughput problem/bisect with rtl8187B

Herton Ronaldo Krzesinski wrote:
> Ok, Looks like sifs or eifs setting then expect values in another format or
> have a different meaning may be (or just cause some hw bug), it's strange,
> I suspect sifs value is the culprit. In the patch I just reverted to values vendor
> driver uses, in it difs remains the same, just eifs isn't changed for short slot
> case and kept with a default value (along with what is supposed to be ack
> timeout register), and sifs set to 0x22. Please try just the following change
> to isolate that the SIFS setting caused the throughput issue:
>
> diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> index d49f2a7..c0392e4 100644
> --- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
> +++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> @@ -924,7 +924,7 @@ static void rtl8187_conf_erp(struct rtl8187_priv *priv, bool use_short_slot,
> difs = 0x32;
> eifs = 0x5b;
> }
> - rtl818x_iowrite8(priv, &priv->map->SIFS, 0xa);
> + rtl818x_iowrite8(priv, &priv->map->SIFS, 0x22);
> rtl818x_iowrite8(priv, &priv->map->SLOT, slot_time);
> rtl818x_iowrite8(priv, &priv->map->DIFS, difs);

This patch gives me the best performance yet. I get about 1.0 MB/s download and
580 KB/s upload with a 25 MB file using sftp.

Larry

2008-11-13 00:06:19

by Hin-Tak Leung

[permalink] [raw]
Subject: Re: throughput problem/bisect with rtl8187B

--- On Wed, 12/11/08, Larry Finger <[email protected]> wrote:
> Herton Ronaldo Krzesinski wrote:
> > Ok, Looks like sifs or eifs setting then expect values
> in another format or
> > have a different meaning may be (or just cause some hw
> bug), it's strange,
> > I suspect sifs value is the culprit. In the patch I
> just reverted to values vendor
> > driver uses, in it difs remains the same, just eifs
> isn't changed for short slot
> > case and kept with a default value (along with what is
> supposed to be ack
> > timeout register), and sifs set to 0x22. Please try
> just the following change
> > to isolate that the SIFS setting caused the throughput
> issue:
> >
> > diff --git
> a/drivers/net/wireless/rtl818x/rtl8187_dev.c
> b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > index d49f2a7..c0392e4 100644
> > --- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > +++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > @@ -924,7 +924,7 @@ static void
> rtl8187_conf_erp(struct rtl8187_priv *priv, bool
> use_short_slot,
> > difs = 0x32;
> > eifs = 0x5b;
> > }
> > - rtl818x_iowrite8(priv, &priv->map->SIFS,
> 0xa);
> > + rtl818x_iowrite8(priv, &priv->map->SIFS,
> 0x22);
> > rtl818x_iowrite8(priv, &priv->map->SLOT,
> slot_time);
> > rtl818x_iowrite8(priv, &priv->map->DIFS,
> difs);
>
> This patch gives me the best performance yet. I get about
> 1.0 MB/s download and
> 580 KB/s upload with a 25 MB file using sftp.

Yes, confirming this one number fixes the throughput problem I had. And I can also confirm that wireless-testing + this oneliner seems to be better than 2.6.27.

I tried it alone on top of wireless-testing, and together with
the conf_tx and feedback patches.

Thanks for putting time into this!

Hin-Tak





2008-11-11 08:39:42

by Hin-Tak Leung

[permalink] [raw]
Subject: throughput problem/bisect with rtl8187B

Hi Herton,

I bisected through recent wireless-testing, and found the commit which results in my throughput problem - it is one of yours :-(. Can you and also possibly Larry give this a try: transfering some large files (>50MB) before and after reverting this particular commit, and see what sftp says about the transfer rate? You need to let sftp keep going for a while to see what rate it settles at. (>50MB should do, so a kernel source tarball
would be appropriate). The difference is quite obvious in my case -
<60kB/s, and 7x - 10x that if I revert this commit.

The commit is all magic numbers, so if you see the problem, can you please
have a look and check the numbers?

Thanks,
Hin-Tak

-------------
>From 9c1493477380e51d152a2e0ef560291d7445e9ea Mon Sep 17 00:00:00 2001
From: Herton Ronaldo Krzesinski <[email protected]>
Date: Mon, 13 Oct 2008 18:11:00 +0000
Subject: [PATCH] rtl8187: add short slot handling for 8187B

This change adds short slot handling for 8187B variant of rtl8187 chips.
Some things to note about changes done:
* Values used are chosen to met 802.11-2007 spec. This raised a question
about SIFS value used with 8187L: 0x22 (34) doesn't match any spec
value. For now just don't change 8187L, but is something to be
looked at.
* On 8187B, the location of EIFS register is at the same place as BRSR+1
of struct rtl818x_csr. Unfortunately there is no clean way to
accomodate 8187B differences currently, just use address of BRSR+1 and
comment about it. The same thing happens for Ack timeout register,
that is on CARRIER_SENSE_COUNTER location of 8187L. The eifs and ack
timeout values are in units of 4us. All these registers information
was gathered from references being the vendor gpl driver and 8180
datasheet, unfortunately there is no information about this on 8187B
datasheet. Also the ack timeout value was inspired by the same
calculation as done on rt2x00.
-----------------




2008-11-11 19:42:18

by Larry Finger

[permalink] [raw]
Subject: Re: throughput problem/bisect with rtl8187B

Herton Ronaldo Krzesinski wrote:
> On Tuesday 11 November 2008 14:48:52 Hin-Tak Leung wrote:
>> --- On Tue, 11/11/08, Herton Ronaldo Krzesinski <[email protected]> wrote:
>>
>> <snipped>
>>> Lets try to identify what part is broken, I guess is this,
>>> can you try this
>>> patch on latest wireless-testing?
>> Tried it, no improvement.
>>
>> Can you /did you see any problem similiar to mine with throughput on your system(s)?
>
> Nope, here I can scp a large file from another machine, rate stabilizes at 6M
> with minstrel, transfer rate stays around 400-480KB/s, and drops/fluctuates
> below 400KB/s usually (must be affected by other network traffic, I can't do
> the test now on a clean environment).
>
> Please check this patch to see if things improve, if not, can you check with
> the patch I posted earlier, "Add conf_tx callback and use it to configure tx
> queues of 8187L/8187B.", if things improve? (I think you already checked, but
> just in case you tested only the rate control related patch)

With patch #2 I get an upload speed of 463 KB/s, which is the same as before.

Hin-tak: If you use "minstrel" as the rate-control algorithm, mac80211 says so.
You are using "pid".

Larry

2008-11-11 17:17:41

by Hin-Tak Leung

[permalink] [raw]
Subject: Re: throughput problem/bisect with rtl8187B

--- On Tue, 11/11/08, Larry Finger <[email protected]> wrote:
> Hin-Tak Leung wrote:
> > --- On Tue, 11/11/08, Herton Ronaldo Krzesinski
> <[email protected]> wrote:
> >
> > <snipped>
> >> Lets try to identify what part is broken, I guess
> is this,
> >> can you try this
> >> patch on latest wireless-testing?
> >
> > Tried it, no improvement.
> >
> > Can you /did you see any problem similiar to mine with
> throughput on your system(s)?
>
> I may see a slight improvement with the patch. Throughput
> using sftp goes from
> 386 KB/s to 460 KB/s when I put in the patch, but there is
> some jitter and that
> change may not be significant.
>
> What rate-setting method are you using? I'm using
> "pid", which rapidly goes to
> 54 Mb/s on my device. I tried using minstrel and found that
> it gets an
> occasional burst of speed, but that it usually stays at 1
> Mb/s.

I am using "pid" according to dmesg (does "minstrel" says it is choosen if it is?) - I haven't done anything so it should be using the default rc method. What I found is that the rate reported by iwconfig (I also get 54Mb/s, without the feedback patch) has nothing to do with how fast I
can move actual data...

Hin-Tak





Subject: Re: throughput problem/bisect with rtl8187B

On Tuesday 11 November 2008 14:48:52 Hin-Tak Leung wrote:
> --- On Tue, 11/11/08, Herton Ronaldo Krzesinski <[email protected]> wrote:
>
> <snipped>
> > Lets try to identify what part is broken, I guess is this,
> > can you try this
> > patch on latest wireless-testing?
>
> Tried it, no improvement.
>
> Can you /did you see any problem similiar to mine with throughput on your system(s)?

Nope, here I can scp a large file from another machine, rate stabilizes at 6M
with minstrel, transfer rate stays around 400-480KB/s, and drops/fluctuates
below 400KB/s usually (must be affected by other network traffic, I can't do
the test now on a clean environment).

Please check this patch to see if things improve, if not, can you check with
the patch I posted earlier, "Add conf_tx callback and use it to configure tx
queues of 8187L/8187B.", if things improve? (I think you already checked, but
just in case you tested only the rate control related patch)

diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index d49f2a7..a7860b0 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -908,44 +908,28 @@ static int rtl8187_config_interface(struct ieee80211_hw *dev,
return 0;
}

-static void rtl8187_conf_erp(struct rtl8187_priv *priv, bool use_short_slot,
- bool use_short_preamble)
+static void rtl8187_conf_erp(struct rtl8187_priv *priv, bool use_short_slot)
{
if (priv->is_rtl8187b) {
- u8 difs, eifs, slot_time;
- u16 ack_timeout;
+ u8 difs, slot_time;

- if (use_short_slot) {
+ if (use_short_slot)
slot_time = 0x9;
- difs = 0x1c;
- eifs = 0x53;
- } else {
+ else
slot_time = 0x14;
- difs = 0x32;
- eifs = 0x5b;
- }
- rtl818x_iowrite8(priv, &priv->map->SIFS, 0xa);
+ difs = 10 + 2 * slot_time;
+ rtl818x_iowrite8(priv, &priv->map->SIFS, 0x22);
rtl818x_iowrite8(priv, &priv->map->SLOT, slot_time);
rtl818x_iowrite8(priv, &priv->map->DIFS, difs);

/*
- * BRSR+1 on 8187B is in fact EIFS register
- * Value in units of 4 us
+ * On 8187B:
+ * - BRSR+1 is in fact EIFS register
+ * - CARRIER_SENSE_COUNTER is ack timeout register
+ * Values in units of 4 us
*/
- rtl818x_iowrite8(priv, (u8 *)&priv->map->BRSR + 1, eifs);
-
- /*
- * For 8187B, CARRIER_SENSE_COUNTER is in fact ack timeout
- * register. In units of 4 us like eifs register
- * ack_timeout = ack duration + plcp + difs + preamble
- */
- ack_timeout = 112 + 48 + difs;
- if (use_short_preamble)
- ack_timeout += 72;
- else
- ack_timeout += 144;
- rtl818x_iowrite8(priv, &priv->map->CARRIER_SENSE_COUNTER,
- DIV_ROUND_UP(ack_timeout, 4));
+ rtl818x_iowrite8(priv, (u8 *)&priv->map->BRSR + 1, 0x5b);
+ rtl818x_iowrite8(priv, &priv->map->CARRIER_SENSE_COUNTER, 0x5b);
} else {
rtl818x_iowrite8(priv, &priv->map->SIFS, 0x22);
if (use_short_slot) {
@@ -969,9 +953,8 @@ static void rtl8187_bss_info_changed(struct ieee80211_hw *dev,
{
struct rtl8187_priv *priv = dev->priv;

- if (changed & (BSS_CHANGED_ERP_SLOT | BSS_CHANGED_ERP_PREAMBLE))
- rtl8187_conf_erp(priv, info->use_short_slot,
- info->use_short_preamble);
+ if (changed & BSS_CHANGED_ERP_SLOT)
+ rtl8187_conf_erp(priv, info->use_short_slot);
}

static void rtl8187_configure_filter(struct ieee80211_hw *dev,


>
> Hin-Tak

--
[]'s
Herton

2008-11-11 17:01:11

by Larry Finger

[permalink] [raw]
Subject: Re: throughput problem/bisect with rtl8187B

Hin-Tak Leung wrote:
> --- On Tue, 11/11/08, Herton Ronaldo Krzesinski <[email protected]> wrote:
>
> <snipped>
>> Lets try to identify what part is broken, I guess is this,
>> can you try this
>> patch on latest wireless-testing?
>
> Tried it, no improvement.
>
> Can you /did you see any problem similiar to mine with throughput on your system(s)?

I may see a slight improvement with the patch. Throughput using sftp goes from
386 KB/s to 460 KB/s when I put in the patch, but there is some jitter and that
change may not be significant.

What rate-setting method are you using? I'm using "pid", which rapidly goes to
54 Mb/s on my device. I tried using minstrel and found that it gets an
occasional burst of speed, but that it usually stays at 1 Mb/s.

Larry

Subject: Re: throughput problem/bisect with rtl8187B

On Wednesday 12 November 2008 22:06:16 Hin-Tak Leung wrote:
> --- On Wed, 12/11/08, Larry Finger <[email protected]> wrote:
> > Herton Ronaldo Krzesinski wrote:
> > > Ok, Looks like sifs or eifs setting then expect values
> > in another format or
> > > have a different meaning may be (or just cause some hw
> > bug), it's strange,
> > > I suspect sifs value is the culprit. In the patch I
> > just reverted to values vendor
> > > driver uses, in it difs remains the same, just eifs
> > isn't changed for short slot
> > > case and kept with a default value (along with what is
> > supposed to be ack
> > > timeout register), and sifs set to 0x22. Please try
> > just the following change
> > > to isolate that the SIFS setting caused the throughput
> > issue:
> > >
> > > diff --git
> > a/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > > index d49f2a7..c0392e4 100644
> > > --- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > > +++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
> > > @@ -924,7 +924,7 @@ static void
> > rtl8187_conf_erp(struct rtl8187_priv *priv, bool
> > use_short_slot,
> > > difs = 0x32;
> > > eifs = 0x5b;
> > > }
> > > - rtl818x_iowrite8(priv, &priv->map->SIFS,
> > 0xa);
> > > + rtl818x_iowrite8(priv, &priv->map->SIFS,
> > 0x22);
> > > rtl818x_iowrite8(priv, &priv->map->SLOT,
> > slot_time);
> > > rtl818x_iowrite8(priv, &priv->map->DIFS,
> > difs);
> >
> > This patch gives me the best performance yet. I get about
> > 1.0 MB/s download and
> > 580 KB/s upload with a 25 MB file using sftp.
>
> Yes, confirming this one number fixes the throughput problem I had. And I can also confirm that wireless-testing + this oneliner seems to be better than 2.6.27.
>
> I tried it alone on top of wireless-testing, and together with
> the conf_tx and feedback patches.
>
> Thanks for putting time into this!

nice, I sent the patch now plus the others pending I had.

>
> Hin-Tak

--
[]'s
Herton

2008-11-11 16:49:00

by Hin-Tak Leung

[permalink] [raw]
Subject: Re: throughput problem/bisect with rtl8187B

--- On Tue, 11/11/08, Herton Ronaldo Krzesinski <[email protected]> wrote:

<snipped>
> Lets try to identify what part is broken, I guess is this,
> can you try this
> patch on latest wireless-testing?

Tried it, no improvement.

Can you /did you see any problem similiar to mine with throughput on your system(s)?

Hin-Tak




Subject: Re: throughput problem/bisect with rtl8187B

On Tuesday 11 November 2008 23:12:42 Hin-Tak Leung wrote:
> --- On Tue, 11/11/08, Herton Ronaldo Krzesinski <[email protected]> wrote:
> > Please check this patch to see if things improve, if not,
> > can you check with
> > the patch I posted earlier, "Add conf_tx callback and
> > use it to configure tx
> > queues of 8187L/8187B.", if things improve? (I think
> > you already checked, but
> > just in case you tested only the rate control related
> > patch)
>
> okay, very good - this one does it. I didn't try the conf_tx callback patch
> when I posted the problem, but I did this time - so I have the conf_tx
> callback patch, feedback patch, and a modified version of this new one, and
> I get decent throughput; reverting the 3rd patch, (ie. just the conf_tx
> callback and feekback transmitted patch) and the throughput is appalling.
> So you can add tested-by me to both the conf_tx and feedback patches, and
> either tested-by or signed-off-by for this version of the 3rd patch (I made
> some small changes just so that it applies on top of the conf_tx patch
> which has a priv->slot_time rather than local slot_time). Sorry about the
> indentation - no doubt you'll polish it up before sending off the three.

Ok, Looks like sifs or eifs setting then expect values in another format or
have a different meaning may be (or just cause some hw bug), it's strange,
I suspect sifs value is the culprit. In the patch I just reverted to values vendor
driver uses, in it difs remains the same, just eifs isn't changed for short slot
case and kept with a default value (along with what is supposed to be ack
timeout register), and sifs set to 0x22. Please try just the following change
to isolate that the SIFS setting caused the throughput issue:

diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index d49f2a7..c0392e4 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -924,7 +924,7 @@ static void rtl8187_conf_erp(struct rtl8187_priv *priv, bool use_short_slot,
difs = 0x32;
eifs = 0x5b;
}
- rtl818x_iowrite8(priv, &priv->map->SIFS, 0xa);
+ rtl818x_iowrite8(priv, &priv->map->SIFS, 0x22);
rtl818x_iowrite8(priv, &priv->map->SLOT, slot_time);
rtl818x_iowrite8(priv, &priv->map->DIFS, difs);


>
> These 3 are tested against v2.6.28-rc4-5168-gaafbf3d (moved on a bit since
> my last tests).
>
> Thanks for looking into this.
>
> Hin-Tak

--
[]'s
Herton

Subject: Re: throughput problem/bisect with rtl8187B

On Tuesday 11 November 2008 06:39:40 Hin-Tak Leung wrote:
> Hi Herton,
>
> I bisected through recent wireless-testing, and found the commit which results in my throughput problem - it is one of yours :-(. Can you and also possibly Larry give this a try: transfering some large files (>50MB) before and after reverting this particular commit, and see what sftp says about the transfer rate? You need to let sftp keep going for a while to see what rate it settles at. (>50MB should do, so a kernel source tarball
> would be appropriate). The difference is quite obvious in my case -
> <60kB/s, and 7x - 10x that if I revert this commit.
>
> The commit is all magic numbers, so if you see the problem, can you please
> have a look and check the numbers?

Lets try to identify what part is broken, I guess is this, can you try this
patch on latest wireless-testing?

diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index d49f2a7..63c796e 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -913,7 +913,6 @@ static void rtl8187_conf_erp(struct rtl8187_priv *priv, bool use_short_slot,
{
if (priv->is_rtl8187b) {
u8 difs, eifs, slot_time;
- u16 ack_timeout;

if (use_short_slot) {
slot_time = 0x9;
@@ -933,19 +932,6 @@ static void rtl8187_conf_erp(struct rtl8187_priv *priv, bool use_short_slot,
* Value in units of 4 us
*/
rtl818x_iowrite8(priv, (u8 *)&priv->map->BRSR + 1, eifs);
-
- /*
- * For 8187B, CARRIER_SENSE_COUNTER is in fact ack timeout
- * register. In units of 4 us like eifs register
- * ack_timeout = ack duration + plcp + difs + preamble
- */
- ack_timeout = 112 + 48 + difs;
- if (use_short_preamble)
- ack_timeout += 72;
- else
- ack_timeout += 144;
- rtl818x_iowrite8(priv, &priv->map->CARRIER_SENSE_COUNTER,
- DIV_ROUND_UP(ack_timeout, 4));
} else {
rtl818x_iowrite8(priv, &priv->map->SIFS, 0x22);
if (use_short_slot) {


>
> Thanks,
> Hin-Tak

--
[]'s
Herton

Subject: Re: throughput problem Re: [RFC/RFT PATCH v2 2/2] rtl8187: feedback transmitted packets using tx close descriptor for 8187B

On Sunday 09 November 2008 04:01:03 Hin-Tak Leung wrote:
> Without any additional modification, just compat-wireless and
> wireles-testing v2.6.28-rc3-4651-gb53846d has a preculiar problem - the
> rate is stuck at 54Mb (known issue to be addressed by Herton's feedback
> patch) as shown by iwconfig, but sftp doesn't transfer file much higher
> than 30-40kB/s. blowing away /lib/module/`uname -r`/updates (i.e. reverting
> to the as shipped 2.6.27.5 rtl8187 & mac80211 ) gives easily over 10 times
> that speed. anybody seen this problem (with rtl8187 or other mac80211
> driver with wireless testing)?

Here I don't get such low transfer rate, may be a regression in
wireless-testing? Try a bisect to see, besides that I don't have other ideas
what could be. BTW, do you checked wireless-testing, so can I add your
tested-by then to the "feedback transmitted packets..." patch? I plan to
submit the final patch to inclusion in wireless-testing soon.

--
[]'s
Herton

2008-11-10 21:55:43

by Hin-Tak Leung

[permalink] [raw]
Subject: Re: throughput problem Re: [RFC/RFT PATCH v2 2/2] rtl8187: feedback transmitted packets using tx close descriptor for 8187B

--- On Mon, 10/11/08, Herton Ronaldo Krzesinski <[email protected]> wrote:

> Here I don't get such low transfer rate, may be a
> regression in
> wireless-testing? Try a bisect to see, besides that I
> don't have other ideas
> what could be. BTW, do you checked wireless-testing, so can
> I add your
> tested-by then to the "feedback transmitted
> packets..." patch? I plan to
> submit the final patch to inclusion in wireless-testing
> soon.

Yes, I suppose I'll need to go the git bisect route to find out what's wrong with the throughput. The "feedback transmitted packets" patch is
good - have it with wireless testing - please send it in with tested-by.

Hin-Tak




2008-11-12 01:12:44

by Hin-Tak Leung

[permalink] [raw]
Subject: Re: throughput problem/bisect with rtl8187B

--- On Tue, 11/11/08, Herton Ronaldo Krzesinski <[email protected]> wrote:

> Please check this patch to see if things improve, if not,
> can you check with
> the patch I posted earlier, "Add conf_tx callback and
> use it to configure tx
> queues of 8187L/8187B.", if things improve? (I think
> you already checked, but
> just in case you tested only the rate control related
> patch)

okay, very good - this one does it. I didn't try the conf_tx callback patch when I posted the problem, but I did this time - so I have the
conf_tx callback patch, feedback patch, and a modified version of this new
one, and I get decent throughput; reverting the 3rd patch, (ie. just the conf_tx callback and feekback transmitted patch) and the throughput is appalling. So you can add tested-by me to both the conf_tx and feedback patches, and either tested-by or signed-off-by for this version of the 3rd patch (I made some small changes just so that it applies on top of the conf_tx patch which has a priv->slot_time rather than local slot_time).
Sorry about the indentation - no doubt you'll polish it up before sending off the three.

These 3 are tested against v2.6.28-rc4-5168-gaafbf3d (moved on a bit since my last tests).

Thanks for looking into this.

Hin-Tak

------------------------------
--- rtl8187_dev.c.orig 2008-11-11 23:49:09.000000000 +0000
+++ rtl8187_dev.c 2008-11-12 00:11:54.000000000 +0000
@@ -1050,45 +1050,29 @@

#define SIFS_TIME 0xa

-static void rtl8187_conf_erp(struct rtl8187_priv *priv, bool use_short_slot,
- bool use_short_preamble)
+static void rtl8187_conf_erp(struct rtl8187_priv *priv, bool use_short_slot)
{
if (priv->is_rtl8187b) {
- u8 difs, eifs;
- u16 ack_timeout;
+ u8 difs;
int queue;

- if (use_short_slot) {
+ if (use_short_slot)
priv->slot_time = 0x9;
- difs = 0x1c;
- eifs = 0x53;
- } else {
+ else
priv->slot_time = 0x14;
- difs = 0x32;
- eifs = 0x5b;
- }
- rtl818x_iowrite8(priv, &priv->map->SIFS, SIFS_TIME);
+ difs = 10 + 2 * priv->slot_time;
+ rtl818x_iowrite8(priv, &priv->map->SIFS, 0x22);
rtl818x_iowrite8(priv, &priv->map->SLOT, priv->slot_time);
rtl818x_iowrite8(priv, &priv->map->DIFS, difs);

/*
- * BRSR+1 on 8187B is in fact EIFS register
- * Value in units of 4 us
+ * On 8187B:
+ * - BRSR+1 is in fact EIFS register
+ * - CARRIER_SENSE_COUNTER is ack timeout register
+ * Values in units of 4 us
*/
- rtl818x_iowrite8(priv, (u8 *)&priv->map->BRSR + 1, eifs);
-
- /*
- * For 8187B, CARRIER_SENSE_COUNTER is in fact ack timeout
- * register. In units of 4 us like eifs register
- * ack_timeout = ack duration + plcp + difs + preamble
- */
- ack_timeout = 112 + 48 + difs;
- if (use_short_preamble)
- ack_timeout += 72;
- else
- ack_timeout += 144;
- rtl818x_iowrite8(priv, &priv->map->CARRIER_SENSE_COUNTER,
- DIV_ROUND_UP(ack_timeout, 4));
+ rtl818x_iowrite8(priv, (u8 *)&priv->map->BRSR + 1, 0x5b);
+ rtl818x_iowrite8(priv, &priv->map->CARRIER_SENSE_COUNTER, 0x5b);

for (queue = 0; queue < 4; queue++)
rtl818x_iowrite8(priv, (u8 *) rtl8187b_ac_addr[queue],
@@ -1115,9 +1099,8 @@
{
struct rtl8187_priv *priv = dev->priv;

- if (changed & (BSS_CHANGED_ERP_SLOT | BSS_CHANGED_ERP_PREAMBLE))
- rtl8187_conf_erp(priv, info->use_short_slot,
- info->use_short_preamble);
+ if (changed & BSS_CHANGED_ERP_SLOT)
+ rtl8187_conf_erp(priv, info->use_short_slot);
}

static void rtl8187_configure_filter(struct ieee80211_hw *dev,
------------------------