From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1B85B20061F for ; Wed, 2 Nov 2011 03:05:49 -0700 (PDT) Received: by wyh11 with SMTP id 11so1461906wyh.16 for ; Wed, 02 Nov 2011 03:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=qe0YS5kB8LxrwQBCQcjwSO8b/yHfIB0zSzP2tu9XcM4=; b=jcEwgxjpuV+eRbbvHaj3A3TwYLJNtujvc7oXb0iqD5lxJJ78gJ2DZ+LIn5bMhk51gB SrBVom6/lwgSsPZtQ3IREo0dAK4++o6lwGmEiJA60/TlExnIf2JrqKFzCaquvl3E7Nuh m1Yxz0D42URKUreHCdenpbo6CSUpnVX4iw+zE= Received: by 10.216.198.224 with SMTP id v74mr6017264wen.41.1320228347166; Wed, 02 Nov 2011 03:05:47 -0700 (PDT) Received: from [172.30.42.102] (gob75-7-82-247-114-230.fbx.proxad.net. [82.247.114.230]) by mx.google.com with ESMTPS id l20sm3243124wbo.6.2011.11.02.03.05.44 (version=SSLv3 cipher=OTHER); Wed, 02 Nov 2011 03:05:45 -0700 (PDT) Message-ID: <4EB115F7.5070203@gmail.com> Date: Wed, 02 Nov 2011 11:05:43 +0100 From: =?ISO-8859-1?Q?David_T=E4ht?= Organization: Bufferbloat.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Karel Rericha References: <1319716772.2601.26.camel@edumazet-laptop> <1319731732.2601.40.camel@edumazet-laptop> <1319732832.2601.43.camel@edumazet-laptop> In-Reply-To: Content-Type: multipart/mixed; boundary="------------060507090002020507020401" Cc: netdev@vger.kernel.org, bloat Subject: Re: [Bloat] Quick Fair Queue scheduler maturity and examples X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:05:50 -0000 This is a multi-part message in MIME format. --------------060507090002020507020401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit (Example elided, see thread on netdev) On 11/02/2011 10:36 AM, Karel Rericha wrote: > 2011/10/27 Eric Dumazet: > Thanks for example Eric. But it only added more confusion to me now > :-) I was under impression (and read somewhere) that QFQ is non work > conserving scheduler so I can use it more or less like HTB or HFSC to > set bandwidth constraints to flows. But from this example (and from > sources/patches/papers I try not to pretend I fully understand) it > looks to me like some multiqueue scheduler with arbitrary number of > queues and ability to arbitrary assign flows to this queues. So some > sort of fair division of available bandwidth to flows without > arbitrary bandwidth caps to these flows. This is what I want! It may not be what you want... > I really dont see what is non work conserving here :-S Please save my > soul and enlighten me because I am at dead end now :-) I initially had great hope for QFQ as I've been saying (mostly privately) that "PFIFO_FAST must die" for over a year now. What to replace it with is a rather large question, but I felt a start would be to adopt some FQ algorithm. Over the last couple weeks I read all the papers regarding DRR and QFQ and also poked into the source code and like you, am seriously un-enlightened. I think eric's example is misleading as he divided up the queues by bandwidth, rather than flow, in the first tier of his tc hierarchy. useful as a test... That said, buried in one of the papers on QFQ is the item that it isn't entirely fair queuing, as it has a maximum MSS of 5, rather than 1. Still that would be an improvement over diffserv based classification in the general case, and being somewhat bursty actually helps with 802.11n packet aggregation (at present). Anyway, I've built QFQ into the latest cerowrt and am building it for another machine, and will try to come up with good ways to configure it this week. My use cases are different than yours, however. On a wireless STA (a laptop) - FQ all flows originating from that box. This would, for example, jump a DNS packet, ping, or TCP SYN attempt - to near the beginning of the transmit buffer while another elephant flow is taking place. On the AP, FQ across the clients (so aggregation works better and bittorrent is suppressed), and FQ within each flow from/to that client (so as to reduce head of line blocking and have better performance for things like dns/ping/etc) - this would apply to the internal wireless and wired interfaces. As for the gateway interface, FQ across originating clients as well (but far more stuff than that needs to happen) Haven't a clue how to do any of that right at all, at present. Clues wanted. I emailed one of the authors of QFQ for a clue, no reply as yet.... PS Also along the way whilst poking into that source code I found that there was already a fifo_drop_head tc queue type, which strikes me as almost useful for VO and VI wireless queues... -- Dave Täht --------------060507090002020507020401 Content-Type: text/x-vcard; charset=utf-8; name="dave_taht.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dave_taht.vcf" begin:vcard fn;quoted-printable:Dave T=C3=A4ht n;quoted-printable:T=C3=A4ht;Dave email;internet:dave.taht@gmail.com tel;home:1-239-829-5608 tel;cell:0638645374 x-mozilla-html:FALSE version:2.1 end:vcard --------------060507090002020507020401--