From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 B304221F212 for ; Sat, 23 May 2015 22:15:13 -0700 (PDT) Received: by obcus9 with SMTP id us9so36679159obc.2 for ; Sat, 23 May 2015 22:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=S8jmkDV7o0G3h9v/IhuLfzixJshFnJM3rIM7AqwnNxo=; b=vDGJ84QLY3ZIvndg8/45qF0vmUwVRqWmMBIe00ZuSmi6mTYiJ6FzwKmFR18Ut+1I1s nvg953BGndyhlU3z8B3AZXhfJvPeUAYDWFtYjOLhUXaU60o8b0S/jlw3BkajzZKfZmQd Oc9KkdiSORCibAH8GEpj7bccrQlVwOGKdcad/xS8DRgMLUcBegj3/cBEqMhJbgo5cg5O 1TNFLsbfSV8nwxosqo16mPAKloTOh93J+WNqjj0QVqUym1sU3iSMmF7dndAwzAATNMvp 5Ryhdw9MJsyW5vwtp9BqbWClHittiiyVp/XwM24j0dqklevLWNcokQzm29OOTOsSlV1C YXvQ== MIME-Version: 1.0 X-Received: by 10.202.71.84 with SMTP id u81mr4673285oia.81.1432444474119; Sat, 23 May 2015 22:14:34 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Sat, 23 May 2015 22:14:34 -0700 (PDT) Date: Sat, 23 May 2015 22:14:34 -0700 Message-ID: From: Dave Taht To: cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [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: Sun, 24 May 2015 05:16:00 -0000 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. Even what i did below is kind of wrong, but it did have satisfying results for kicking in the cake ecn overload and-switch-to-drop behavior, and stomping on slow start before it got too out of hand. tcp's behavior is quadratic to the buffering... (it is too late at night for me to think harder on that), and a queue is there to absorb bursts (and also too late to think on this) anywhy, here so we end up at 100mbit at ~340 full size packets max with byte limits, and about 2000 acks. Compare this to the packet limits in the sqm system (800), which were developed primarily against testing against 5-50Mbit workloads. On the one hand I have hope we can always use less memory with a byte queue limited qdisc system while still preserving good reverse direction performance. (yea! makes for saner small router behavior) 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. 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. if(q->rate_bps) { u64 t =3D q->rate_bps * q->classes[0].cparams.interval; do_div(t, NSEC_PER_SEC * 10 / 4); ^^^^ added the *10 q->buffer_limit =3D t; if(q->buffer_limit < 131072) q->buffer_limit =3D 131072; // 64k too low a lower = bound } else { q->buffer_limit =3D 1 << 20; } printk(KERN_WARNING "cake buffer_limit: %d", q->buffer_limit); --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67