From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pz0-f43.google.com (mail-pz0-f43.google.com [209.85.210.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6424920051B; Thu, 30 Aug 2012 16:06:41 -0700 (PDT) Received: by daku36 with SMTP id u36so2089315dak.16 for ; Thu, 30 Aug 2012 16:06:40 -0700 (PDT) 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=ZxGipbEp9dulX4eF2fQOb5cswie2LhvYZb/SQl3lNB8=; b=V7kiEK+HsKDK1SzeRWJVofTDFgOg4/xQdetX/jCelzPvw7K4AqOFQXbtLfFHQjfZxB moA8MzbJtZ8I3cZ0hjBi40npQcxKYNx6YNxd4JXIDeZPXCqHYShEOlexciid9Eh/+yjT 7LdyjIeOVLiARl3iDC0nbwLEIOXHBx2GSrx7B4IbvdmSGAJ6+S1o9sM+LY+YBMdqNl4j 2aITpcYM2CXlSUX3cSBdPe+xVnMTCr0e/eK1I4ffsd7j0013t5mjld6drEWgMrubxK+o JuHrzga4H4fECYPbQ9LmA7Ljv3V+xEXgmFsswwq6NIqKenYIiE71AKN04+nUZ8Y/Gaij WjLg== Received: by 10.66.74.37 with SMTP id q5mr12095703pav.29.1346368000522; Thu, 30 Aug 2012 16:06:40 -0700 (PDT) Received: from [10.10.4.254] (0127ahost2.starwoodbroadband.com. [12.105.246.2]) by mx.google.com with ESMTPS id pk9sm2325949pbb.4.2012.08.30.16.06.38 (version=SSLv3 cipher=OTHER); Thu, 30 Aug 2012 16:06:38 -0700 (PDT) From: Eric Dumazet To: Dave Taht In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 30 Aug 2012 16:06:38 -0700 Message-ID: <1346367998.2586.33.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Codel] better mixing in fq_codel 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: Thu, 30 Aug 2012 23:06:41 -0000 On Thu, 2012-08-30 at 15:59 -0700, Dave Taht wrote: > I have finally found the source of the issues I was having with htb + > fq_codel at low bandwidths, and it wasn't htb to the extent I thought > it was. > > It was fq_codel's use of byte quantums, which was resulting in head of > line blocking for multiple streams. > > The undesirable behavior (quantum of 1500) > > A new stream, 15 acks (1500 bytes or so) > B new stream, 4 acks (66 bytes each) > C new stream, 1 packet, 1500 bytes > > Each stream would be delivered in an entire quantum's quantity before > the next. This is basically something that is nearly unnoticable at > higher bandwidths, but down here in the slow moving mud, it's quite > significant. At 1 mbit, 1500 bytes is forever... > > Better mixing behavior results from > > A 1 packet > B 1 packet > C 1 packet (if not larger than quantum) > A 1 packet "" > B 1 packet "" > ... > > While I have a patch for this (all 5 lines of it), which does this > sort of mixing, it crashes under load, but I'll get there. Behavior > before it crashes is rather nice, where before I was observing > something like 36 ms of delay with htb for: small packets, "sparse" or > ANT streams under a variety of loads, it drops below 3ms in the > general case for those. Both qos-scripts and simple-qos benefit > hugely. > > One of these three sets of changes to fq_codel_dequeue or enqueue is > dubious. (well, I have a half dozen other patches and fixups to codel > and fq_codel in the queue too, so have to rip out each). But yea! this > is the low bandwidth behavior we want! You dont need a patch, fq_codel has a quantum parameter, default to 1514 Just set it to 256 if you really feel the need.