Re: Correctly calculating overheads on unknown connections

[Andy Furniss <adf.lists@gmail.com>]

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.