Re: [LARTC] simple tbf rate clamping issues

[Andy Furniss <lists@andyfurniss.entadsl.com>]

sting wrote:
> Hello,
> 
> I was attempting to throttle egress traffic to a specific rate using a 
> tbf.  As  a starting point I used an example from the LARTC howto, which 
> goes:
> 
> tc qdisc add dev eth1 root tbf rate 220kbit latency 50ms burst 1540

It's not the best example as latency is a way of setting buffer 
length(limit) and 50ms @ 220kbit is < 1500 bytes. If you set < 1514/1518 
explicitly with limit you would not pass bulk packets at all. I guess it 
rounds it up a bit if you use latency.
> 
> I then attempt a large fetch from another machine via wget (~40 megs) 
> and the rate was clamped down to about 12Kbytes/s.  As this seemed too 
> much, I gradually increased the latency up to 200ms which then gave me 
> the expected results (~34Kbytes/s).

I would expect that, tcp doesn't like one packet/short buffers, and it's 
even worse on a lan than a wan as (linux?)tcp behaves differently when 
it detects low latenccy.

> 
> I then applied this queuing discipline on a machine acting as a 
> gateway/router for a few VLANed subnets.  The tbf was applied on 
> interface eth1.615.  From another workstation I attempted a wget, and so 
> the traffic had to go through the gateway/router.  The download rate 
> went from 16 Mbytes/s down to about 1.6 Mbytes/s, but was much much 
> higher than what I'm trying to clamp it down to.

I just tested a tbf on a vlan and it seems OK - if you see 1.6 Mbytes 
and tbf is 220kbit maybe you are shaping in the wrong direction and just 
getting the acks? (OK I am just guessing here)

What does tc -s qdisc ls dev eth1.615 say?

> 
> Two questions:
> 1/ My main question. AFAIK, queuing disciplines affect egress traffic 
> whether that traffic originates from the host or is being forwarded. 
> Assuming that the fact the tbf is mostly meant to be applied to 
> forwarded traffic is not an issue, *is there anything else that could 
> cause the transfer rate not to be correctly clamped down?*  What 
> parameters should I be playing with?

One possible difference, though it's probably not your problem.

If you have a nic that does tcp segmentation offload, then locally 
generated traffic may go through as supersize "packets" which makes htb 
go over rate. I am not sure what tbf would do - maybe just drop them if 
the buffer is not long enough.

> 
> 2/ I'm assuming the first example I quoted must have worked as described 
> when the HOWTO was initially written a few years ago.  In any case, i am 
> assuming with 50ms max latency outgoing packets could not be held long 
> enough in the tbf and had to be droppd, correct?

Yep, also that example was on a ppp wan IIRC.

If you put anything on the root of eth/vlan you need to remember that 
you are going to be catching arp aswell as ip traffic.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc