From: Vadtec <vadtec@vadtec.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Question about how TC enforces bandwidth limiting
Date: Thu, 06 Sep 2007 01:13:48 +0000 [thread overview]
Message-ID: <46DF544C.6070501@vadtec.net> (raw)
In-Reply-To: <46D758ED.2030705@vadtec.net>
After another two days of trying to get this to work like I think it
should, I've still hit a brick wall.
As I am at a total loss as to what's going on, I am providing my shell
script that I use to setup my
tc rules.
You will notice a big section that is commented out. Those are rules I
have been using that (for
all intents and purposes) for like I expect.
I adapted my section based on the example I found at
http://lartc.org/howto/lartc.cookbook.ultimate-tc.html section 15.8.3
#!/bin/sh
IFext='eth0'
IFint='eth1'
rc_done=" done"
rc_failed=" failed"
MAX_RATE='360kbit'
MAX_RATEA='360'
INGRESS_RATE='1400kbit'
return=$rc_done
TC='/sbin/tc'
tc_reset ()
{
# Reset everything to a known state (cleared)
$TC qdisc del dev $IFext root 2> /dev/null > /dev/null
}
tc_status ()
{
echo "[qdisc - $IFext]"
$TC -s qdisc show dev $IFext
echo "------------------------"
echo
echo "[class - $IFext]"
$TC -s class show dev $IFext
}
tc_showfilter ()
{
echo "[filter - $IFext]"
$TC -s filter show dev $IFext
}
case "$1" in
start)
echo -n "Starting traffic shaping"
tc_reset
# U320="$TC filter add dev $IFext protocol ip parent 1:0 prio 0 u32"
$TC qdisc del dev eth0 root
$TC qdisc del dev eth0 ingress
# uplink
# dev eth0
$TC qdisc add dev $IFext root handle 1: htb default 20
$TC class add dev $IFext parent 1: classid 1:1 htb rate $MAX_RATE
burst 6k
$TC class add dev $IFext parent 1:1 classid 1:10 htb rate 240kbit
ceil $MAX_RATE burst 6k prio 1
$TC class add dev $IFext parent 1:1 classid 1:20 htb rate 200kbit
ceil $[9*$MAX_RATEA/10]kbit burst 6k prio 2
$TC qdisc add dev $IFext parent 1:10 handle 10: sfq perturb 5
$TC qdisc add dev $IFext parent 1:20 handle 20: sfq perturb 5
$TC filter add dev $IFext parent 1:0 protocol ip prio 10 u32 match
ip tos 0x10 0xff flowid 1:10
$TC filter add dev $IFext parent 1:0 protocol ip u32 match ip
protocol 1 0xff flowid 1:10
$TC filter add dev $IFext parent 1: protocol ip prio 10 u32 match ip
protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2
match u8 0x10 0xff at 3 flowid 1:10
# downlink
# dev eth0
tc qdisc add dev $IFext handle ffff: ingress
$TC filter add dev $IFext parent ffff: protocol ip prio 50 u32 match
ip src 0.0.0.0/0 police rate $INGRESS_RATE burst 10k drop flowid :1
#
# dev eth0 - creating qdiscs & classes
#
#$TC qdisc add dev $IFext root handle 1: htb default 90
#$TC class add dev $IFext parent 1: classid 1:1 htb rate $MAX_RATE
#$TC class add dev $IFext parent 1:1 classid 1:10 htb rate 240kbit
ceil $MAX_RATE prio 0
#$TC class add dev $IFext parent 1:1 classid 1:20 htb rate 192kbit
ceil $MAX_RATE prio 1
#$TC class add dev $IFext parent 1:1 classid 1:30 htb rate 80kbit
ceil $MAX_RATE prio 2
#$TC class add dev $IFext parent 1:1 classid 1:40 htb rate 64kbit
ceil $MAX_RATE prio 3
#$TC class add dev $IFext parent 1:1 classid 1:50 htb rate 32kbit
ceil $MAX_RATE prio 4
#$TC class add dev $IFext parent 1:1 classid 1:60 htb rate 20kbit
ceil $MAX_RATE prio 5
#$TC class add dev $IFext parent 1:1 classid 1:70 htb rate 16kbit
ceil $MAX_RATE prio 6
#$TC class add dev $IFext parent 1:1 classid 1:80 htb rate 8kbit
ceil $MAX_RATE prio 7
#$TC class add dev $IFext parent 1:1 classid 1:90 htb rate 2kbit
ceil $MAX_RATE prio 8
#$TC class add dev $IFext parent 1:1 classid 1:100 htb rate 2kbit
ceil 20kbit prio 9
#$TC qdisc add dev $IFext parent 1:10 handle 10: sfq perturb 10
#$TC qdisc add dev $IFext parent 1:20 handle 20: sfq perturb 10
#$TC qdisc add dev $IFext parent 1:30 handle 30: sfq perturb 10
#$TC qdisc add dev $IFext parent 1:40 handle 40: sfq perturb 10
#$TC qdisc add dev $IFext parent 1:50 handle 50: sfq perturb 10
#$TC qdisc add dev $IFext parent 1:60 handle 60: sfq perturb 10
#$TC qdisc add dev $IFext parent 1:70 handle 70: sfq perturb 10
#$TC qdisc add dev $IFext parent 1:80 handle 80: sfq perturb 10
#$TC qdisc add dev $IFext parent 1:90 handle 90: sfq perturb 10
#$TC qdisc add dev $IFext parent 1:100 handle 100: sfq perturb 10
tc_status
;;
stop)
echo -n "Stopping traffic shaper"
tc_reset || return=$rc_failed
echo -e "$return"
;;
restart|reload)
$0 stop
$0 start || return=$rc_failed
;;
stats|status)
tc_status
;;
filter)
tc_showfilter
;;
*)
echo "Usage: $0 {start|stop|restart|stats|filter}"
exit 1
esac
test "$return" = "$rc_done" || exit 1
Regardless of the values I use for any of the rates, I still have the
same problem. I do not classify ANY traffic with iptables for this set
of tc filters, so any traffic that is generated is solely shaped by tc
in this case.
The problem I have is this, whenever I allow any torrent client to use
above 20k of outgoing bandwidth, *everything* becomes laggy for some
reason. Most notable is SSH. While I have no accurate way to time the
lag, as near as I can tell it lags about 2 seconds. When I press a key
on my keyboard it takes ~2 seconds to show up in the SSH client. Or, if
I enter lets say "ls" and press enter, it takes roughly 2 seconds for
the ls output to reach me, and while its being displayed, its choppy
appearing (as in it comes in chunks rather than a nice stream).
I see absolutely no reason for this to be happening. Why should anything
lag when I'm using more outgoing bandwidth? Why would more outgoing
bandwidth cause a slow down on incoming bandwidth. Or, why would more
outgoing bandwidth slow down the filters/tc? I've verified that this
happens on more than just my modem. I've used two different routers and
a cable modem. All suffer from the same symptoms.
For the record, my router PC is built as such:
CentOS 5 64bit
AMD Sempron 2800+ (64bit, 1.6Ghz)
2GB of DDR
2GB of swap
As you can see, this PC is more than capable of acting as my router.
I would greatly appreciate any input as to why this torrent problem
keeps poping up. As near as I can tell, it doesn't happen during FTP
upload or any other sort of intensive upload action.
Thanks,
Vadtec
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2007-09-06 1:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-30 23:55 [LARTC] Question about how TC enforces bandwidth limiting Vadtec
2007-09-03 12:05 ` Vadtec
2007-09-03 18:43 ` Martin A. Brown
2007-09-03 20:15 ` Vadtec
2007-09-04 2:09 ` Martin A. Brown
2007-09-04 12:27 ` Vadtec
2007-09-04 13:02 ` Martin A. Brown
2007-09-04 13:39 ` Vadtec
2007-09-06 1:13 ` Vadtec [this message]
2007-09-06 2:47 ` Martin A. Brown
2007-09-06 3:04 ` Vadtec
2007-09-06 4:08 ` Vadtec
2007-09-06 17:43 ` Vadtec
2007-09-06 17:57 ` David Boreham
2007-09-06 18:43 ` Vadtec
2007-09-06 19:32 ` David Boreham
2007-09-06 20:09 ` Vadtec
2007-09-06 20:09 ` Andy Furniss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46DF544C.6070501@vadtec.net \
--to=vadtec@vadtec.net \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.