From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-iad.dyndns.com (mxout-035-iad.mailhop.org [216.146.32.35]) by lists.bufferbloat.net (Postfix) with ESMTP id 6EB752E04DB for ; Thu, 24 Mar 2011 07:20:09 -0700 (PDT) Received: from scan-11-iad.mailhop.org (scan-11-iad.local [10.150.0.208]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id A99BF371297 for ; Thu, 24 Mar 2011 14:20:08 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.161.43 Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id 338BA3712A6 for ; Thu, 24 Mar 2011 14:20:08 +0000 (UTC) Received: by fxm3 with SMTP id 3so116559fxm.16 for ; Thu, 24 Mar 2011 07:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=x0M0s/1cNbie+JZwBtSHYfCcnDaGyv5usQu01QttLUA=; b=YQ7Y5dJSbPtBLVlW4i+EGy0PQXhBzH5zNb1Iad8SF0+XDG0uCGmCnkTBo3b8qyln2M UCf0UKrAD8ILGHASit7zJU4si2zAwUBHY1pWcF/9XWqqpEqr0hwMj9ziuv2/x5noIPGk gW3ownKBx+Zr6vtf+lUHxLzjzqkFcQcxNa1qs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=bQXPFNnGYTlP8gLS/J0/P7NidXmF7sD3NNQVhqxlVBK+FH3PBwKkzeF6gBs/TLwD8t OrscSCfmUuytoA0EJCT4J+yAKhkMlwQzh3GH6J7vQhaCSLTDINWjzXF4YkHR8oT4yV6C +ct+20CzFk4Z4RVnBhBl4BZkSSPSuI9SrTLLc= Received: by 10.223.16.148 with SMTP id o20mr4814818faa.149.1300976407344; Thu, 24 Mar 2011 07:20:07 -0700 (PDT) Received: from [10.150.51.210] (gw0.net.jmsp.net [212.23.165.14]) by mx.google.com with ESMTPS id e23sm3942856faa.18.2011.03.24.07.20.05 (version=SSLv3 cipher=OTHER); Thu, 24 Mar 2011 07:20:06 -0700 (PDT) Subject: Re: [Bloat] Thoughts on Stochastic Fair Blue From: Eric Dumazet To: Jonathan Morton In-Reply-To: <1EC45925-8DE2-4ABA-83AE-09A8E2290100@gmail.com> References: <7imxklz5vu.fsf@lanthane.pps.jussieu.fr> <160809C8-284C-4463-97FE-0E2F03C08589@gmail.com> <1300973556.3747.9.camel@edumazet-laptop> <1EC45925-8DE2-4ABA-83AE-09A8E2290100@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 Mar 2011 15:20:03 +0100 Message-ID: <1300976403.3747.26.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: bloat-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 14:20:09 -0000 Le jeudi 24 mars 2011 à 15:57 +0200, Jonathan Morton a écrit : > On 24 Mar, 2011, at 3:44 pm, Dave Taht wrote: > > >> Here is the POC patch I am currently testing, with a probability to > >> "early drop" a packet of one percent per ms (HZ=1000 here), only if > >> packet stayed at least 4 ms on queue. > > A fixed time threshold doesn't take into account the wildly varying > bandwidths of connections. For example, 4ms will cause almost any > queued packet on a 33.6K modem uplink (or a 3G or GSM tether) to be > marked, yet with the 128-packet default size for SFQ, a GigE NIC will > typically empty the queue before any packets reach the marking > threshold. > If an ideal value would exist, we would use them, and provide a black box. On my particular test setup I used 4 ms threshold, thats it. You cant solve any problems with a single "super qdisc". We provide many different qdisc (and params) to be able to build complex setups. DRR for example is nice, because it provides an extensive infrastructure. SFQ is good only because its space optimized (I know some setups using 100.000 SFQ qdiscs on a single router) You might want to play with QFQ, we are about to release it. > But perhaps a heuristic such as not marking packets which are the last > in their bucket would be okay, and mark everything else when the queue > is more than half full. Mark everything is not good, RED like algo use probabilities.