Hi,
Recently I started using kernel 3.19 from Ubuntu ppa and I noticed a
big drop in Wifi throughput. After some investigation I found that my
router was reporting the AMPDU factor changed from 3(in 3.18) to 0(in 3.19):
cat
/sys/kernel/debug/ieee80211/phy1/netdev:wlan1/stations/c4:xx:xx:xx:xx:xx/ht_capa:
ht supported
cap: 0x1066
HT20/HT40
Dynamic SM Power Save
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
ampdu factor/density: 3/5
MCS mask: ff ff 00 00 00 00 00 00 00 00
MCS tx params: 1
ht supported
cap: 0x1066
HT20/HT40
Dynamic SM Power Save
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
ampdu factor/density: 0/5
MCS mask: ff ff 00 00 00 00 00 00 00 00
MCS tx params: 1
In my setup this means a 50% drop in downstream throughput(from
160Mbit/s to 80Mbit/s)
I tracked down the offending commit and it seems this is it:
iwlwifi: change max HT and VHT A-MPDU exponent
c064ddf318aa51647a30108f7cd151c208c62eef
A new mechanism was created to have per device ampd_factor:
- ht_info->ampdu_factor = IEEE80211_HT_MAX_AMPDU_64K;
+ ht_info->ampdu_factor = cfg->max_ht_ampdu_exponent;
however the max_ht_ampdu_exponent is not set for any of the iwl-6000
devices(including mine Intel Corporation Centrino Advanced-N 6235)
#define IWL_DEVICE_6035 \
.fw_name_pre = IWL6030_FW_PRE, \
.ucode_api_max = IWL6035_UCODE_API_MAX, \
.ucode_api_ok = IWL6035_UCODE_API_OK, \
.ucode_api_min = IWL6035_UCODE_API_MIN, \
.device_family = IWL_DEVICE_FAMILY_6030, \
.max_inst_size = IWL60_RTC_INST_SIZE, \
.max_data_size = IWL60_RTC_DATA_SIZE, \
.nvm_ver = EEPROM_6030_EEPROM_VERSION, \
.nvm_calib_ver = EEPROM_6030_TX_POWER_VERSION, \
.base_params = &iwl6000_g2_base_params, \
.eeprom_params = &iwl6000_eeprom_params, \
.led_mode = IWL_LED_RF_STATE
Since the original value of IEEE80211_HT_MAX_AMPDU_64K I would
suggest adding it to some iwl-6000 devices.
I did not submit any patches because I have no idea if there are
device which would not support this feature, however it worked before
with default value set to IEEE80211_HT_MAX_AMPDU_64K so I guess it must
be supported.
Regards,
Valentin
Hi again (fixed your address, I hope it will not bounce this time...)
Please test the patch attached.
On Sun, 2015-02-22 at 14:19 +0200, Emmanuel Grumbach wrote:
> Hi,
>
> On Sun, 2015-02-22 at 14:15 +0200, Valentin Manea wrote:
> > Hi,
> >
> > Recently I started using kernel 3.19 from Ubuntu ppa and I noticed a
> > big drop in Wifi throughput. After some investigation I found that my
> > router was reporting the AMPDU factor changed from 3(in 3.18) to 0(in 3.19):
> > cat
> > /sys/kernel/debug/ieee80211/phy1/netdev:wlan1/stations/c4:xx:xx:xx:xx:xx/ht_capa:
> > ht supported
> > cap: 0x1066
> > HT20/HT40
> > Dynamic SM Power Save
> > RX HT20 SGI
> > RX HT40 SGI
> > No RX STBC
> > Max AMSDU length: 3839 bytes
> > DSSS/CCK HT40
> > ampdu factor/density: 3/5
> > MCS mask: ff ff 00 00 00 00 00 00 00 00
> > MCS tx params: 1
> >
> > ht supported
> > cap: 0x1066
> > HT20/HT40
> > Dynamic SM Power Save
> > RX HT20 SGI
> > RX HT40 SGI
> > No RX STBC
> > Max AMSDU length: 3839 bytes
> > DSSS/CCK HT40
> > ampdu factor/density: 0/5
> > MCS mask: ff ff 00 00 00 00 00 00 00 00
> > MCS tx params: 1
> >
> > In my setup this means a 50% drop in downstream throughput(from
> > 160Mbit/s to 80Mbit/s)
> >
> > I tracked down the offending commit and it seems this is it:
> > iwlwifi: change max HT and VHT A-MPDU exponent
> > c064ddf318aa51647a30108f7cd151c208c62eef
> > A new mechanism was created to have per device ampd_factor:
> > - ht_info->ampdu_factor = IEEE80211_HT_MAX_AMPDU_64K;
> > + ht_info->ampdu_factor = cfg->max_ht_ampdu_exponent;
> >
> > however the max_ht_ampdu_exponent is not set for any of the iwl-6000
> > devices(including mine Intel Corporation Centrino Advanced-N 6235)
> >
> > #define IWL_DEVICE_6035 \
> > .fw_name_pre = IWL6030_FW_PRE, \
> > .ucode_api_max = IWL6035_UCODE_API_MAX, \
> > .ucode_api_ok = IWL6035_UCODE_API_OK, \
> > .ucode_api_min = IWL6035_UCODE_API_MIN, \
> > .device_family = IWL_DEVICE_FAMILY_6030, \
> > .max_inst_size = IWL60_RTC_INST_SIZE, \
> > .max_data_size = IWL60_RTC_DATA_SIZE, \
> > .nvm_ver = EEPROM_6030_EEPROM_VERSION, \
> > .nvm_calib_ver = EEPROM_6030_TX_POWER_VERSION, \
> > .base_params = &iwl6000_g2_base_params, \
> > .eeprom_params = &iwl6000_eeprom_params, \
> > .led_mode = IWL_LED_RF_STATE
> >
> > Since the original value of IEEE80211_HT_MAX_AMPDU_64K I would
> > suggest adding it to some iwl-6000 devices.
> > I did not submit any patches because I have no idea if there are
> > device which would not support this feature, however it worked before
> > with default value set to IEEE80211_HT_MAX_AMPDU_64K so I guess it must
> > be supported.
> >
>
> Thank you for your report and analysis. You saved us a lot of time.
> I'll send a fix.
SGksDQoNCk9uIFN1biwgMjAxNS0wMi0yMiBhdCAxNDoxNSArMDIwMCwgVmFsZW50aW4gTWFuZWEg
d3JvdGU6DQo+IEhpLA0KPiANCj4gICAgUmVjZW50bHkgSSBzdGFydGVkIHVzaW5nIGtlcm5lbCAz
LjE5IGZyb20gVWJ1bnR1IHBwYSBhbmQgSSBub3RpY2VkIGEgDQo+IGJpZyBkcm9wIGluIFdpZmkg
dGhyb3VnaHB1dC4gQWZ0ZXIgc29tZSBpbnZlc3RpZ2F0aW9uIEkgZm91bmQgdGhhdCBteSANCj4g
cm91dGVyIHdhcyByZXBvcnRpbmcgdGhlIEFNUERVIGZhY3RvciBjaGFuZ2VkIGZyb20gMyhpbiAz
LjE4KSB0byAwKGluIDMuMTkpOg0KPiBjYXQgDQo+IC9zeXMva2VybmVsL2RlYnVnL2llZWU4MDIx
MS9waHkxL25ldGRldjp3bGFuMS9zdGF0aW9ucy9jNDp4eDp4eDp4eDp4eDp4eC9odF9jYXBhOg0K
PiBodCBzdXBwb3J0ZWQNCj4gY2FwOiAweDEwNjYNCj4gICAgICAgICAgSFQyMC9IVDQwDQo+ICAg
ICAgICAgIER5bmFtaWMgU00gUG93ZXIgU2F2ZQ0KPiAgICAgICAgICBSWCBIVDIwIFNHSQ0KPiAg
ICAgICAgICBSWCBIVDQwIFNHSQ0KPiAgICAgICAgICBObyBSWCBTVEJDDQo+ICAgICAgICAgIE1h
eCBBTVNEVSBsZW5ndGg6IDM4MzkgYnl0ZXMNCj4gICAgICAgICAgRFNTUy9DQ0sgSFQ0MA0KPiBh
bXBkdSBmYWN0b3IvZGVuc2l0eTogMy81DQo+IE1DUyBtYXNrOiBmZiBmZiAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMA0KPiBNQ1MgdHggcGFyYW1zOiAxDQo+IA0KPiBodCBzdXBwb3J0ZWQNCj4gY2Fw
OiAweDEwNjYNCj4gICAgICAgICAgSFQyMC9IVDQwDQo+ICAgICAgICAgIER5bmFtaWMgU00gUG93
ZXIgU2F2ZQ0KPiAgICAgICAgICBSWCBIVDIwIFNHSQ0KPiAgICAgICAgICBSWCBIVDQwIFNHSQ0K
PiAgICAgICAgICBObyBSWCBTVEJDDQo+ICAgICAgICAgIE1heCBBTVNEVSBsZW5ndGg6IDM4Mzkg
Ynl0ZXMNCj4gICAgICAgICAgRFNTUy9DQ0sgSFQ0MA0KPiBhbXBkdSBmYWN0b3IvZGVuc2l0eTog
MC81DQo+IE1DUyBtYXNrOiBmZiBmZiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KPiBNQ1MgdHgg
cGFyYW1zOiAxDQo+IA0KPiAgICBJbiBteSBzZXR1cCB0aGlzIG1lYW5zIGEgNTAlIGRyb3AgaW4g
ZG93bnN0cmVhbSB0aHJvdWdocHV0KGZyb20gDQo+IDE2ME1iaXQvcyB0byA4ME1iaXQvcykNCj4g
DQo+ICAgIEkgdHJhY2tlZCBkb3duIHRoZSBvZmZlbmRpbmcgY29tbWl0IGFuZCBpdCBzZWVtcyB0
aGlzIGlzIGl0Og0KPiAgIGl3bHdpZmk6IGNoYW5nZSBtYXggSFQgYW5kIFZIVCBBLU1QRFUgZXhw
b25lbnQgDQo+IGMwNjRkZGYzMThhYTUxNjQ3YTMwMTA4ZjdjZDE1MWMyMDhjNjJlZWYNCj4gICAg
QSBuZXcgbWVjaGFuaXNtIHdhcyBjcmVhdGVkIHRvIGhhdmUgcGVyIGRldmljZSBhbXBkX2ZhY3Rv
cjoNCj4gLSBodF9pbmZvLT5hbXBkdV9mYWN0b3IgPSBJRUVFODAyMTFfSFRfTUFYX0FNUERVXzY0
SzsNCj4gKyBodF9pbmZvLT5hbXBkdV9mYWN0b3IgPSBjZmctPm1heF9odF9hbXBkdV9leHBvbmVu
dDsNCj4gDQo+ICAgIGhvd2V2ZXIgdGhlIG1heF9odF9hbXBkdV9leHBvbmVudCBpcyBub3Qgc2V0
IGZvciBhbnkgb2YgdGhlIGl3bC02MDAwIA0KPiBkZXZpY2VzKGluY2x1ZGluZyBtaW5lIEludGVs
IENvcnBvcmF0aW9uIENlbnRyaW5vIEFkdmFuY2VkLU4gNjIzNSkNCj4gDQo+ICNkZWZpbmUgSVdM
X0RFVklDRV82MDM1CQkJCQkJXA0KPiAJLmZ3X25hbWVfcHJlID0gSVdMNjAzMF9GV19QUkUsCQkJ
CVwNCj4gCS51Y29kZV9hcGlfbWF4ID0gSVdMNjAzNV9VQ09ERV9BUElfTUFYLAkJCVwNCj4gCS51
Y29kZV9hcGlfb2sgPSBJV0w2MDM1X1VDT0RFX0FQSV9PSywJCQlcDQo+IAkudWNvZGVfYXBpX21p
biA9IElXTDYwMzVfVUNPREVfQVBJX01JTiwJCQlcDQo+IAkuZGV2aWNlX2ZhbWlseSA9IElXTF9E
RVZJQ0VfRkFNSUxZXzYwMzAsCQlcDQo+IAkubWF4X2luc3Rfc2l6ZSA9IElXTDYwX1JUQ19JTlNU
X1NJWkUsCQkJXA0KPiAJLm1heF9kYXRhX3NpemUgPSBJV0w2MF9SVENfREFUQV9TSVpFLAkJCVwN
Cj4gCS5udm1fdmVyID0gRUVQUk9NXzYwMzBfRUVQUk9NX1ZFUlNJT04sCQlcDQo+IAkubnZtX2Nh
bGliX3ZlciA9IEVFUFJPTV82MDMwX1RYX1BPV0VSX1ZFUlNJT04sCVwNCj4gCS5iYXNlX3BhcmFt
cyA9ICZpd2w2MDAwX2cyX2Jhc2VfcGFyYW1zLAkJCVwNCj4gCS5lZXByb21fcGFyYW1zID0gJml3
bDYwMDBfZWVwcm9tX3BhcmFtcywJCVwNCj4gCS5sZWRfbW9kZSA9IElXTF9MRURfUkZfU1RBVEUN
Cj4gDQo+ICAgIFNpbmNlIHRoZSBvcmlnaW5hbCB2YWx1ZSBvZiBJRUVFODAyMTFfSFRfTUFYX0FN
UERVXzY0SyBJIHdvdWxkIA0KPiBzdWdnZXN0IGFkZGluZyBpdCB0byBzb21lIGl3bC02MDAwIGRl
dmljZXMuDQo+ICAgIEkgZGlkIG5vdCBzdWJtaXQgYW55IHBhdGNoZXMgYmVjYXVzZSBJIGhhdmUg
bm8gaWRlYSBpZiB0aGVyZSBhcmUgDQo+IGRldmljZSB3aGljaCB3b3VsZCBub3Qgc3VwcG9ydCB0
aGlzIGZlYXR1cmUsIGhvd2V2ZXIgaXQgd29ya2VkIGJlZm9yZSANCj4gd2l0aCBkZWZhdWx0IHZh
bHVlIHNldCB0byBJRUVFODAyMTFfSFRfTUFYX0FNUERVXzY0SyBzbyBJIGd1ZXNzIGl0IG11c3Qg
DQo+IGJlIHN1cHBvcnRlZC4NCj4gDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXBvcnQgYW5kIGFu
YWx5c2lzLiBZb3Ugc2F2ZWQgdXMgYSBsb3Qgb2YgdGltZS4NCkknbGwgc2VuZCBhIGZpeC4NCg==
T24gTW9uLCAyMDE1LTAyLTIzIGF0IDAwOjIzICswMjAwLCBWYWxlbnRpbiBNYW5lYSB3cm90ZToN
Cj4gSGksDQo+IE9uIDIwMTUtMDItMjIgMjI6MTYsIEdydW1iYWNoLCBFbW1hbnVlbCB3cm90ZToN
Cj4gPiBIaSBhZ2FpbiAoZml4ZWQgeW91ciBhZGRyZXNzLCBJIGhvcGUgaXQgd2lsbCBub3QgYm91
bmNlIHRoaXMgdGltZS4uLikNCj4gU29ycnksIHN0dXBpZCBmaW5nZXJzIGNhdXNlZCB0aGUgYmFk
IHNwZWxsaW5nLCBhbnl3YXkgbm93IGJvdGggYWxpYXNlcyANCj4gYXJlIHZhbGlkLg0KPiA+IFBs
ZWFzZSB0ZXN0IHRoZSBwYXRjaCBhdHRhY2hlZC4NCj4gSSBjYW4gY29uZmlybSB0aGlzIHBhdGNo
IGZpeGVzIHRoZSBwcm9ibGVtIG9uIG15IGhhcmR3YXJlLCBteSB0aHJvdWdocHV0IA0KPiBpcyBi
YWNrIHRvIDE2NCBNYml0L3MNCj4gDQoNCk9rIC0gZ29vZC4gVGhpcyBwYXRjaCBoYXMgYmVlbiBz
dWJtaXR0ZWQgdG8gb3VyIGludGVybmFsIHRyZWUgYW5kIHdpbGwNCnNob3cgdXAgdXBzdHJlYW0g
c29vbi4NCg==
Hi,
On 2015-02-22 22:16, Grumbach, Emmanuel wrote:
> Hi again (fixed your address, I hope it will not bounce this time...)
Sorry, stupid fingers caused the bad spelling, anyway now both aliases
are valid.
> Please test the patch attached.
I can confirm this patch fixes the problem on my hardware, my throughput
is back to 164 Mbit/s
Thank you very much,
Valentin