LinuxQuestions.org - bandwidth throttling??

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - bandwidth throttling?? (https://www.linuxquestions.org/questions/linux-networking-3/bandwidth-throttling-484185/)

bandwidth throttling??

I cannot find a working way to throttle my bandwidth in linux. In windoze I use NetLimiter Pro and it works like a charm. The problem is, the software I use to download stuff (lots o stuff ;)) will just download at a steady 5 Mb/s maxing out my entire connection. I want to set it at 300k/s (2.5 Mb/s).

So far I have tried cbq.init. It's complicated as heck, and doesnt work for me as far as I can tell. Even after I recompiled my kernel with all the packet queing stuff it still doesnt work.

Is there a way to do this with netfilter/iptables?

It's the INCOMING bandwidth I want to limit, not the outgoing. And my PC does not route packets, its just a standalone FC5 box.

Check "tc" to see if it's what you need.

Quote:

Originally Posted by nuxrl

Check "tc" to see if it's what you need.

Too effing complicated. I just want to limit incoming bandwidth to 300k/s, not setup all sorts of packet classes, QoS, etc, etc, etc...

yeah, im so l33t i solved my own problem:

Code:

#!/bin/bash 



#in Kbits/sec

DONLOADLIMIT=4000

DEV=eth0



if [ "$1" = "status" ]

then

        tc -s qdisc ls dev $DEV

        tc -s class ls dev $DEV

        exit

fi



if [ "$1" = "stop" ]

then

        tc qdisc del dev $DEV root    2> /dev/null > /dev/null

        tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

        exit

fi



# clean existing filter

tc qdisc del dev $DEV root    2> /dev/null > /dev/null

tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null



########## downlink #############

# attach ingress policer:



tc qdisc add dev $DEV handle ffff: ingress



# filter *everything* to it (0.0.0.0/0), drop everything that's

# coming in too fast:



tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \

  0.0.0.0/0 match ip sport 0x0077 0xffff  police rate ${DONLOADLIMIT}kbit burst 10k drop flowid :1

(remove the 'match ip sport 0x0077 0xffff' to limit all traffic, instead of just port 119.)

Damn, the script i posted works, but it basically just drops the incoming packets until the rate is correct. Is there a better way to throttle INCOMING data (without dropping tons of packets) ?

Although this method does drop packets they're only in respect of your download - if you set your limit to 50% of your maximum download bandwidth the unused bit will get used by other people. However, although I had limited success with this sort of stuff the problem is that you need to set the limit bandwidth below the available bandwidth of your download supplier. As that can vary according to the number of users downloading, time of day etc. you either need to set the limit very small or be prepared to adjust it. I have a similar script to yours which I call passing a max bandwidth parameter.

I must say that in the end I couldn't be bothered as the aggro from other users when they got lag and trying to download 5 CD's of the latest SuSE linux at 100K (rather than 6M) was too painful. I therefore pinch all the bandwidth overnight when I need to do a big download!

my download supplier is giganews, and believe me, they can send the data waaaaaaaay faster than you can recieve it. They easily max out my 10Mbps link (about 1200-1300 kBps). I wanted to limit that down to about 350kBps.

I would assume that if I start dropping packets [which is what the ingress policer does], then giganews would throttle down their sending rate until it eventually levels off at 350kBps, but they dont seem to. The rate at which packets are dropped remains constant (and I expected the rate of packet droppage to decrease).

My question is, if giganews is sending me data as fast as possible, and my compter is just dropping packets until the receive rate is 350kBps, isnt that HIGHLY inefficient?

Is there a better way to limit incoming bandwidth??????

???????????????????????????????????

Although it does seem very inefficient if it lets you do multiple downloads without affecting other internet activity and games then it's better than nothing at all. I'll have another go using it myself to see how effective it really is.

Here's a useful link:

http://www.tldp.org/HOWTO/ADSL-Bandw...agement-HOWTO/

yeah, they said what i said:

Quote:

3.5.1. Why Inbound Traffic Limiting isn't all That Good

We want to limit our inbound traffic to avoid filling up the queue at the ISP, which can sometimes buffer as much as 5 seconds worth of data. The problem is that currently the only way to limit inbound TCP traffic is to drop perfectly good packets. These packets have already taking up some share of bandwidth on the ADSL modem only to be dropped by the Linux box in an effort to slow down future packets. These dropped packets will eventually be retransmitted consuming more bandwidth. When we limit traffic, we are limiting the rate of packets which we will accept into our network. Since the actual inbound data rate is somewhere above this because of the packets we drop, we'll actually have to limit our downstream to much lower than the actual rate of the ADSL modem in order to assure low latency. In practice I had to limit my 1.5mbit/s downstream ADSL to 700kbit/sec in order to keep the latency acceptable with 5 concurrent downloads. The more TCP sessions you have, the more bandwidth you'll waste with dropped packets, and the lower you'll have to set your limit rate.

A much better way to control inbound TCP traffic would be TCP window manipulation, but as of this writing there exists no (free) implementation of it for Linux (that I know of...).

however, my script does do a good job, and allows other users to download just fine while i'm downloading too.

Well tried it again using half available bandwidth as maximum download bandwidth. Appeared to work for a while but then hit same issue with latency increasing to the point that even web browsing stopped working until I paused the download, so need to look further to see what's causing that. Working on self-adjusting script that monitors latency and adjusts download limit dynamically.

The script I posted works flawlessly. I can set it at anything from 50kbps all the way up to 90% of my bandwidth: 4500kbps, and it works perfectly. Of course, my script only throttles incoming data from port 119, because I do all my downloading from usenet.