Description of problem: I have a Lenovo T440s running F20 that contains an Intel 7260 wireless card. When I associate with an 802.11ac Apple Airport Extreme router on a 5GHz channel, iwconfig reports a very high bit rate, but the performance is no better than 802.11n speeds. wlp3s0 IEEE 802.11abgn ESSID:"My 5GHz SSID" Mode:Managed Frequency:5.745 GHz Access Point: 90:72:40:11:F8:05 Bit Rate=780 Mb/s Tx-Power=16 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:on Link Quality=54/70 Signal level=-56 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:3723 Invalid misc:216 Missed beacon:0 Version-Release number of selected component (if applicable): Fedora 20, kernel 3.13.6-200.fc20.x86_64 How reproducible: Every time Steps to Reproduce: 1. Associate with my Airport Extreme AP on a 5GHz channel 2. Use scp to copy a several hundred megabyte file wirelessly to a RHEL 6 laptop connected to the same AP via wired Ethernet. 3. Actual results: 9.7MB/s transfer speeds Expected results: Much faster transfer speed Additional info: These tests were performed about 3 feet away from the access point. When connected via wired Ethernet to the same AP, I can get scp transfer rates of about 112MB/s from the T440s. I performed the same wireless test using my 802.11n Mac (it's too old to have ac) and it was able to transfer a different, but still several hundred megabyte, file to the wired laptop at 16.7Mb/sec.
3.13 doesn't include 11ac Tx rates. Please retry with 3.14.
(In reply to Emmanuel Grumbach from comment #1) > 3.13 doesn't include 11ac Tx rates. Why iwconfig shows "Bit Rate=780 Mb/s" then ?
Because we have an 11ac association, we can Rx in 11ac rates, but the support for TXing in 11ac rates is very minimal - most of the patches were merged in 3.14.
But iwcofnig shows TX rate, it is done by: static int cfg80211_wext_giwrate(struct net_device *dev, struct iw_request_info *info, struct iw_param *rate, char *extra) { /* ... */ err = rdev_get_station(rdev, dev, addr, &sinfo); if (err) return err; if (!(sinfo.filled & STATION_INFO_TX_BITRATE)) return -EOPNOTSUPP; rate->value = 100000 * cfg80211_calculate_bitrate(&sinfo.txrate); } But perhaps calculations in cfg80211 can be broken. Anyway if RX rates are supported, dowloading from AP should show improvment over uploading, Gary could you check that ?
(In reply to Stanislaw Gruszka from comment #4) > But perhaps calculations in cfg80211 can be broken. I mean broken for 11ac, since this is a new thing, for older rates calculations should works fine.
We may be using 11ac rates in 3.13, but: $ git log --oneline v3.13.6..v3.14-rc6 -- drivers/net/wireless/iwlwifi/mvm/rs.c 2b755bb Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next 560843f iwlwifi: mvm: rs: fix a theoretical out of bounds access 75d3e2d iwlwifi: mvm: rs: fix handling of column switch error c8bf40a wireless: delete non-required instances of include <linux/init.h> 51368bf iwlwifi: Update Copyright to 2014 80e9e5c iwlwifi: mvm: rs: fix a potential NULL deref 9e898f1 iwlwifi: mvm: fix harmless smatch / coccinelle warnings cf4ef65 iwlwifi: mvm: rs: fix variable shadowing 4623a26 iwlwifi: mvm: rs: disable MCS9 Tx workaround 4e4b815 iwlwifi: mvm: rs: refactor rate scale action decision 4107dbd iwlwifi: mvm: rs: remove unnecessary debug logs e07be6d iwlwifi: mvm: rs: improve rates table algo ca6f38f iwlwifi: mvm: rs: avoid recalc of supported legacy rate mask 8fc7c58 iwlwifi: mvm: rs: refactor building the LQ command a0c38b2 iwlwifi: mvm: rs: move rs_program_fix_rate to cleanup ifdefs 9d10849 iwlwifi: mvm: rs: fix compilation without CONFIG_MAC80211_DEBUGFS b3b06a3 iwlwifi: mvm: rs: overhaul search cycle state machine a56db7d iwlwifi: mvm: rs: use the proper channel width define for legacy rate da87d7d iwlwifi: mvm: rs: fix mapping from HT/VHT rates to legacy 809bccf iwlwifi: mvm: rs: set dual_stream_ant_msk to ANT_AB always a8ff14f iwlwifi: mvm: rs: remove unused parameter to rs_get_supported_rates 5aa3355 iwlwifi: mvm: rs: refactor to use rs_rate 0c308e9 iwlwifi: mvm: rs: remove unused timestamp field 32b0172 iwlwifi: mvm: rs: increase stay in column timeout c48075d iwlwifi: mvm: rs: rename thresholds defines 9d015a0 iwlwifi: mvm: rs: update expected TPT tables if aggregation changed d17334c iwlwifi: mvm: rs: reduce min failures to end test window 4d30ee8 iwlwifi: mvm: rs: improve debug prints ecc90e7 iwlwifi: mvm: don't configure mimo rates if nss is limited to 1 271518a iwlwifi: mvm: don't enable VHT MCS9 in 20Mhz 393b9e5 iwlwifi: mvm: stop using MIMO in case BT doesn't allow it d307ec8 iwlwifi: mvm: add LQ flags definitions b87c217 iwlwifi: mvm: implement rate_update hook in rs 750a1b4 iwlwifi: mvm: refactor iwl_mvm_rs_rate_init 9e68094 iwlwifi: mvm: simplify iwl_mvm_send_lq_cmd 1a61b34 iwlwifi: mvm: fix and improve printing of rate scale table All these are quite significant...
I tried uploading files to the T440s (used the same wired RHEL 6 system on the other end) and it doesn't appear to receive data significantly faster than it sends it. The receive on the T440s was 11.4MB/s and the send from the T440s was 10.4MB/s
While I am not saying you are the first to report performance issues, I know that Apple makes optimizations between their devices so that comparing Linux to Apple against an Apple Access Point is not exactly an apple to apple comparison :). FWIW, we have much better numbers internally...
That's disappointing, but not surprising. I suppose if I owned the HW and SW like Apple does, I'd make optimizations too. I'll do some checking with the 3.14 kernel as soon as one comes out for F20. The T440s is my production laptop and I don't want to get too far off the rails with dependencies by installing pre-release kernels.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
hi all, I just install 3.15.2 from elrepo-kernel, work with iwlwifi-7260-9.ucode. wlan0 IEEE 802.11abgn ESSID:"euroford_5G" Mode:Managed Frequency:5.765 GHz Access Point: 8C:BE:BE:25:DA:70 Bit Rate=300 Mb/s Tx-Power=16 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:on Link Quality=70/70 Signal level=-30 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:19 Missed beacon:0 Actual results: 11.0MB/s transfer speeds, which is almost the same with official kernel in RHEL6.5. My wifi router is a 2x2 802.11ac HT80. Should I update iwconfig or any other wifi related packages to let RHEL6 support 802.11ac? Thanks.
wireless-regdb should be updated, 2014.06.13 works fine.
only kernel and crda need update. iw dev wlan0 link Connected to 8c:be:be:25:da:70 (on wlan0) SSID: euroford_5G freq: 5765 RX: 11266894 bytes (83761 packets) TX: 9695887 bytes (82173 packets) signal: -33 dBm tx bitrate: 780.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 2 bss flags: short-slot-time dtim period: 3 beacon int: 100
It looks like you should open a RHEL6 bug?
OK John, I met the same problem, when iw reports the wifi's tx bitrate working at 780Mbit/s, the actual transfer rate is 12.5MB/s. If fedora fix this bug, RHEL6 will fix it too.
Now I turn to fedora 20, I notice from version 2.1, wpa_supplicant start support VHT, could you update wpa_supplicant to version 2.1 or above please?
euroford, you need to open an appropriate bugzilla instead of continuing to add comments to a closed one...