From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (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 11B5F21F1BA for ; Sat, 28 Dec 2013 23:24:40 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id p61so9447778wes.3 for ; Sat, 28 Dec 2013 23:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8Zc6HUvjl2kpzo6DPxReRQu56tN96aXHPj5CgDK6tnM=; b=ApK9sXMSHRkRlHf9Igbt1PmEaFERqRVVKlwQR3RL0zfqE7JsUurw6e1DYtzGWl+kSD oasqIRvUFQkdE2xi7eGNiCwYxRBbq7DKKvZ0RY5LGk+5THdvvP+p5MevQnNHlcok+kws UE8SgX2R/8zorMPwsapktpGpcVEtu8tFdIV2tiRheApup9nqXS1eQwOOKLrgDM3dLt6O 8VMEyZzzgdX+GZSXQZSTzhcd9E6+hHbXRIRp1Hg6Sk78opdOMz4NgKul2FjCDzNOvKSK 4oQt9fWgkCU8U47EItC+tKlOTdEiyZEvVEnzOP2Lo4M4elVg9s1GZUneVQsBm/+FoQCz zTGA== MIME-Version: 1.0 X-Received: by 10.194.90.144 with SMTP id bw16mr40043230wjb.1.1388301878487; Sat, 28 Dec 2013 23:24:38 -0800 (PST) Received: by 10.217.123.69 with HTTP; Sat, 28 Dec 2013 23:24:38 -0800 (PST) In-Reply-To: <2E760E83-7224-4B9B-B918-B3EAD578E831@gmail.com> References: <2E760E83-7224-4B9B-B918-B3EAD578E831@gmail.com> Date: Sat, 28 Dec 2013 23:24:38 -0800 Message-ID: From: Dave Taht To: Rich Brown Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] SQM Question #4: What are the major features of simple.qos, simplest.qos, and drr.qos scripts X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 07:24:41 -0000 I ended up taking today off and not trying to do an edit, and I'm only going to try to answer this one question tonight as the others are too hard for this time of night. Thank you for breaking your questions down into bite sizes pieces. On Sat, Dec 28, 2013 at 8:35 PM, Rich Brown wrote= : > QUESTION #4: What are the major features of (and/or differences between) = the simple.qos, simplest.qos, and drr.qos scripts? Simplest.qos is the simplest possible htb based shaper, with only a single fq_codel qdisc (with 1024 queues) Advantages are that it does optimal mixing and uses the least memory. (it works pretty good down to about 16 queues actually) Simple.qos is a three tier system that can use diffserv and simple prioritization to give or remove priority to certain kinds of identifiable flows. Right now it gives priority to locally generated dns and ntp packets, and a couple diffserv markings, and deprioritizes CS1. It would be nice if it was feature-competitive with qos-scripts, which have (for example) l7 inspection to find common torrent-like protocols, and a gui with lots of knobs to control that aspect. I waffle on calling things "tiers" rather than "queues". "levels?" "Bands?" Band is used in the pfifo_fast and prio qdiscs, maybe we should call it that. A queue can be a queue, but an fq_codel queue consists of up to 64k flows which can also be considered queues. And it's turtles all the way down. drr.qos snuck in there accidentally on a commit. It's not functional and I should remove it. I'd intended to build up a emulation of more or less exactly what free.fr has deployed, but haven't got around to writing the code. Their system: prio 1 Strict priority fq_codel prio 2 -> DRR 1 Best Effort fq_codel (80% weight) -> DRR 2 Background fq_codel (20% weight) The advantage of it is that you can run it without htb at all and still get a 3 tier shaper that works at *line rate*. (free wrote their own very tight DSL driver and doesn't have to muck with htb on egress). A disadvantage is unless the prio 1 queue is well admission controlled... it can starve the best effort and background queues. (originally, maxime at free tells me that this was a 3 band prio shaper but found that too much traffic was marked background, and too easily starved. I hope that this will be the final nail in the coffin for advocates of strict prio queues in general use) If we ever get around to trying to get tbf working perhaps that + a free.fr-like system might be more cpu efficient than htb. "Cake" if I ever get around to finishing it does a form of weighting for 3 bands, and can't starve a queue under any circumstances. Me being me I emulated this with qfq first, but qfq is too heavy.... I will probably use free's example in an upcoming rfc. PS I'd like to do a writeup/rant about everything that is wrong with wondershaper and get it published somewhere that will knock various links to it out of the top spot on google. PPS perhaps a glossary of terms is needed, for things like "band", "admission controlled", "starvation", weighting. > I=92ll use this information to flesh out the Details=85 section for that = section of the page. > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html