From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.candelatech.com (mail2.candelatech.com [208.74.158.173]) by huchra.bufferbloat.net (Postfix) with ESMTP id A29A021F1A1; Tue, 19 May 2015 15:34:11 -0700 (PDT) Received: from [192.168.100.236] (unknown [50.251.239.81]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail2.candelatech.com (Postfix) with ESMTPSA id E788B40B3EC; Tue, 19 May 2015 15:33:59 -0700 (PDT) Message-ID: <555BBA57.3080402@candelatech.com> Date: Tue, 19 May 2015 15:33:59 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dave Taht References: <555A5938.9080706@candelatech.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] Fwd: Poor TCP performance with ath10k in 4.0 kernel, again. 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: Tue, 19 May 2015 22:35:04 -0000 On 05/19/2015 01:49 PM, Dave Taht wrote: > ben, do you have packet captures? I can get them easily enough...what scenario would you like captured? Files will be large, but I can upload them somewhere and post a link. > > What was the qdisc on the interface? Default kernel qdisc...I think fifo-fast? Thanks, Ben > > ---------- Forwarded message ---------- > From: Ben Greear > Date: Mon, May 18, 2015 at 2:27 PM > Subject: Poor TCP performance with ath10k in 4.0 kernel, again. > To: "linux-wireless@vger.kernel.org" , > ath10k > > > Disclosure: I am working with a patched 4.0 kernel, patched ath10k driver, and > patched (CT) ath10k firmware. Traffic generator is of our own making. > > First, this general problem has been reported before, but the > work-arounds previously suggested do not fully resolve my problems. > > The basic issue is that when the sending socket is directly on top > of a wifi interface (ath10k driver), then TCP throughput sucks. > > For instance, if AP interface sends to station, with 10 concurrent > TCP streams, I see about 426Mbps. With 100 streams, I see total throughput > of 750Mbps. These were maybe 10-30 second tests that I did. > > Interestingly, a single stream connection performs very poorly at first, > but at least in one test, it eventually ran quite fast. It is too > complicated to describe in words, but the graph is here: > > http://www.candelatech.com/downloads/single-tcp-4.0.pdf > > The 10-stream test did not go above about 450Mbps even after running > for more than > 1 minute, and it was fairly stable around the 450Mbps range after the > first few seconds. > > 100-stream test shows nice stable aggregate throughput: > > http://www.candelatech.com/downloads/100-tcp-4.0.pdf > > I have tweaked the kernel tcp_limit_output_bytes setting > (tested at 1024k too, did not make any significant difference). > > # cat /proc/sys/net/ipv4/tcp_limit_output_bytes > 2048000 > > I have tried forcing TCP send/rcv buffers to be 1MB and 2MB, but that > did not make obvious difference except that it started at the maximum > rate very quickly instead of taking a few seconds to train up to full speed. > > If I run a single-stream TCP test, sending on eth1 (Intel 1G NIC) > through the AP machine, then single stream download is about 540 Mbps, > and ramps up > quickly. So, the AP can definitely send the needed amount of TCP packets. > > UDP throughput in download direction, single stream, is about 770Mbps, > regardless > of whether I originate the socket on the AP or if I pass it through the AP. > send/recv bufs are set to 1MB for UDP sockets. > > The 3.17 kernel shows similar behaviour, and the 3.14 kernel is a lot better > for TCP traffic. > > Are there tweaks other than tcp_limit_output_bytes that might > improve this behaviour? > > I will be happy to grab captures or provide any other debugging info > that someone thinks will be helpful. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com