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

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

[Hin-Tak Leung]

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)?


      

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

[Herton Ronaldo Krzesinski]

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

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

[Hin-Tak Leung]

--- On Mon, 10/11/08, Herton Ronaldo Krzesinski <herton@mandriva.com.br> 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  


      

throughput problem/bisect with rtl8187B

[Hin-Tak Leung]

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 <herton@mandriva.com.br>
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.
-----------------


      

Re: throughput problem/bisect with rtl8187B

[Herton Ronaldo Krzesinski]

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

Re: throughput problem/bisect with rtl8187B

[Hin-Tak Leung]

--- On Tue, 11/11/08, Herton Ronaldo Krzesinski <herton@mandriva.com.br> 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


      

Re: throughput problem/bisect with rtl8187B

[Larry Finger]

Hin-Tak Leung wrote:
> --- On Tue, 11/11/08, Herton Ronaldo Krzesinski <herton@mandriva.com.br> 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

Re: throughput problem/bisect with rtl8187B

[Hin-Tak Leung]

--- On Tue, 11/11/08, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Hin-Tak Leung wrote:
> > --- On Tue, 11/11/08, Herton Ronaldo Krzesinski
> <herton@mandriva.com.br> 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



      

Re: throughput problem/bisect with rtl8187B

[Herton Ronaldo Krzesinski]

On Tuesday 11 November 2008 14:48:52 Hin-Tak Leung wrote:
> --- On Tue, 11/11/08, Herton Ronaldo Krzesinski <herton@mandriva.com.br> 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

Re: throughput problem/bisect with rtl8187B

[Larry Finger]

Herton Ronaldo Krzesinski wrote:
> On Tuesday 11 November 2008 14:48:52 Hin-Tak Leung wrote:
>> --- On Tue, 11/11/08, Herton Ronaldo Krzesinski <herton@mandriva.com.br> 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

Re: throughput problem/bisect with rtl8187B

[Hin-Tak Leung]

--- On Tue, 11/11/08, Herton Ronaldo Krzesinski <herton@mandriva.com.br> 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,
------------------------






      

Re: throughput problem/bisect with rtl8187B

[Herton Ronaldo Krzesinski]

On Tuesday 11 November 2008 23:12:42 Hin-Tak Leung wrote:
> --- On Tue, 11/11/08, Herton Ronaldo Krzesinski <herton@mandriva.com.br> 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

Re: throughput problem/bisect with rtl8187B

[Larry Finger]

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

Re: throughput problem/bisect with rtl8187B

[Hin-Tak Leung]

--- On Wed, 12/11/08, Larry Finger <Larry.Finger@lwfinger.net> 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



      

Re: throughput problem/bisect with rtl8187B

[Herton Ronaldo Krzesinski]

On Wednesday 12 November 2008 22:06:16 Hin-Tak Leung wrote:
> --- On Wed, 12/11/08, Larry Finger <Larry.Finger@lwfinger.net> 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