From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 DE3F93B260 for ; Fri, 6 May 2016 00:35:16 -0400 (EDT) Received: by mail-ob0-x231.google.com with SMTP id x1so46502698obt.0 for ; Thu, 05 May 2016 21:35:16 -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-transfer-encoding; bh=Bmj3+QvPjnyHOgiDX6LjMF46FMMu6fdhEtyJJIsvWyo=; b=psCfcXW9vXx5w2LTOJtDRhp9Qxvvj17OOF5xmKLV6DGjixy7ZYiCKOLFA+THE/dzjZ foijGjTGUOlCIf648NsN1lMLLFKfN5DcFwPyxOA82ERAXmAPx4VVHV1O5n2/iLB3siKD ZSbDIFCOs3VELkipqxHl0S38RsTfpO5BB+h6TKoc/vf9WdEGooaC20XHg4PJuefqbbtv GiPao0vxx+By5P1AWKcvJFK2nJPXm8wK0tEItEBHorN9P8o6uZq4FxDmhEiLqoctGDFK uYTr0BEnd6aJbRmyIae8ucFMSl8XeGPuz7f5yHorUMD8rDqjLeJ8h8dugDyE81aCrjux 1m4A== 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:content-transfer-encoding; bh=Bmj3+QvPjnyHOgiDX6LjMF46FMMu6fdhEtyJJIsvWyo=; b=Yfh6tpk96PTHX+Mp8Uxp8J0t3f5Q9LAqdYVuAwKIqUveDO40agpButo0azkKAqSaeN huAGUrV2MLvbsQedauLa9/sEV6gU/jv7wIH/eShMuFvCZbgo5ygzhSfJWUx4G219QmGj PUreEeDpml5U+8FG/LNSUC5FImqt7GFsRv8BS5s5up5xYcccQFzlii0hgKx71Xv/1YpR skF3kck6HCRKeLg5AVce7KjsT06PLY/ai8bAxjfD2jS/81T/tFEJ7OPCYkFlZt2ZzTN1 kXYzelrV5kx9xvvEHz4I6a41NSsWmzs/CIpAH85W7iQeaN2hMqt0ozDUjizIuWBJ6sXS FaGA== X-Gm-Message-State: AOPr4FV7bg3VLOf3F3tbxgy5PLfzxANEj/qQkH15lI9W93lJmdl4c42rCyCSlNEihrQPj2RdkVfWPTQcciryUA== MIME-Version: 1.0 X-Received: by 10.60.129.166 with SMTP id nx6mr6966982oeb.13.1462509316294; Thu, 05 May 2016 21:35:16 -0700 (PDT) Received: by 10.202.81.76 with HTTP; Thu, 5 May 2016 21:35:16 -0700 (PDT) In-Reply-To: References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <2D83E4F6-03DD-4421-AAE0-DD3C6A8AFCE0@gmail.com> Date: Thu, 5 May 2016 21:35:16 -0700 Message-ID: From: Dave Taht To: cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cake] Fwd: [Codel] fq_codel_drop vs a udp flood X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 04:35:17 -0000 this would be a pretty nifty feature for cake to have in this hostile unive= rse. ---------- Forwarded message ---------- From: Dave Taht Date: Thu, May 5, 2016 at 11:33 AM Subject: Re: [Codel] fq_codel_drop vs a udp flood To: Jonathan Morton Cc: Roman Yeryomin , Eric Dumazet , make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" , ath10k On Thu, May 5, 2016 at 9:59 AM, Jonathan Morton wro= te: >> Having same (low) speeds. >> So it didn't help at all :( > > Although the new =E2=80=9Cemergency drop=E2=80=9D code is now dropping ba= tches of consecutive packets, Codel is also still dropping individual packe= ts in between these batches, probably at a high rate. Since all fragments = of an original packet are required to reassemble it, but Codel doesn=E2=80= =99t link related fragments when deciding to drop, each fragment lost in th= is way reduces throughput efficiency. Only a fraction of the original pack= ets can be reassembled correctly, but the surviving (yet useless) fragments= still occupy link capacity. I could see an AQM dropper testing to see if it is dropping a frag, and then dropping any further fragments, also. We're looking at the IP headers anyway in that section of the code, and the decision to drop is (usually) rare, and fragments a PITA. > This phenomenon is not Codel specific; I would also expect to see it on m= ost other AQMs, and definitely on RED variants, including PIE. Fortunately= for real traffic, it normally arises only on artificial traffic such as ip= erf runs with large UDP packets. Unfortunately for AQM advocates, iperf us= es large UDP packets by default, and it is very easy to misinterpret the re= sults unfavourably for AQM (as opposed to unfavourably for iperf). > > If you re-run the test with iperf set to a packet size compatible with th= e path MTU, you should see much better throughput numbers due to the elimin= ation of fragmented packets. A UDP payload size of 1280 bytes is a safe, c= onservative figure for a normal MTU in the vicinity of 1500. > >> Limit of 1024 packets and 1024 flows is not wise I think. >> >> (If all buckets are in use, each bucket has a virtual queue of 1 packet, >> which is almost the same than having no queue at all) > > This, while theoretically important in extreme cases with very large numb= ers of flows, is not relevant to the specific test in question. > > - Jonathan Morton > -- Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org