From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) (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 7857521F1AF; Wed, 28 Nov 2012 11:00:26 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so7653893dak.16 for ; Wed, 28 Nov 2012 11:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=6F9ljps3UVtfRvbT45RC8Xwg75LfvqkRZ2GLx7FWf6M=; b=SNCrZVquBSAXcqhIdySNzEkxd6C2srz4SOHp8I2D5Jp6OaMt0Ffo8YiUTcBAjYrpbm Q3zGlH3cte5Y1yyO6c/C+FI7YX652ZaoOR9xHkplVPrHEAOTMUlCN3ztFr3p4oaZHYC4 U2La7Q1Sc2tLBiWuiKpZ+SY16mSzrNVeq/tlZlMETAAgZJKZ5Nt9s2dBP2sAKw5HmSFd H/QP/xdkCpzNBaNnjYxNZNkXoobHY9oskZg9HqSxrH2/I89yO0UIHDlzpVlO83u912At PFZ6Vw1MaDdwKmiE/9xdwtbKkt6xGJho4IkOsJ3izI9t1UUA/tHeLxXkfHgJNjebk/Nx GDBQ== Received: by 10.68.137.234 with SMTP id ql10mr60458242pbb.158.1354129226107; Wed, 28 Nov 2012 11:00:26 -0800 (PST) Received: from [172.26.49.229] ([172.26.49.229]) by mx.google.com with ESMTPS id r6sm254930pax.24.2012.11.28.11.00.23 (version=SSLv3 cipher=OTHER); Wed, 28 Nov 2012 11:00:25 -0800 (PST) From: Eric Dumazet To: paulmck@linux.vnet.ibm.com In-Reply-To: <20121128174440.GD2474@linux.vnet.ibm.com> References: <20121127224915.GM2474@linux.vnet.ibm.com> <20121128002710.GS2474@linux.vnet.ibm.com> <50B5887C.7010605@pollere.com> <20121128043838.GX2474@linux.vnet.ibm.com> <20121128160133.GA16995@linux.vnet.ibm.com> <20121128174440.GD2474@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 28 Nov 2012 11:00:22 -0800 Message-ID: <1354129222.14302.508.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: Paolo Valente , Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , bloat , John Crispin Subject: Re: [Codel] [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 19:00:26 -0000 On Wed, 2012-11-28 at 09:44 -0800, Paul E. McKenney wrote: > You lost me on this one. It looks to me like net/sched/sch_fq_codel.c > in fact does hash packets into flows, so FQ-CoDel is stochastic in the > the same sense that SFQ is. In particular, FQ-CoDel can hash a thin > session into the same flow as a thick session, which really is the > birthday effect. > > Now FQ-CoDel uses a 1024-bucket hash table compared to SFQ's default > of 128 buckets, so FQ-CoDel will have smaller collision probabilities > than will SFQ on a given set of flows. In addition, FQ-CoDel seems > to be able to tolerate a limited number of collisions among thin flows, > while SFQ doesn't distinguish thin from thick. > > But the possibility of stochastic collision behavior really is there > with FQ-CoDel. I hasten to add that in practice, I do not expect this > possibility of stochastic behavior to be a problem in the common case. > > Or am I missing your point? Or perhaps your definition of either > fairness or stochastic? Thats absolutely correct, fq_codel uses a stochastic hashing exactly like SFQ. In fact, I wrote fq_codel using same base, after patching SFQ and hitting some limits last year. Note that I played a bit with a version using a non stochastic hash, we tested it here in our labs. This can help if you really want to avoid a thick flow sharing a thin flow bucket, but given that all packets are going eventually into the Internet (or equivalent crowded network), its not really a clear win. Its more an academic issue...