From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) (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 8475D200377 for ; Sun, 1 Jan 2012 21:22:37 -0800 (PST) Received: by wgbdr10 with SMTP id dr10so23057071wgb.28 for ; Sun, 01 Jan 2012 21:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:mime-version; bh=rXqWLeJqjWXhQvji4+BZyykmFNgVXhelHq0E33JDJ/M=; b=Q21SwRTxoo22bvGp3LNVxELR2hVIofCbFqaFfHDplQvg0GIRHKj/muVpGLXxsJOCl2 Pr7iKuLRg0Cb/n5xNo3kUuQFutezat8Nl6ZlBRzt/XZi6bRscPcCo26kG/28d4wboiPi /9Cuh3kXQWD+/lDgqVqBEpAY03s9ZMIeYKqOc= Received: by 10.227.202.142 with SMTP id fe14mr23207421wbb.10.1325481754527; Sun, 01 Jan 2012 21:22:34 -0800 (PST) Received: from [10.170.237.2] ([87.255.129.107]) by mx.google.com with ESMTPS id fy5sm114709369wib.7.2012.01.01.21.22.32 (version=SSLv3 cipher=OTHER); Sun, 01 Jan 2012 21:22:33 -0800 (PST) Message-ID: <1325481751.2526.23.camel@edumazet-laptop> From: Eric Dumazet To: Dave Taht Date: Mon, 02 Jan 2012 06:22:31 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.1- Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Cc: bloat Subject: Re: [Bloat] finally... winning on wired! 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: Mon, 02 Jan 2012 05:22:37 -0000 Le lundi 02 janvier 2012 à 01:40 +0100, Dave Taht a écrit : > SFQ has generally been quite good in many respects. SFQ also does > improved hashing on net-next. But: QFQ seemed very promising also, and > it took until now to see it clearly, with BQL turned on. > > To look in more detail at sfq vs qfq, under even heavier load: > > http://www.teklibre.com/~d/bloat/pfifo_sfq_vs_qfq_linear50.png > > It's really very rare in my life that I've seen a win vs an existing > system of these orders of magnitude. It's taken me a week to make sure > the results were real, and repeatable... I thought about sitting on > them for a while longer actually. I'd really like someone else to > repeat these tests and tell me I'm not seeing things! > > I have hopes QFQ will do even better at 10Mbit vs SFQ. Happy New Year Dave This makes no sense to me. For most uses on a host or residential router, SFQ should perform the same than QFQ. QFQ is the thing you want to use on a big node, when SFQ limits are reached (SFQ as implemented in linux : at most 127 concurrent flows, and at most 127 packets in queue. This could be changed with an increase of memory cost [ which are really small anyway : about 4 Kbytes per SFQ queue ]. A "nolimit" implementation could use a dynamic memory allocator schem, eventually consuming less memory on typical use :) Please try the patch I posted this morning to solve this SFQ bug. http://patchwork.ozlabs.org/patch/133793/