From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Sat, 20 Sep 2014 22:29:25 +0000 Subject: Re: Correctly calculating overheads on unknown connections Message-Id: <541DFFC5.2000105@gmail.com> List-Id: References: <541C9527.1070105@yescomputersolutions.com> In-Reply-To: <541C9527.1070105@yescomputersolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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.