From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 0FBD3200111; Tue, 19 May 2015 13:49:24 -0700 (PDT) Received: by oign205 with SMTP id n205so20944320oig.2; Tue, 19 May 2015 13:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=TJJVAMUq/bRFi3SnAccbOIKkn7XI/Fb9Z0OZ2QSwmk0=; b=igVNRpwk7Ph/Bm24OfuXofUkSLGYQmyTAUqAwk3ABKnPH63ovsK96pyG2WJ+ciJYOZ NDYgxLQzY56UtCXBLrogpNn70luu7SQiJPvkEPZ46t6cgD4vSZ5En89Gy71xOh5BB+Oh z96CTNkbuCmA5f3QthxZ+ws+Lciki/6mHPVLkCiASxla0dsfScl2Fx+/fklHnh6r+9ZB i7zd6s33Ed9O/um8I152OkF+n2SHOJq13dRvEVnGnEV4EDB6M0pwIrpTcx+OLw6Ije/M 3HqMRc1R3Ei++N8uI3lihFr+tsswPrg9tTl2Ng3HpDiEWSJd9mzfeaSiF6ZcebmDUvd3 6Ccw== MIME-Version: 1.0 X-Received: by 10.60.78.232 with SMTP id e8mr4412640oex.24.1432068554419; Tue, 19 May 2015 13:49:14 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Tue, 19 May 2015 13:49:14 -0700 (PDT) In-Reply-To: <555A5938.9080706@candelatech.com> References: <555A5938.9080706@candelatech.com> Date: Tue, 19 May 2015 13:49:14 -0700 Message-ID: From: Dave Taht To: bloat , make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" , Ben Greear Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Bloat] Fwd: Poor TCP performance with ath10k in 4.0 kernel, again. X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:50:11 -0000 ben, do you have packet captures? What was the qdisc on the interface? ---------- 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 bette= r 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 --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67