From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (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 4684F21F544 for ; Sat, 20 Sep 2014 15:29:25 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so943297wgg.32 for ; Sat, 20 Sep 2014 15:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=H54gkpd5GBj/IGNR28xHbvee9YHBI4CahnCBEp4Xb3o=; b=0HMXTY8yCz7vttwXNG2DRb8rFuAdhHupPNQV1yggBOBV9L7Bf2RUx8mA6iMto4acgw CohoLAQRVwt9EyFdGExnqDLFWpp+J4AafJplNgxbKSzQghj4PrIOZzbiUE8EOOQQShKp PaW+M/odg13eE/A9CCY5JUVLuYmmOBF+fhOooOD/ISAeb5i15wW5sqfYCGHqRC9EQWqH NQjI409tdU95g1GF5nFwCeO3EEFndKfc8SV5eoc0un68o+12Vl7UR6CXeRTYSg9SrzmK w/s7Mf2vl1UGb29LTKFI39zlOhcT3wvYSNbK4yLPXYqCrMGkDEzv2WMdqa/T7YGwr/jA 8DxA== X-Received: by 10.194.191.135 with SMTP id gy7mr9969381wjc.39.1411252163600; Sat, 20 Sep 2014 15:29:23 -0700 (PDT) Received: from [192.168.0.3] ([81.174.180.31]) by mx.google.com with ESMTPSA id pn5sm6957437wjc.4.2014.09.20.15.29.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Sep 2014 15:29:22 -0700 (PDT) Message-ID: <541DFFC5.2000105@gmail.com> Date: Sat, 20 Sep 2014 23:29:25 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Dave Taht References: <541C9527.1070105@yescomputersolutions.com> <541DA8B5.70701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Sep 2014 10:01:39 -0700 Cc: "cerowrt-devel@lists.bufferbloat.net" , Alan Goodman , "lartc@vger.kernel.org" Subject: Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections 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: Sat, 20 Sep 2014 22:29:54 -0000 Dave Taht wrote: > We'd had a very long thread on cerowrt-devel and in the end > sebastian (I think) had developed some scripts to exaustively (it > took hours) derive the right encapsulation frame size on a link. I > can't find the relevant link right now, ccing that list... Thanks, that sounds cool. >> Sfq was only ever meant for bulk, so should really be in addition >> to some classification to separate interactive - I don't really get >> the > > Hmm? sfq separates bulk from interactive pretty nicely. It tends to > do bad things to bulk as it doesn't manage queue length. Well I come at this from years of qos stuck on 288 then 448 kbit up atm dsl before the days of fq_codel. Since it got jhash sfq does at least manage to avoid collisions, but it's still a total non starter for use alone on a slow link because the interactive packet may wait for many bulk packets to dequeue before its turn. Of course sfq is cleverer now than it used to be - headdrop and red the latter I've not used. I agree it's bloaty for bulk, but that's not quite so critical if your real buffer is not bloaty if you can get classification to work. > A little bit of prioritization or deprioritization for some traffic > is helpful, but most traffic is hard to classify. > >> bufferbloat bit, you could make the default 128 limit lower if you >> wanted. > > htb + fq_codel, if available, is the right thing here.... Yea, though on a link like my old one I still think classification would just win. I should test really, but IME a slow link can be hard to simulate (I have 20mbit up now) - the results tend to look a bit better because of no real bitrate latency.