[Cerowrt-devel] HT40+ performance issues and AMPDUs
Sebastian Moeller
moeller0 at gmx.de
Thu Feb 20 14:55:10 EST 2014
Hi Dave, hi List,
On Feb 20, 2014, at 19:07 , Dave Taht <dave.taht at gmail.com> wrote:
> 0) Are these settings actually correct?
>
> list ht_capab SHORT-GI-40
> list ht_capab TX-STBC
> list ht_capab RX-STBC1
> list ht_capab DSSS_CCK-40
> option htmode HT40+
>
> for hardware with dual antennas 2x2 as cero has?
>
> 1) I had turned HT40+ off by default in 3.10.28-14. You can turn it on
> via the gui
> or config file, so long as you adhere to the correct channel numbers
> for your country.
Which I did (Channel: 44; mode: 802.11 a+n; Country Code: DE; HT mode: 40MHz 2nd channel above) and I currently get MCS12, at 162Mbit/s which means 40MHz channel 800ns GI., 2 spatial streams (according to http://en.wikipedia.org/wiki/IEEE_802.11n-2009 this means 40MHz channels work)
>
> 2) Performance from HT40+ is still worse than I expected (but a good deal better
> than it was pre-instruction-trap-fix)
According to http://dl.acm.org/citation.cfm?id=2079307, "The impact of channel bonding on 802.11n network management" (I might have gotten the citation from you Dave in the first place, I just can not remember) we can expect roughly 1.3 times the throughput for 40MHz vs. 20 MHz channels. I am not sure whether that is still valid though.
>
> In poking at this I see one oddity in that we are never seeing ampdus queued
> in hardware, OR completed on system idle...
>
> I'm willing to believe this is a bug in the reporting system rather
> than reality.
I would not be to amazed given:
root at nacktmulle:~# cat /sys/kernel/debug/ieee80211/phy1/ath9k/regdump
Segmentation fault
dmesg has:
[72466.046875] Data bus error, epc == 8256f404, ra == 8256f40c
[72466.046875] Oops[#1]:
[72466.046875] CPU: 0 PID: 5967 Comm: cat Not tainted 3.10.28 #2
[72466.046875] task: 81721a10 ti: 838a2000 task.ti: 838a2000
[72466.046875] $ 0 : 00000000 00000000 deadc0de 00000001
[72466.046875] $ 4 : c0c97c88 00035c8d 82577018 000008e8
[72466.046875] $ 8 : 0000000a 00000003 00000001 00000000
[72466.046875] $12 : 8033cf14 00000002 00000000 004062b0
[72466.046875] $16 : 000008e8 c0c97c88 00035c8d 82695440
[72466.046875] $20 : 0000023a 00002c88 c0c95000 00038915
[72466.046875] $24 : 00000000 8007352c
[72466.046875] $28 : 838a2000 838a3d20 00002d41 8256f40c
[72466.046875] Hi : 00000003
[72466.046875] Lo : 00000000
[72466.046875] epc : 8256f404 open_file_regdump+0xb8/0x118 [ath9k]
[72466.046875] Not tainted
[72466.046875] ra : 8256f40c open_file_regdump+0xc0/0x118 [ath9k]
[72466.046875] Status: 1000fc03 KERNEL EXL IE
[72466.046875] Cause : 8080001c
[72466.046875] PrId : 00019374 (MIPS 24Kc)
[72466.046875] Modules linked in: ath9k ath9k_htc ath9k_common iptable_nat ath9k_hw ath pppoe nf_nat_ipv4 nf_conntrack_ipv4 mac80211 cfg80211 xt_u32 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_hashlimit xt_ecn xt_dscp xt_conntrack xt_connmark xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_LOG xt_IPMARK xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet ts_kmp ts_fsm ts_bm pptp pppox ppp_async nf_nat_irc nf_nat_ftp nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables crc_ccitt compat_xtables compat sch_teql sch_tbf sch_sfq sch_red sch_qfq sch_prio sch_pie sch_ns2_codel sch_nfq_codel sch_netem sch_htb sch_gred sch_efq_codel sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress leds_wndr3700_usb ledtrig_usbdev ledtrig_netdev xt_set ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink sr_mod cdrom ip6t_NPT ip6t_MASQUERADE ip6table_nat nf_nat_ipv6 nf_nat ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb sit ipip ip6_tunnel tunnel6 tunnel4 ip_tunnel vfat fat autofs4 br2684 atm nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_iso8859_1 nls_cp437 ipv6 authenc aead arc4 crypto_blkcipher usb_storage leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache usbcore nls_base usb_common crypto_hash
[72466.046875] Process cat (pid: 5967, threadinfo=838a2000, task=81721a10, tls=77daf440)
[72466.046875] Stack : 00000100 8010239c 83559ee0 000008e4 00000000 838a3e30 823c5000 8355bde0
[72466.046875] 82575978 8256f34c 838a3e20 823c5008 00000002 838a3f00 00000000 800f7650
[72466.046875] 0058d3ec 823c5000 00002000 801055b0 838a3e78 838a3e78 00000000 838a3e30
[72466.046875] 823c5000 838a3e20 823c5000 80105f94 82c00037 82c00038 00000000 838a3e78
[72466.046875] 00000000 80103b28 83aecf78 8355bde0 83b11650 83556f68 83558a68 00002000
[72466.046875] ...
[72466.046875] Call Trace:
[72466.046875] [<8256f404>] open_file_regdump+0xb8/0x118 [ath9k]
[72466.046875] [<800f7650>] do_dentry_open.isra.15+0x1bc/0x29c
[72466.046875] [<80105f94>] do_last.isra.43+0x974/0xb80
[72466.046875] [<80106260>] path_openat+0xc0/0x41c
[72466.046875] [<80106cd0>] do_filp_open+0x3c/0xa4
[72466.046875] [<800f8a00>] do_sys_open+0x140/0x1e8
[72466.046875] [<80062544>] stack_done+0x20/0x40
[72466.046875]
[72466.046875]
[72466.046875] Code: 02402821 24c67018 02003821 <0c063f24> afa20010 02a2a821 26940001 029e102b 1440ffef
[72466.402343] ---[ end trace e7739d545f975285 ]---
So somethings are a bit fickle with ath9k, but I do not even know whether regdump is a reasonable thing to do in a live system…
Best Regards
Sebastian
>
> root at dave:/sys/kernel/debug/ieee80211/phy1/ath9k# cat xmit
> BE BK VI VO
>
> MPDUs Queued: 0 0 0 5
> MPDUs Completed: 20090 0 0 5
> MPDUs XRetried: 0 0 0 0
> Aggregates: 0 0 0 0
> AMPDUs Queued HW: 0 0 0 0
> AMPDUs Queued SW: 20090 0 0 0
> AMPDUs Completed: 0 0 0 0
> AMPDUs Retried: 0 0 0 0
> AMPDUs XRetried: 0 0 0 0
> TXERR Filtered: 0 0 0 0
> FIFO Underrun: 0 0 0 0
> TXOP Exceeded: 0 0 0 0
> TXTIMER Expiry: 0 0 0 0
> DESC CFG Error: 0 0 0 0
> DATA Underrun: 0 0 0 0
> DELIM Underrun: 0 0 0 0
> TX-Pkts-All: 20090 0 0 5
> TX-Bytes-All: 11089496 0 0 770
> HW-put-tx-buf: 1 0 0 1
> HW-tx-start: 20090 0 0 5
> HW-tx-proc-desc: 20090 0 0 5
> TX-Failed: 0 0 0 0
>
> This is on a box that has been idle, with nothing attached to it.
>
> Elsewhere on other test runs I HAVE seen ampdus, with traffic, but
> nothing queued
> in the queued hw statistic:
>
> BE BK VI VO
>
> MPDUs Queued: 0 0 0 110
> MPDUs Completed: 1643 0 3 130
> MPDUs XRetried: 0 0 0 0
> Aggregates: 38198 0 0 0
> AMPDUs Queued HW: 0 0 0 0
> AMPDUs Queued SW: 241225 0 61 20
> AMPDUs Completed: 239582 0 58 0
> AMPDUs Retried: 3229 0 0 0
> AMPDUs XRetried: 0 0 0 0
> TXERR Filtered: 0 0 0 0
> FIFO Underrun: 0 0 0 0
> TXOP Exceeded: 0 0 0 0
> TXTIMER Expiry: 0 0 0 0
> DESC CFG Error: 0 0 0 0
> DATA Underrun: 0 0 0 0
> DELIM Underrun: 0 0 0 0
> TX-Pkts-All: 241225 0 61 130
> TX-Bytes-All: 144207885 0 8502 7793
> HW-put-tx-buf: 1 0 1 1
> HW-tx-start: 61881 0 61 130
> HW-tx-proc-desc: 61895 0 61 130
> TX-Failed: 0 0 0 0
>
> I bumped up the default be_qlen to 128 again and under my test conditions
> (boxes about 2 feet away from each other, but other radios contending on the
> same channel elsewhere), and get about 60MBit out of it.
>
> I see it occilate between MCS13 and MCS15. At MCS13 ~60Mbit kind of makes sense.
>
> type rate throughput ewma prob this prob retry this succ/attem
> HT20/LGI MCS0 5.9 100.0 100.0 1 0(
> HT20/LGI MCS1 11.9 100.0 100.0 0 0(
> HT20/LGI MCS2 17.7 100.0 100.0 0 0(
> HT20/LGI MCS3 23.4 100.0 100.0 0 0(
> HT20/LGI MCS4 34.7 100.0 100.0 0 0(
> HT20/LGI MCS5 45.4 96.5 100.0 2 0(
> HT20/LGI MCS6 50.5 97.7 100.0 5 0(
> HT20/LGI MCS7 50.8 80.2 100.0 0 0(
> HT20/LGI MCS8 11.9 100.0 100.0 4 0(
> HT20/LGI MCS9 23.4 100.0 100.0 0 0(
> HT20/LGI MCS10 34.7 100.0 100.0 0 0(
> HT20/LGI MCS11 45.4 100.0 100.0 0 0(
> HT20/LGI MCS12 67.1 95.7 100.0 0 0(
> HT20/LGI MCS13 84.9 100.0 100.0 0 0(
> HT20/LGI MCS14 95.8 100.0 100.0 0 0(
> HT20/LGI MCS15 14.1 12.2 0.0 0 0(
> HT40/LGI MCS0 12.3 100.0 100.0 0 0(
> HT40/LGI MCS1 24.5 100.0 100.0 0 0(
> HT40/LGI MCS2 36.0 100.0 100.0 0 0(
> HT40/LGI MCS3 47.3 96.2 100.0 0 0(
> HT40/LGI MCS4 69.2 100.0 100.0 0 0(
> HT40/LGI MCS5 88.3 100.0 100.0 0 0(
> HT40/LGI MCS6 100.0 93.6 100.0 3 0(
> HT40/LGI MCS7 105.7 86.6 66.6 4 0(
> HT40/LGI MCS8 24.5 100.0 100.0 0 0(
> HT40/LGI MCS9 47.3 95.7 100.0 0 0(
> HT40/LGI MCS10 69.2 100.0 100.0 0 0(
> HT40/LGI MCS11 88.3 100.0 100.0 6 0(
> HT40/LGI MCS12 128.7 98.8 100.0 5 1(
> HT40/LGI t MCS13 141.4 81.8 100.0 5 1(
> HT40/LGI MCS14 77.9 38.8 100.0 5 0(
> HT40/LGI MCS15 64.6 29.6 0.0 5 0(
> HT40/SGI MCS0 13.7 100.0 100.0 0 0(
> HT40/SGI MCS1 27.1 100.0 100.0 0 0(
> HT40/SGI MCS2 39.6 100.0 100.0 0 0(
> HT40/SGI MCS3 52.0 100.0 100.0 5 0(
> HT40/SGI MCS4 75.8 100.0 100.0 6 0(
> HT40/SGI MCS5 96.2 100.0 100.0 3 0(
> HT40/SGI MCS6 108.7 99.5 100.0 4 0(
> HT40/SGI P MCS7 119.3 90.2 100.0 4 0(
> HT40/SGI MCS8 27.1 100.0 100.0 0 0(
> HT40/SGI MCS9 52.0 100.0 100.0 0 0(
> HT40/SGI MCS10 75.8 100.0 100.0 0 0(
> HT40/SGI MCS11 96.2 95.9 100.0 6 0(
> HT40/SGI MCS12 125.1 80.8 100.0 5 0(
> HT40/SGI T MCS13 144.6 77.9 79.6 5 125(15
> HT40/SGI MCS14 28.6 13.4 0.0 5 0(
> HT40/SGI MCS15 58.8 25.3 0.0 5 0(
>
> Total packet count:: ideal 267597 lookaround 4212
> Average A-MPDU length: 11.1
>
> I've seen the average AMPDU length peak at about 19 under these conditions.
>
> So, under benchmark conditions my empirically derived value for qlen_be is
> too low for maximum throughput. I am considering doubling it to 24 and also
> doing some tweaks to debloat to use a larger quantum and target for wifi...
>
> But if the hw AMPDU problem is a real problem, I'll sit on it.
>
> Amusingly the ath10k device I'm using to drive the tests doesn't seem to support
> running on other channels besides 36 at the moment...
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
More information about the Cerowrt-devel
mailing list