From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 DBB7C3B260; Mon, 2 May 2016 14:40:01 -0400 (EDT) Received: by mail-oi0-x229.google.com with SMTP id v145so168333693oie.0; Mon, 02 May 2016 11:40:01 -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=x+1gfZ0C0WjY8Rb4KFI7askltUI01N8oMKIcL+zjJLA=; b=C9CtCihXvlpg8pJFSBKJbZxqGkMrWzDF4Mo0KOMvCI+PKI85Q4zKjYz748A2JBOveK o+VAhLma53Ju+H/Su4svIrwyZKSPXr7K8Yz2fY6oqnqIDiIKqBvF52cigph6pVtVb4R5 a+gKzOqUYvDmqvLIpKCuVdD4T5Ndst4kJ8+hKg5WNtH/YimVxqS+bU8nDlo58gs53loW qHwU1CDqr6jIoXVs7/OcrGp3jezqilLj1G8LUokySbqWTjbjB7q2qYLCgdcMiVoEnl3p llleaMXm9B9hVoNoo0QKkjFslYnv7AUfCNknNcgwwxT4uoIF9ZZm1XVGhznzqaaTLjlD qmoQ== 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=x+1gfZ0C0WjY8Rb4KFI7askltUI01N8oMKIcL+zjJLA=; b=SU11O9WehQNkXFWl1R+lIsADY8n1e0wwc1/bU+yvVFtaY5rrhuz86FsWjYro42E2Yi 9l2sZhgop97obEiCFxMXhXLlJmWhlI0hOJDY5xZ5oB4Y8NspLPMx3+lvQZlEtmBLowgT p9p50ZWucjNDXgVmQwfIss7PP5REy+BAN6VjqjkJhO3FM4ZjQv+Z1GPZWIjOMgPrzLAh 7GjhC0GbBa78iFbey4B8a75bzoPYOZJ02UOeGFIXhHXOi09DTGVZ/g6aLNlD3FxxDk6c A/iq0j2kcrpwOMKaha80651178BgdGMzruBy1F/qBtEMsw1z/wsWvbuht6pgoZkV38VK tvug== X-Gm-Message-State: AOPr4FUk0CUt78OyJ0a48qU/eSKgryBCAM7HWp0yewzRm5AjuUbB95p2sGCI31YklH87n01vbgVwopCiaZ+RLQ== MIME-Version: 1.0 X-Received: by 10.157.34.14 with SMTP id o14mr17190234ota.63.1462214401073; Mon, 02 May 2016 11:40:01 -0700 (PDT) Received: by 10.202.78.23 with HTTP; Mon, 2 May 2016 11:40:00 -0700 (PDT) In-Reply-To: References: <57258F41.8040600@candelatech.com> <1462114043.512818296@apps.rackspace.com> Date: Mon, 2 May 2016 11:40:00 -0700 Message-ID: From: Dave Taht To: Roman Yeryomin Cc: David Reed , make-wifi-fast@lists.bufferbloat.net, Ben Greear , "codel@lists.bufferbloat.net" , ath10k 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: Mon, 02 May 2016 18:40:02 -0000 On Mon, May 2, 2016 at 7:03 AM, Roman Yeryomin wrot= e: > On 1 May 2016 at 17:47, wrote: >> Maybe I missed something, but why is it important to optimize for a UDP = flood? > > We don't need to optimize it to UDP but UDP is used e.g. by torrents > to achieve higher throughput and used a lot in general. Torrents use uTP congestion control and won't hit this function at all. And eric just made fq_codel_drop more efficient for tests that do. There are potentially zillions of other issues with ampdu's, txop usage, aggregate "packing", etc that can also affect and other protocools. > And, again, in this case TCP is broken too (750Mbps down to 550), so > it's not like Dave is saying that UDP test is broken, fq_codel is just > too hungry for CPU "fq_codel_drop" was too hungry for cpu. fixed. thx eric. :) I've never seen ath10k tcp throughput in the real world (e.g not wired up, over the air) even close to 750 under test on the ath10k (I've seen 300, and I'm getting some better gear up this week)... and everybody tests wifi differently. (for the record, what was your iperf tcp test line?). More people testing differently =3D good. Did fq_codel_drop show up in the perf trace for the tcp test? (More likely you would have seen timestamping rise significantly for the tcp test, as well as enqueue time) That said, more people testing the same ways, good too. I'd love it if you could re-run your test via flent, rather than iperf, and look at the tcp sawtooth or lack thereof, and the overall curve of the throughput, before and after this set of commits. Flent can be made to run on osx via macports or brew. (much easier to get running on linux) And try to tag along on observing/fixing low wifi rate behavior? This was the more recent dql vs wifi test: http://blog.cerowrt.org/post/dql_on_wifi_2/ and series. >> A general observation of control theory is that there is almost always a= n adversarial strategy that will destroy any control regime. Sometimes one = has to invoke an "oracle" that knows the state of the control system at all= times to get there. >> >> So a handwave is that *there is always a DDoS that will work* no matter = how clever you are. >> >> And the corollary is illustrated by the TSA. If you can't anticipate all= possible attacks, it is not clearly better to just congest the whole syste= m at all times with controls that can't possibly solve all possible attacks= - i.e. Security Theater. We don't want "anti-DDoS theater" I don't think. >> >> There is an alternative mechanism that has been effective at dealing wit= h DDoS in general - track the disruption back to the source and kill it. (= this is what the end-to-end argument would be: don't try to solve a fundame= ntally end-to-end problem, DDoS, solely in the network [switches], since yo= u have to solve it at the edges anyway. Just include in the network things = that will help you solve it at the edges - traceback tools that work fast a= nd targeted shutdown of sources). >> >> I don't happen to know of a "normal" application that benefits from UDP = flooding - not even "gossip protocols" do that! >> >> In context, then, let's not focus on UDP flood performance (or any other= "extreme case" that just seems fun to work on in a research paper because = it is easy to state compared to the real world) too much. >> >> I know that the reaction to this post will be to read it and pretty much= go on as usual focusing on UDP floods. But I have to try. There are so man= y more important issues (like understanding how to use congestion signallin= g in gossip protocols, gaming, or live AV conferencing better, as some rela= ted examples, which are end-to-end problems for which queue management and = congestion signalling are truly crucial). >> >> >> >> On Sunday, May 1, 2016 1:23am, "Dave Taht" said: >> >>> On Sat, Apr 30, 2016 at 10:08 PM, Ben Greear = wrote: >>>> >>>> >>>> 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.htm= l) >>>>> >>>>> first up, udp flood... >>>>> >>>>>>>> From: ath10k on behalf of Rom= an >>>>>>>> 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 giv= e it >>>>>>>> a try (using 4.1 kernel and backports). >>>>>>>> The results are quite disappointing: TCP download (client pov) dro= pped >>>>>>>> from 750Mbps to ~550 and UDP shows completely weird behavour - if >>>>>>>> generating 900Mbps it gives 30Mbps max, if generating 300Mbps it g= ives >>>>>>>> 250Mbps, before (latest official backports release from January) I= was >>>>>>>> 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 R= TT. >>> >>>> Thanks, >>>> Ben >>>> >>>> -- >>>> Ben Greear >>>> Candela Technologies Inc http://www.candelatech.com >>> >>> >>> >>> -- >>> Dave T=C3=A4ht >>> Let's go make home routers and wifi faster! With better software! >>> http://blog.cerowrt.org >>> _______________________________________________ >>> Make-wifi-fast mailing list >>> Make-wifi-fast@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/make-wifi-fast >>> >> >> >> _______________________________________________ >> Make-wifi-fast mailing list >> Make-wifi-fast@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/make-wifi-fast --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org