From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Wed, 22 Aug 2007 23:13:12 +0000 Subject: Re: [LARTC] simple tbf rate clamping issues Message-Id: <46CCC308.10709@andyfurniss.entadsl.com> List-Id: References: <46CBD872.6060307@bloodwolf.org> In-Reply-To: <46CBD872.6060307@bloodwolf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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