From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 33BD83B260; Thu, 5 May 2016 14:16:32 -0400 (EDT) Received: by mail-oi0-x236.google.com with SMTP id k142so112278963oib.1; Thu, 05 May 2016 11:16:32 -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=QDWV6CNQXce6R+Od1aCtt1/HDQxkSn0oKqmtGwVPwcQ=; b=v3zZdMhEIJbomiUlTbdxTZ6ey4WP0YV+w6995pCf0qGj53h+7TRI62wpHO56LY1Nob TbQndpU0Kva80G9/m4vZQ5j8Cdm/k8cyaQ+0xM3FMLorvkonncp+ISItYP1lo49ygYjZ ukOzCBK+ewLRgHcd5Fgjp106oPSIrJ6gubMlOVT0f7e/UnoxiwQ3GhhYcIUZmtvH+9Uh I0YNsrv5TtZCndbpj2Yu2IYxNg1ndldTIgyv75AwVyXecs4JvVjMFw7AQ1p7bgi1X6/e no86AOE6V+wWVFJhBxm5mlarWf2GzPIt6Yg8wRrM2ClThScZx946uVahC/tu7hjEKSAa PI2w== 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=QDWV6CNQXce6R+Od1aCtt1/HDQxkSn0oKqmtGwVPwcQ=; b=WTJPz714hwycYHqm/2XNZdtS0HR4RUr+/D4dCTtwS2//uchkD+lcMLzKnhhFkFMR4/ eiM8mL8gefX+L4AIVn1c8KY5sVc43cCJERec3GemphnS+Z0CS903JcoZ1b5H1CFa3kEQ Lz3nfXV048ubVjNfVjjmvLwOHhEwvmin6w89SxgxazYNxnW1tOAduqp27FQBP06RWFY5 vWsVfKnvRcqlz6PXBHXLW1s8XAHGFryqZg4fechXm/onvCA0K4j78RgpNFNx7viLeGLe 5cuB9CChryn0nKG4bvyvhWk2l1c8vxw0tiodvkh1/TfFF+hmUNOwYIrTXGLJSyJZvvXi oy5Q== X-Gm-Message-State: AOPr4FWtWxo/xLJJUgWte9lGvh19QuVNN3xUY2iiO/uaQeTOmWZ/OnkJnII+Lj1V+7I8ZNFz9/mPvSmmII6aKQ== MIME-Version: 1.0 X-Received: by 10.202.217.67 with SMTP id q64mr7805392oig.151.1462472191694; Thu, 05 May 2016 11:16:31 -0700 (PDT) Received: by 10.202.81.76 with HTTP; Thu, 5 May 2016 11:16:31 -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 11:16:31 -0700 Message-ID: From: Dave Taht To: Roman Yeryomin Cc: Jonathan Morton , 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: [Codel] fq_codel_drop vs a udp flood X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:16:32 -0000 On Thu, May 5, 2016 at 10:39 AM, Roman Yeryomin wro= te: > 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 b= atches of consecutive packets, Codel is also still dropping individual pack= ets 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 = most other AQMs, and definitely on RED variants, including PIE. Fortunatel= y for real traffic, it normally arises only on artificial traffic such as i= perf runs with large UDP packets. Unfortunately for AQM advocates, iperf u= ses large UDP packets by default, and it is very easy to misinterpret the r= esults unfavourably for AQM (as opposed to unfavourably for iperf). >> >> If you re-run the test with iperf set to a packet size compatible with t= he path MTU, you should see much better throughput numbers due to the elimi= nation of fragmented packets. A UDP payload size of 1280 bytes is a safe, = conservative 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? How about: completely dropping your hand-picked patch set and joining us on michal's t= ree? https://github.com/kazikcz/linux/commits/fqmac-v4%2Bdqlrfc%2Bcpuregrfix He just put a commit in there on top of that patchset that might point at problem you're seeing, in particular, and the code moves all of fq_codel into the mac80211 layer where it can be scheduled better. I'm still working off the prior patch set, finding bugs in 802.11e (that for all I know pre-exist): http://blog.cerowrt.org/post/cs5_lockout/ (I would love it if people had more insight into the VI queue) and I wrote up the first tests of the prior (fqmac 3.5) patch here: http://blog.cerowrt.org/post/ath10_ath9k_1/ with pretty pictures, and a circle and arrow on the back of each one to be used as evidence against us. I did just get another 3x3 card to play with, but I'd like to finish up comprehensively evaluating what I got against mainline first, at the bandwidths (ath9k to ath10k) I can currently achieve and that will take til monday, at least. Since your hardware is weaker than mine (single core?) it would be good to amble along in parallel. >>> 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 num= bers 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