From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1F68A3B25E; Sun, 1 May 2016 01:23:40 -0400 (EDT) Received: by mail-oi0-x22c.google.com with SMTP id x19so159410547oix.2; Sat, 30 Apr 2016 22:23:39 -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 :cc:content-transfer-encoding; bh=2ETOlt1w/aYKbO80dIiLgPGiG7VAsUs56vLN++IVyyc=; b=hT3EcqowKEOTaA35B13HPpwtaeOTDcmso/SFugzl69tE0BSwPO8hbzGsWpcsLr67/t /LNes0DptXd1UHxEU4z3djTSJKj6RGDOgDJbL0dYMHrlmPsC6v4tUQt8x7qa7h+cmJka RCOQUuCz1JUS6FqCIbtbhL9gVJ15aMe2QthWiGi/MIB91ofJ3ASXu4gc3Xr+KW9utRt2 UxCfOnuSEf4xxrbVC5bfpZNifpJXSwudR87SqDfjglQ5/uR6ktcJTIj2PRARGlzpRwP5 HL+q75sTiKH1fLhH2YCmzASXw8EP9BGDi5Af93b5s08gWP3IaRMiciNe5Juu/mnNk2H9 FVBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=2ETOlt1w/aYKbO80dIiLgPGiG7VAsUs56vLN++IVyyc=; b=OgrLCWgNHrYoWeNuCM3j6ioMSrfHZaoyuB+ucVD6eoqJB06P2YiT+ept31221xPio/ XYTq56US1ayNO/UmB6rsZzzLe/pfvvyTmThdv6cUyxGI7px5RHfdwhqiDuExCv9ej5c7 UEzUlDLoKhNYUZcO+K5ErmptxAiAs3MDjBET9GBootTDVgfOP0xgOGfPj1hlxncLM5Ac tZzmlexWjE9ZMYtB/HoKdnDHuL4TGB9OrrHr0KbDreFyd7UGAUUUriFtvq+6wkPfbQPN iJ0g/09j3DW8UYJ2epp707Tve048aZ5kZTjh5/a945kEG+qijBJvua5xr01ov47nG6hn FdLQ== X-Gm-Message-State: AOPr4FUVVYdhXuhPsDKiYpEo+Tg2cC4x7eY3dd2EA2e+Ynpag+kMgmmmydosHF5Gzj4MU8tFdJ7v1UP++2mOpQ== MIME-Version: 1.0 X-Received: by 10.157.4.174 with SMTP id 43mr11499149otm.127.1462080219467; Sat, 30 Apr 2016 22:23:39 -0700 (PDT) Received: by 10.202.78.23 with HTTP; Sat, 30 Apr 2016 22:23:39 -0700 (PDT) In-Reply-To: <57258F41.8040600@candelatech.com> References: <57258F41.8040600@candelatech.com> Date: Sat, 30 Apr 2016 22:23:39 -0700 Message-ID: From: Dave Taht To: Ben Greear Cc: ath10k , "codel@lists.bufferbloat.net" , make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] fq_codel_drop vs a udp flood X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 05:23:40 -0000 On Sat, Apr 30, 2016 at 10:08 PM, Ben Greear wrot= e: > > > On 04/30/2016 08:41 PM, Dave Taht wrote: >> >> There were a few things on this thread that went by, and I wasn't on >> the ath10k list >> >> (https://www.mail-archive.com/ath10k@lists.infradead.org/msg04461.html) >> >> first up, udp flood... >> >>>>> From: ath10k on behalf of Roman >>>>> Yeryomin >>>>> Sent: Friday, April 8, 2016 8:14 PM >>>>> To: ath10k@lists.infradead.org >>>>> Subject: ath10k performance, master branch from 20160407 >>>>> >>>>> Hello! >>>>> >>>>> I've seen performance patches were commited so I've decided to give i= t >>>>> a try (using 4.1 kernel and backports). >>>>> The results are quite disappointing: TCP download (client pov) droppe= d >>>>> from 750Mbps to ~550 and UDP shows completely weird behavour - if >>>>> generating 900Mbps it gives 30Mbps max, if generating 300Mbps it give= s >>>>> 250Mbps, before (latest official backports release from January) I wa= s >>>>> able to get 900Mbps. >>>>> Hardware is basically ap152 + qca988x 3x3. >>>>> When running perf top I see that fq_codel_drop eats a lot of cpu. >>>>> Here is the output when running iperf3 UDP test: >>>>> >>>>> 45.78% [kernel] [k] fq_codel_drop >>>>> 3.05% [kernel] [k] ag71xx_poll >>>>> 2.18% [kernel] [k] skb_release_data >>>>> 2.01% [kernel] [k] r4k_dma_cache_inv >> >> >> The udp flood behavior is not "weird". The test is wrong. It is so >> filling >> the local queue as to dramatically exceed the bandwidth on the link. > > > It would be nice if you could provide backpressure so that you could > simply select on the udp socket and use that to know when you can send > more frames?? The qdisc version returns NET_XMIT_CN to the upper layers of the stack in the case where the dropped packet's flow =3D the ingress packet's flow, but that is after the exhaustive search... I don't know what effect (if any) that had on udp sockets. Hmm... will look. Eric would "just know". That might provide more backpressure in the local scenario. SO_SND_BUF should interact with this stuff in some sane way... ... but over the wire from a test driver box elsewhere, tho, aside from ethernet flow control itself, where enabled, no. ... but in that case you have a much lower inbound/outbound performance disparity in the general case to start with... which can still be quite high... > > Any idea how that works with codel? Beautifully. For responsive TCP flows. It immediately reduces the window without a RTT. > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org