| Message ID | 4DD074E3.3090502@lwfinger.net (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Larry Finger <Larry.Finger@lwfinger.net> writes: > Could you please try the attached patch to see if it improves your > throughput? Certainly. Can I patch one of the linux-wireless trees, or should I get the source and build the whole kernel? > In addition, please file a Bugzilla report for this problem at > http:bugzilla.kernel.org. Will do. Thanks
On 05/15/2011 09:26 PM, Rob Browning wrote: > Larry Finger<Larry.Finger@lwfinger.net> writes: > >> Could you please try the attached patch to see if it improves your >> throughput? > > Certainly. Can I patch one of the linux-wireless trees, or should I get > the source and build the whole kernel? > >> In addition, please file a Bugzilla report for this problem at >> http:bugzilla.kernel.org. You could patch either the linux-2.6 kernel (2.6.39-rc7), the wireless-testing git tree, or get the source from your distro. You will have to build the entire kernel as I do not have the necessary make files to build the driver as an out of kernel module. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Larry Finger <Larry.Finger@lwfinger.net> writes: > You could patch either the linux-2.6 kernel (2.6.39-rc7), the > wireless-testing git tree, or get the source from your distro. You > will have to build the entire kernel as I do not have the necessary > make files to build the driver as an out of kernel module. That patch didn't seem to have an effect -- the receive rate still settles at about 60Kb/s. I patched the Debian linux-2.6 source package and rebuilt the kernel. The Debian kernel appeared to already have the wifi.h diff. Please let me know if I can help further. Thanks
On 05/16/2011 12:18 AM, Rob Browning wrote: > Larry Finger<Larry.Finger@lwfinger.net> writes: > >> You could patch either the linux-2.6 kernel (2.6.39-rc7), the >> wireless-testing git tree, or get the source from your distro. You >> will have to build the entire kernel as I do not have the necessary >> make files to build the driver as an out of kernel module. > > That patch didn't seem to have an effect -- the receive rate still > settles at about 60Kb/s. > > I patched the Debian linux-2.6 source package and rebuilt the kernel. > The Debian kernel appeared to already have the wifi.h diff. > > Please let me know if I can help further. Strange. With that patch in my system running with the current wireless-testing kernel, I get 19.8 Mbps download and 17.3 Mbps upload using tcpperf. The box at the other end is wired to my router/AP. The wireless connection is configured for 270 Mbps, thus rtl8192cu is not driving it at full rates, but that performance should be satisfactory. Please run the following command for a couple of minutes to see what rate you get: wget http://ftp.utexas.edu/opensuse/factory/iso/openSUSE-NET-x86_64-Build0018-Media.iso That mirror might not be the best one for you to use, but that should be the best one to duplicate my results. On my system, the instantaneous download rate ranges between 250 and 700 K/s. Without the patch, the rate is 48 K/s. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Larry Finger <Larry.Finger@lwfinger.net> writes: > Strange. With that patch in my system running with the current > wireless-testing kernel, I get 19.8 Mbps download and 17.3 Mbps upload > using tcpperf. The box at the other end is wired to my router/AP. The > wireless connection is configured for 270 Mbps, thus rtl8192cu is not > driving it at full rates, but that performance should be satisfactory. > > Please run the following command for a couple of minutes to see what rate you get: > > wget > http://ftp.utexas.edu/opensuse/factory/iso/openSUSE-NET-x86_64-Build0018-Media.iso So that command ran at essentially the rates you report for 10-20 seconds. Then I killed it and tried another test I'd been using, which was to lftp to ftp.kernel.org and get -c linux-2.6.39-rc7.tar.bz2. That transfer started at a high rate, but settled fairly quickly at about 60KB/s. So I killed that transfer and restarted the wget, and it ran steadily at ~60KB/s. One question. While I'm fairly certain that I'm running your patch, would there be an easy way for me to be certain? Perhaps I could add a log message? Thanks
Rob Browning <rlb@defaultvalue.org> writes: > So that command ran at essentially the rates you report for 10-20 > seconds. Then I killed it and tried another test I'd been using, which > was to lftp to ftp.kernel.org and get -c linux-2.6.39-rc7.tar.bz2. That > transfer started at a high rate, but settled fairly quickly at about > 60KB/s. So I killed that transfer and restarted the wget, and it ran > steadily at ~60KB/s. In case it helps, it also looks like the 60KB/s is an aggregate limit. Once it gets into the "lower bandwidth" state, if I run multiple transfers, the total won't go above that.
On 05/16/2011 10:57 PM, Rob Browning wrote: > Rob Browning<rlb@defaultvalue.org> writes: > >> So that command ran at essentially the rates you report for 10-20 >> seconds. Then I killed it and tried another test I'd been using, which >> was to lftp to ftp.kernel.org and get -c linux-2.6.39-rc7.tar.bz2. That >> transfer started at a high rate, but settled fairly quickly at about >> 60KB/s. So I killed that transfer and restarted the wget, and it ran >> steadily at ~60KB/s. > > In case it helps, it also looks like the 60KB/s is an aggregate limit. > Once it gets into the "lower bandwidth" state, if I run multiple > transfers, the total won't go above that. I can duplicate your result. To me, it appears to be a problem with bufferbloat. If that is correct, then there is little I can do with rtl8192cu to fix the problem. I see exactly the same slow rate with rt2800usb using an Ralink RT3070 device. In addition, I see that rate when connected to my router with a wired 100 Mbps connection. What up/down rates do you see if you test with www.speedtest.net? I get 0.48 Mbps up and 12.03 Mbps down. The up rate is a little slower than the 512 Kbps that my ISP provides. My nominal down rate is 7 Mbps with burst rates above 10 if the bandwidth is available. Apparently it was this morning. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Larry Finger <Larry.Finger@lwfinger.net> writes: > I can duplicate your result. To me, it appears to be a problem with > bufferbloat. If that is correct, then there is little I can do with > rtl8192cu to fix the problem. I see exactly the same slow rate with > rt2800usb using an Ralink RT3070 device. In addition, I see that rate > when connected to my router with a wired 100 Mbps connection. I suppose that's possible, but I get much higher rates (300K/s+) when connecting to the same AP using the built-in wireless chipset (BCM4322) from another, very similar laptop, and 6.0Mbps when testing from a third client. I also get 800K/s+ when running the wget command you suggested over a wired connection to my primary router. Unfortunately, can't double-check the second laptop's wireless rate right now, but it got 300K/s+ for a long time, and I just tested the 6Mbps client. It was only when I migrated to the newer laptop and the rtl8192cu usb adapter that I saw the much slower ~60K/s rate. Thanks again
I just tested Debian's 2.6.38-1 kernel, and it has the same problem, though I just noticed something potentially interesting. Right after booting the system, I started a wget which ran at a steady 800+K/s. Then I started an "lftp get -c" to grab a kernel image, and both connections settled at about 400K/s. After a minute or so, I killed the ftp connection; from then on all transfers were limited to 60K/s. Now that I think about it, that's consistent with what I've seen up to this point. Hope this helps
Rob Browning <rlb@defaultvalue.org> writes: > Rob Browning <rlb@defaultvalue.org> writes: > >> So that command ran at essentially the rates you report for 10-20 >> seconds. Then I killed it and tried another test I'd been using, which >> was to lftp to ftp.kernel.org and get -c linux-2.6.39-rc7.tar.bz2. That >> transfer started at a high rate, but settled fairly quickly at about >> 60KB/s. So I killed that transfer and restarted the wget, and it ran >> steadily at ~60KB/s. > > In case it helps, it also looks like the 60KB/s is an aggregate limit. > Once it gets into the "lower bandwidth" state, if I run multiple > transfers, the total won't go above that. As another data point, I just tested the same device on a second machine (a desktop), and saw the same behavior -- initially high transfer rates trailing off to about 60K/s. Thanks
Rob Browning <rlb@defaultvalue.org> writes: > As another data point, I just tested the same device on a second machine > (a desktop), and saw the same behavior -- initially high transfer rates > trailing off to about 60K/s. ...and another data point. Just to be sure it wasn't that particular usb device, I got another that I think is the same hardware (this time the Airlink 101), and I see exactly the same behavior. Next I'll try a different access point -- I'll let you know what I find. And if there's anything else I can do to help test, please let me know. Thanks
Rob Browning <rlb@defaultvalue.org> writes: > Next I'll try a different access point -- I'll let you know what I find. > And if there's anything else I can do to help test, please let me know. Instead, I was able to test an ath9k_htc based adapter (netgear n150), which doesn't appear to have trouble in the same environment, but I'd still prefer to use the much smaller rtl8192cu device if we can figure out what's wrong. Thanks
Rob Browning <rlb@defaultvalue.org> writes: > Instead, I was able to test an ath9k_htc based adapter (netgear n150), > which doesn't appear to have trouble in the same environment, but I'd > still prefer to use the much smaller rtl8192cu device if we can figure > out what's wrong. Actually, I just realized I quoted the wrong model number above. The device that works well is the WNA1100. The rtl8192cu devices still struggle, after a short initial period of reasonable behavior. Thanks
Index: linux-2.6/drivers/net/wireless/rtlwifi/rtl8192cu/dm.c =================================================================== --- linux-2.6.orig/drivers/net/wireless/rtlwifi/rtl8192cu/dm.c +++ linux-2.6/drivers/net/wireless/rtlwifi/rtl8192cu/dm.c @@ -34,6 +34,27 @@ #include "phy.h" #include "dm.h" +static void _rtl92c_dm_restore_power_index(struct ieee80211_hw *hw) +{ + struct rtl_priv *rtlpriv = rtl_priv(hw); + u8 index; + u32 power_index_reg[6] = {0xc90, 0xc91, 0xc92, 0xc98, 0xc99, 0xc9a}; + + for(index = 0; index< 6; index++) + rtl_write_byte(rtlpriv, power_index_reg[index], + rtlpriv->dm.power_index_backup[index]); +} + +static void _rtl92c_dm_write_power_index(struct ieee80211_hw *hw,u8 value) +{ + struct rtl_priv *rtlpriv = rtl_priv(hw); + u8 index; + u32 power_index_reg[6] = {0xc90, 0xc91, 0xc92, 0xc98, 0xc99, 0xc9a}; + + for(index = 0; index< 6; index++) + rtl_write_byte(rtlpriv, power_index_reg[index], value); +} + void rtl92cu_dm_dynamic_txpower(struct ieee80211_hw *hw) { struct rtl_priv *rtlpriv = rtl_priv(hw); @@ -107,6 +128,17 @@ void rtl92cu_dm_dynamic_txpower(struct i ("PHY_SetTxPowerLevel8192S() Channel = %d\n", rtlphy->current_channel)); rtl92c_phy_set_txpower_level(hw, rtlphy->current_channel); + + if(rtlpriv->dm.dynamic_txhighpower_lvl == TXHIGHPWRLEVEL_NORMAL) + /* HP1 -> Normal or HP2 -> Normal */ + _rtl92c_dm_restore_power_index(hw); + else if(rtlpriv->dm.dynamic_txhighpower_lvl == + TXHIGHPWRLEVEL_LEVEL1) + _rtl92c_dm_write_power_index(hw,0x14); + else if(rtlpriv->dm.dynamic_txhighpower_lvl == + TXHIGHPWRLEVEL_LEVEL2) + _rtl92c_dm_write_power_index(hw,0x10); + } rtlpriv->dm.last_dtp_lvl = rtlpriv->dm.dynamic_txhighpower_lvl; Index: linux-2.6/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c =================================================================== --- linux-2.6.orig/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c +++ linux-2.6/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c @@ -503,11 +503,33 @@ static void rtl92c_dm_dig(struct ieee802 } +static void _rtl92c_dm_save_power_index(struct ieee80211_hw *hw) +{ + struct rtl_priv *rtlpriv = rtl_priv(hw); + u8 index; + u32 power_index_reg[6] = {0xc90, 0xc91, 0xc92, 0xc98, 0xc99, 0xc9a}; + + for(index = 0; index< 6; index++) + rtlpriv->dm.power_index_backup[index] = + rtl_read_byte(rtlpriv, power_index_reg[index]); +} + static void rtl92c_dm_init_dynamic_txpower(struct ieee80211_hw *hw) { struct rtl_priv *rtlpriv = rtl_priv(hw); + struct rtl_hal *rtlhal = rtl_hal(rtlpriv); + struct rtl_efuse *rtlefuse = rtl_efuse(rtlpriv); - rtlpriv->dm.dynamic_txpower_enable = false; + if (rtlhal->interface == INTF_PCI) { + rtlpriv->dm.dynamic_txpower_enable = false; + } else { + if (rtlefuse->external_pa) { + _rtl92c_dm_save_power_index(hw); + rtlpriv->dm.dynamic_txpower_enable = true; + } else { + rtlpriv->dm.dynamic_txpower_enable = false; + } + } rtlpriv->dm.last_dtp_lvl = TXHIGHPWRLEVEL_NORMAL; rtlpriv->dm.dynamic_txhighpower_lvl = TXHIGHPWRLEVEL_NORMAL; @@ -541,8 +563,6 @@ static void rtl92c_dm_pwdb_monitor(struc u8 h2c_parameter[3] = { 0 }; - return; - if (tmpentry_max_pwdb != 0) { rtlpriv->dm.entry_max_undecoratedsmoothed_pwdb = tmpentry_max_pwdb; Index: linux-2.6/drivers/net/wireless/rtlwifi/wifi.h =================================================================== --- linux-2.6.orig/drivers/net/wireless/rtlwifi/wifi.h +++ linux-2.6/drivers/net/wireless/rtlwifi/wifi.h @@ -1105,6 +1105,7 @@ struct rtl_dm { bool disable_tx_int; char ofdm_index[2]; char cck_index; + u8 power_index_backup[6]; }; #define EFUSE_MAX_LOGICAL_SIZE 256