From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4AE0C21F21F for ; Sun, 24 May 2015 21:47:26 -0700 (PDT) Received: by lami4 with SMTP id i4so42687361lam.0 for ; Sun, 24 May 2015 21:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GfTfKXQKvYGuSiMI6UyXU/11yXaDGcqVy4r4INd0y+8=; b=P9z3G21I5+ChHVLWcvLkduFBYcSu1DOWShaREChdG4QijbJplIwZFm8e24X3c5qJLD OGWY002wP5mta9naN4uhkNH3QIhbg9HJPntSjX//7e+jOOE00DZTKNXkRJTjfevJchVb ToGpa8w6Zd6XqGCujJirpEMU+sAn266GLdvWL1tbMX9WU4Ih2HlCu36dxcXAdB4XBcML l0LhbvTBX/ntkZve2dx0JOv4IcTD1iX9CP3RROBch4GpThipEPwhbrlq1/cE1I6lYauy cUO0Az186xRLCFQmKDuMaeHrh74LgQ4ooId0nUKR219mLa6E00muxUr7JfVaa2vOnUIQ gbtw== X-Received: by 10.112.136.166 with SMTP id qb6mr10431413lbb.54.1432529244748; Sun, 24 May 2015 21:47:24 -0700 (PDT) Received: from bass.home.chromatix.fi (37-136-70-24.rev.dnainternet.fi. [37.136.70.24]) by mx.google.com with ESMTPSA id uq1sm2122133lbb.18.2015.05.24.21.47.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 May 2015 21:47:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Mon, 25 May 2015 07:47:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Taht X-Mailer: Apple Mail (2.2098) Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] cake byte limits too high by 10x X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 04:47:55 -0000 > On 24 May, 2015, at 08:14, Dave Taht wrote: >=20 > at 100Mbit we had 5 megabytes of max queuing. I don't think this was > jonathon's intent, as the default if no rate was specified was 1Mbyte. >=20 > =E2=80=A6 On the other hand codel does not > react fast enough to major bursts without engaging the out of > bufferspace cake_drop which is pretty darn cpu intensive. The 1-megabyte default is not intended to reflect the highest possible = link rate. Frankly, if you=E2=80=99re triggering cake_drop() without = involving truly unresponsive flows, then the buffer limit is too small - = you need to give Codel the time it needs to come up to speed. I = definitely should make cake_drop() more efficient, but that=E2=80=99s = not the problem here. I consider it *far* less important to control the short-term length of = individual queues, compared to the latency observed by competing = latency-sensitive traffic. And I also think that ECN and packet-drops are too crude a tool to = control queue length to the extent you want. Hence ELR - but that=E2=80=99= s still in the future. (How much funding do you think we can get for = that?) > On the > gripping hand there becomes no right outer limit for a wildly variable > 802.11ac wifi queue, with speeds from one to 1.5Gbit, but I sure would > like a cake-mq that handled the existing queues right with less > memory. Something that I haven=E2=80=99t had time to implement yet is a = dual-mode FQ, performing both flow isolation and host isolation. That = seems like a step towards what wifi needs, as well as more directly = addressing the case where swarms and sensitive traffic are running on = different endpoints, without Diffserv assistance. However, the overall design I have in mind for a wifi-aware qdisc is a = little bit inside-out compared to cake. Cake goes: shaper -> priority -> flows -> signalling -> queues =E2=80=A6or, with host isolation added: shaper -> priority -> hosts -> flows -> signalling -> queues What wifi needs is a bit different: (hosts/aggregates?) -> (shapers/minstrel?) -> priority -> flows -> = signalling -> queues Of course, since the priority layer is buried three+ layers deep, it=E2=80= =99s obviously not going to use hardware 802.11e support. - Jonathan Morton