From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp65.ord1c.emailsrvr.com (smtp65.ord1c.emailsrvr.com [108.166.43.65]) by huchra.bufferbloat.net (Postfix) with ESMTP id 1F0D521F159 for ; Mon, 20 Jan 2014 07:10:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2B005148134; Mon, 20 Jan 2014 10:09:07 -0500 (EST) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id 6F5FF1480DE; Mon, 20 Jan 2014 10:09:06 -0500 (EST) User-Agent: K-@ Mail for Android X-Priority: 3 In-Reply-To: <21212.40503.163250.285305@gargle.gargle.HOWL> References: <21212.38828.910370.71395@gargle.gargle.HOWL> <21212.40503.163250.285305@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----V3LT64RJQHXHGGHNWD9SVHW83YJR8D" Content-Transfer-Encoding: 8bit From: "David P. Reed" Date: Mon, 20 Jan 2014 07:09:04 -0800 To: Sujith Manoharan ,Dave Taht Message-ID: <0045e4e1-f1dd-4e15-81fb-4d616ffab08d@katmail.1gravity.com> Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] looking over ampdu stats 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: Mon, 20 Jan 2014 15:10:28 -0000 ------V3LT64RJQHXHGGHNWD9SVHW83YJR8D Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 It's worth remembering that while aggregation of data in single units might reduce overhead, end to end latency is far more critical to most Internet apps. Focusing on optimizing throughput for the last few percent in corner cases is NOT desirable. In fact, it is the cause of pervasive buffer bloated designs, and the creator of "Daddy broke the Internet" scenarios. Since LTE is badly configured in the field for Internet use, causing denial of service to many users because of bloated (multisecond to drain) queues, I would stop focusing on this, which is only a 10 percent issue. Multisecond bloat is a disaster. You are fiddling while Rome burns imo. On Jan 19, 2014, Sujith Manoharan wrote: >Dave Taht wrote: >> Gotcha. I went later (at felix's urging) to look at the rc_stats >> and that showed some decent averages for the actual number of >> packets in the AMPDU. Never managed to get it much above 11, >> regardless of what I set be_qlen to... > >Yes, something seems to be wrong. > >Using just 1 stream with iperf, the average A-MPDU length never >goes above 10 and the throughput is about 90 Mbps. > >Using 4 iperf streams (using -P), the average A-MPDU length goes up to >22 >and throughput reaches about 102 Mbps. > >This is with HT20. Using HT40 shows the behavior for 1 iperf stream. > >Sujith >_______________________________________________ >Cerowrt-devel mailing list >Cerowrt-devel@lists.bufferbloat.net >https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Sent from my Android device with K-@ Mail. Please excuse my brevity. ------V3LT64RJQHXHGGHNWD9SVHW83YJR8D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit It's worth remembering that while aggregation of data in single units might reduce overhead, end to end latency is far more critical to most Internet apps.

Focusing on optimizing throughput for the last few percent in corner cases is NOT desirable.  In fact, it is the cause of pervasive buffer bloated designs, and the creator of "Daddy broke the Internet" scenarios.

Since LTE is badly configured in the field for Internet use, causing denial of service to many users because of bloated (multisecond to drain) queues, I would stop focusing on this, which is only a 10 percent issue.  Multisecond bloat is a disaster. You are fiddling while Rome burns imo.

On Jan 19, 2014, Sujith Manoharan <sujith@msujith.org> wrote:
Dave Taht wrote:
Gotcha. I went later (at felix's urging) to look at the rc_stats
and that showed some decent averages for the actual number of
packets in the AMPDU. Never managed to get it much above 11,
regardless of what I set be_qlen to...

Yes, something seems to be wrong.

Using just 1 stream with iperf, the average A-MPDU length never
goes above 10 and the throughput is about 90 Mbps.

Using 4 iperf streams (using -P), the average A-MPDU length goes up to 22
and throughput reaches about 102 Mbps.

This is with HT20. Using HT40 shows the behavior for 1 iperf stream.

Sujith

Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

-- Sent from my Android device with K-@ Mail. Please excuse my brevity. ------V3LT64RJQHXHGGHNWD9SVHW83YJR8D--