From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 76FCA201253; Thu, 2 May 2013 15:07:01 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id e36so874996iag.33 for ; Thu, 02 May 2013 15:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=WUtxX6M0wBpG1V73jyqS+EA3iwJX1zb1xXV75bSXThA=; b=EjBvK5L8TVE4M8gibXajcG6tOH4QqcDXwv1hAZ9EbMWzX7WYiRwZLV3IWY6nIzkLJV b+boa+ZXeUg5ZFnonMR0jrCxfsYCq016VMev+ireYWcohUgc+N35/1YkU/xiDf/Ar8/S hM/CY7A+MXO01fT0Pw9O7SDFAofqU/muVFR9/RMDjbgMszjAy+7X8KZK/LxVjmNolSHL IEwYpEfH72DcgraeJLbwWV1c8HZWlVAZne7Keb115PKmYPXvJU9GsEZDUz481/AqHPBM FoYjDQKUQ0JR+HPBMh+0UVHDuv9jLg63hD2htdbVmN3o2sfpJJwkojKFLuZFO5jsxbLk T2GQ== MIME-Version: 1.0 X-Received: by 10.50.236.100 with SMTP id ut4mr15101783igc.86.1367532420763; Thu, 02 May 2013 15:07:00 -0700 (PDT) Received: by 10.64.7.51 with HTTP; Thu, 2 May 2013 15:07:00 -0700 (PDT) Date: Thu, 2 May 2013 15:07:00 -0700 Message-ID: Subject: optimizing for very small bandwidths with fq_codel better? From: Dave Taht To: bloat-devel , cerowrt-devel@lists.bufferbloat.net, Jonathan Morton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 22:07:01 -0000 Given some of the keruffle over bittorrent, and voip traffic in relation to the cablelabs report in relation to the effects of fq at very high numbers of flows (100+) vs the priority traffic like voip, at very low (4mbit and lower) bandwidths.... and no matter that the default hash on fq_codel is *very* robust, at lower bandwidths some optimization is desirable, and people seem to have a general need for control and classification that seems unsatiable... And adding a classic three or four band shaper is a little difficult, but using something like classic fq "weights" was, theoretically not... so, anyway, I sat down and fiddled with the tc command to try and generate a set of filters that would scale better below 4Mbit, deprioritize bittorrent and background traffic, do gaming and ef traffic better, AND (most importantly) work without HTB when possible, while still retaining the base simplicity and most of the advantages of fq_codel. It's very short and can be applied to anything to play with (although in my case I slow down my laptop's ethernet port to 100Mbit so I can fill the queues) Very short, heavily commented, 14 line attempt: http://pastebin.com/bRmW9YD3 It isn't done. 1) I think there's a bug in either the kernel or tc or me on tos matching, 2) and there may be a useful feature to add to tc for doing smarter filtering when you have multiple sets of bins... 3) and it seems like you'd have to use iptables to match for torrents and then use a fw match? so perhaps there is someone more expert on tc than I out there or with more patience to fiddle? --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html