Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox