From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C6AAD21F1EC for ; Thu, 20 Feb 2014 10:07:31 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id e4so6187206wiv.5 for ; Thu, 20 Feb 2014 10:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+29RULZS+JBaUNcpsK35diQovMjO5zHXgLvAzTKexvs=; b=DXBViP1pCr09vBg0ZqCtV4W9vHmuXpsg4D+IVXVFPdWZjOvEWnP+f1mpuFME5UTrcR x61OmVV2N2qobZFVzfIa/49KTjlhJQOiWKElosN36JJma+/xbAnz4+keUepk5SHg0Bcx ZpKYtbR4o77r6W4ra7rvozvmQrFx5qDBQ14AtyaWe6YbqgJYIE5zdjfd3LJAmDwBcQyM 9cMCYUJFBPRSYPSssjzL0msZ5jqzx2Kf3tdB6nTw1YFYMVK1bo0LKM09Sh7TqzxX5JXE /kL+hAhenIEhKu9a+C2yUy4MX7WLvsaZyrukI66pJpW/KFWk5gz7asZ7RH+4Y35pDhUy BTig== MIME-Version: 1.0 X-Received: by 10.180.97.37 with SMTP id dx5mr3710234wib.53.1392919649694; Thu, 20 Feb 2014 10:07:29 -0800 (PST) Received: by 10.216.8.1 with HTTP; Thu, 20 Feb 2014 10:07:29 -0800 (PST) Date: Thu, 20 Feb 2014 13:07:29 -0500 Message-ID: From: Dave Taht To: "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Felix Fietkau Subject: [Cerowrt-devel] HT40+ performance issues and AMPDUs X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 18:07:33 -0000 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. 2) Performance from HT40+ is still worse than I expected (but a good deal b= etter than it was pre-instruction-trap-fix) In poking at this I see one oddity in that we are never seeing ampdus queue= d in hardware, OR completed on system idle... I'm willing to believe this is a bug in the reporting system rather than reality. root@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 th= e same channel elsewhere), and get about 60MBit out of it. I see it occilate between MCS13 and MCS15. At MCS13 ~60Mbit kind of makes s= ense. 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 1= 25(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 su= pport running on other channels besides 36 at the moment... --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html