[Cerowrt-devel] optimizing for very small bandwidths with fq_codel better?
dave.taht at gmail.com
Fri May 3 07:45:09 EDT 2013
On Thu, May 2, 2013 at 10:01 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> On Thu, 2 May 2013, Dave Taht wrote:
>> 1) I think there's a bug in either the kernel or tc or me on tos matching,
> Taking a guess here...
> The TOS byte is 8 bytes. So EF is 46, which is 0x2e, and then you need to
> left-shift it 2 bits because it's the most significant 6 bits, you get 0xb8
> (if my early morning pre-breakfast hex calculations are correct). Try
> matching on that and see if it works.
THANK YOU. I've been making that mistake on EF now for 2 years, over
and over again, in everything. Thank you for breaking me of the habit.
> Some programs use the whole TOS byte, some just do the 6 DSCP bits. I
> usually end up using tcpdump to see on the wire what the program actually
In this case I am hopefully ignoring ECN bits by using 0xfc as the mask.
OK, so I put a new paste up, with the fixed EF classifier.
I also found the option to have an offset to a filter with a hash and
divisor - "baseclass". So I have arbitrarily fiddled with multiple
traffic types and then tossed the rest into a subset of fq_codel
queues. (I really am a big fan of better mixing, particularly with tcp
I have not however figured out how to classify via a u32 match and end
up with a hash, divisor, and baseclass offset, (it seems to make sense
to have a bunch of queues for gaming/dns/interactive traffic).
My observation is that a LOT of traffic is seemingly marked CS1 (or
remarked as such, particularly on ingress from the internet), so that
if you wanted to pound torrent flat and torrent only, deeper packet
inspection might be required, and CS1 marked traffic could use a
couple of queues dedicated to it....
nor have I benchmarked this attempt....
> Mikael Abrahamsson email: swmike at swm.pp.se
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Cerowrt-devel