Re: HTB precision and bursts

[Andy Furniss <andyqos@ukfsn.org>]

Ivan Lezhnjov Jr. wrote:
> Hello,

Hi, apologies for lack of examples - I am rusty with this stuff and 
don't have time to test everything so I am just going to make some 
critical points.

>
> I was wondering if the community would be able to help me understand something about HTB and what to expect of its precision.
>
> The configuration that I work with is a Linux laptop using only one wireless interface to communicate with a typical SOHO Cisco Linksys Router.
> You can see the actual HTB configuration below and what Linux kernel i use. Let me know if you need any other information to better understand my system.

It would be much nicer if you could get open wrt on the router or have 
something in front of it so that it saw all network traffic.

>
> My Internet connection is asymmetric ADSL, 10Mbit/s down and 1Mbit/s up.

If you try hard enough you should be able to use almost 100% upstream of 
ADSL as there are ways to allow for overheads, though you need to know 
exact detail of the way you are connected and sync speed (which may of 
course vary a bit).

>
> The problem.
>
> When egress is saturated fully ingress gets sluggish.
> Really annoying, so I try to cap egress according to what appears to be a common knowledge and best practice.
>
> As it is a 1Mbit/s egress, I attempt to limit outgoing traffic at 75kbps. This is what I figured is a good value that doesn't hinder ingress traffic to the point where it start being sluggish.
> I know that it gets sluggish because I use a torrent client almost always seeding distro ISOs and whatnot, and I just know from experience that when I use torrent client shaping capabilities capping outgoing traffic at 75kbps there's left enough room for comfortable work.
>
> So, I'm particularly interested in why transmission can be very precise, and if I limit outbound traffic in it to 75kbps it never goes above that value. However, if use HTB as shown below and tell transmission to get out of the way in aspect of shaping traffic, I can see that on average it is limited to 75kbps indeed but I can see intermittent bursts up to 150kbps.

Transmission doesn't know what's happening on the wire and since 
150kbyte is impossible for you it must be measuring traffic that is 
getting buffered.

>
> You could say transmission is stupid and is showing wrong numbers in GUI, but having worked with this particular configuration on a daily basis for years literally I can really tell that when I'm using HTB these bursts can and actually do cripple ingress.
>

The problem is your htb setup is not any better than nothing as you are 
just sending everything to a possibly large fifo (as you don't specify 
it will get whatever qlen is on the wlan if).

To maximise downloads/interactivity when upstream is saturated needs you 
to give priority to small udp for dns and small tcp for acks over the 
larger bulk data packets.

This involves filtering and a more complicated htb setup - an easier 
option if you are not trying to go for best possible latency for gaming 
would be to put sfq or fq_codel on the internet class.


> Transmission's internal shaping capabilities proved way more accurate and reliable, so I'd say what it shows in GUI is in fact accurate.
>
> However, limiting egress with the help of transmission isn't cool enough anymore :P Seriously, my home network grows more and more complex with time and there's a real need to use a more advanced shaping solution on this Linux laptop.
>
> So, is there a way to tune HTB to be uncompromisingly precise with no bursts above set value of 75kbps?
> If yes, how would I do it?

IME htb won't go over - I shape on adsl at almost 100%, depending on 
setup/use case it may spit out more than one bulk packet occasionally, 
but it still won't go over.


> and this is how I get it configured via an init script
>
> $tc qdisc del root dev $dev
>
> 	$tc qdisc add dev $dev root handle 1: htb default 10

The problem with default is that arp will go here I prefer to filter 
"the rest" with a "protocol ip" filter and not use default. If you have 
ipv6 etc you need to handle this. direct_packets_stat tells you what has 
gone through without shaping.


> 	$tc class add dev $dev parent 1: classid 1:10 htb rate 75kbps
> 	$tc class add dev $dev parent 1: classid 1:11 htb rate 54mbit

Being single duplex and having many overheads mean this 54mbit is not 
going to do anything - you won't get anything like that.

I have no experience trying to shape wireless.