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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C8B463B260; Thu, 5 May 2016 14:33:24 -0400 (EDT) Received: by mail-oi0-x22a.google.com with SMTP id k142so112831670oib.1; Thu, 05 May 2016 11:33:24 -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=LuUB+BifWMHpAztikCtTQcncD51Zn19qCpkTWp7zgpE=; b=MNwKQuJTOw9nzmvd7AHz1GWLW+b4FX0RQNbYREs/zk+yxCE3Q68fQ12C6opjKpmt00 +zqKm8H8T3GAvqLzOTtx7lR9kgvaCXm7axZUe4hC/bdhDOWZ/nSZL5TEPwtpiHEStX/0 C5WCrkOxRDa3VeY8Wr34fkgk2pNh3a4CujnShOhJaxOJpjB5DMl8G7EWWVYl5VUVTrR+ CA7Jxdx2OzAOT+K6pdSvfCl3avkxiEfSFopimMGyd5vS3G5YgMZfcJ951yOycSR4QvaM v5NX4zHH9GzI77DAhAk1rECJ732nmMcJ71WRraEo7bFsIdg0ua/24cuCE2b/FxCB2DgN GNNw== 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=LuUB+BifWMHpAztikCtTQcncD51Zn19qCpkTWp7zgpE=; b=HZVK8XEmdlTBs0EuMtmouhcd+hWGYXYNoqYdTGvhBvLM3lu+e7QhnURLbjEbl64e9V 40KfE9ZfwzjRpes1IZu1AOG/vlwjQh/BKtk3N4H07Yi8DTVczPyjtEV8ducdCmnMdoW5 PZNnwNEa8nFUvANzINqNAZO3q0013ayXhqAkP3ZWA9xeuLCT/di+Ifdq5nfgaUdur7Pm Yk8TU6rn1pRD+87Eo+SJXK9dmQlQbyUqR7Np+88b1EexK3Dd0D0eT/cP6lUWaDhQdqfF 0E9YbSZVJ/p2lU4PuTwny1BB+2a1sT9XrLofpTLBDhyN//937GboaPzjYvLLE1COIHA1 lCLw== X-Gm-Message-State: AOPr4FWgijvMVeMYZcV5tlTbcHQ+0DOvGrfa8BCaflSK5yAcgFTAeyjfkxrTWOdwAgqZg2tfnSyTe79zc95s6g== MIME-Version: 1.0 X-Received: by 10.157.57.200 with SMTP id y66mr7051952otb.169.1462473204097; Thu, 05 May 2016 11:33:24 -0700 (PDT) Received: by 10.202.81.76 with HTTP; Thu, 5 May 2016 11:33:23 -0700 (PDT) In-Reply-To: <2D83E4F6-03DD-4421-AAE0-DD3C6A8AFCE0@gmail.com> 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 11:33:23 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Cc: Roman Yeryomin , Eric Dumazet , make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" , ath10k Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [Codel] 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: Thu, 05 May 2016 18:33:24 -0000 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 > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org