From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by huchra.bufferbloat.net (Postfix) with ESMTP id 6728421F1CB; Mon, 6 May 2013 13:47:39 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r46Klba6012608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 May 2013 16:47:37 -0400 Received: from localhost (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r46KlZ8e024719; Mon, 6 May 2013 16:47:35 -0400 Date: Mon, 6 May 2013 22:47:32 +0200 From: Jesper Dangaard Brouer To: Jonathan Morton Message-ID: <20130506224732.1795f13a@redhat.com> In-Reply-To: <81045B4C-0636-48BD-8191-E257F433F795@gmail.com> References: <51817A6F.1080006@superduper.net> <86AA48E0-B5CD-4A94-AF2B-D75178E8C660@gmail.com> <5181CD56.9050501@superduper.net> <20130506195438.5df6d1cd@redhat.com> <81045B4C-0636-48BD-8191-E257F433F795@gmail.com> Organization: Red Hat Inc. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Re: [Codel] [Bloat] Latest codel, fq_codel, and pie sim study from cablelabs now available 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: Mon, 06 May 2013 20:47:39 -0000 On Mon, 6 May 2013 21:46:35 +0300 Jonathan Morton wrote: > On 6 May, 2013, at 8:54 pm, Jesper Dangaard Brouer wrote: > > > A flow is considered "new" if no packets for the given flow exists > > in the queue. It does not have to be a truly new-flow, it just > > have to send packets "slow"/paced enough, that the queue is empty > > when the next packet arrive. > > > > Perhaps VoIP would fit this traffic profile, and thus would work > > better with the Linux fq_codel implementation, compared to the > > SFQ-Codel used in the simulation. > > That doesn't work, because the with a sufficient number of BT flows, > the flow queue containing the VoIP flow is the fullest queue, not the > emptiest. That's independent of the number of flow queues, including > the infinite case. Think about it carefully. Yes, I agree. And as I mentioned, with the fq_codel implementation details, this is going to hit even earlier, as we have a limited number of flow/hash queues. > Looking at the implementation, it does have the problem that the match > for "if the flow already have packets in the queue" just looks to see > if the hash bucket is empty. Thus 2 stream sharing a hash queue throw > this off. -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer