From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (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 2C19D3B260; Thu, 5 May 2016 13:39:20 -0400 (EDT) Received: by mail-oi0-x244.google.com with SMTP id i2so15121304oib.3; Thu, 05 May 2016 10:39:20 -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=aKXXB2I8//QzL0pgQzF7bLtIinw6B0cIYpLVAQJSkqw=; b=oshOZlIj+RBX06HMGYvjSfJgZyAtxtba5M5y/Xqur0zZo6/SGQ87JQwjS5xnVRJzao 9U5+oAtHnnsuzHbBqhuSDYn1Ab8wEwsL90fSzRBlKex0ztOfermH7My8vSvdRHqKpKp3 dM7LwCnBqZAAREoDgd9IqTzX1zj7S+AqP14PmokuM6UDwRI/diJIoj017KKczkDC7FF5 5eENjjRdbugf1xVvHVsSfVx3jJiHSTnTRVh8+yHK1OXs6+XH0EuPCLMkySUpM1JtRSjB 37kAmzPQ+feJ9cNAl8HBa+Rqm8F12NkPpbjI7HdG3Yb87daJlmmKJq9spK7Rm3MDwIqP U/VA== 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=aKXXB2I8//QzL0pgQzF7bLtIinw6B0cIYpLVAQJSkqw=; b=GiHQGo6CJbvbPmSSvEykZI8Qheg/yVovBuJ6MBugnrg7l7hpPXo5DFwnGlbK/Qj4Aq m5SF61gbdyfHylmNKaZJz50UvJGiBzXGrI4Z6V4hvwWKUOjqMUnQb3/tuFfUQa+Y6PAO HqD/KM0p0/pSNBYx/44i/5f0PUQhMfJHDtcXejHskWntEHzfwlcYEVkNxVCJfgTVyGk9 TUBJ6k4a9goT2sIiMJAXXp78/7UQ4ZTTKQ0frlYU0VUX/jR6bgAI+mLRXZiGUJQIPcAf LC9iEqgqNbCNl9snToyRBZBOX1JU7H7SHpaMkjDBepkw63sDrKn7ftBqJL/xMqBO4mPA jWyg== X-Gm-Message-State: AOPr4FXezuVvjUuL9PfNhspCscG9QG/wJjZ1bMS8lEYf2eX8iWR2FLsZFTwsB//8KR8Qtkic1ecD9wBgJm0xag== MIME-Version: 1.0 X-Received: by 10.202.186.132 with SMTP id k126mr6590326oif.113.1462469959658; Thu, 05 May 2016 10:39:19 -0700 (PDT) Received: by 10.202.252.9 with HTTP; Thu, 5 May 2016 10:39:19 -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 20:39:19 +0300 Message-ID: From: Roman Yeryomin To: Jonathan Morton Cc: Dave Taht , 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 17:39:20 -0000 On 5 May 2016 at 19:59, Jonathan Morton wrote: >> 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. > > 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. Setting packet size to 1280 (-l1280) instead of 1472, I got even lower speed (18-20Mbps). Other ideas? >> 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 >