All of lore.kernel.org
 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 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.