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.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
