All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Hickey <bugfood-ml@fatooh.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] tc does'nt limit the bandwidth!
Date: Tue, 13 Apr 2004 21:26:27 +0000	[thread overview]
Message-ID: <407C5B03.90603@fatooh.org> (raw)
In-Reply-To: <20040413201326.8460.qmail@web20103.mail.yahoo.com>

segun adesina wrote:
> Hi, good people!
> 
> I wanted to limit my 4 customers to 144, 16, 32, and
> 32kbps.
> I used the following tc commands BUT IT FAILED TO
> LIMIT each and everyone of them to its bandwidth.
>  What am I doing wrong:

Do you know that tc uses somewhat unconventional abbreviations? kbps
means kiloBYTEs per second and kbit means kiloBITs per second. That
would really screw up the limiting if you had that mixed up. Read the
"Units" secion of the man page.

> 
> My tc scripts are:
> 
> tc qdisc add dev eth1 root handle 1: htb default 1
>                        #Classes#
> tc class add dev eth1 parent 1:    classid 1:1    htb
> rate     9bps ceil    9bps  #Default
> tc class add dev eth1 parent 1:    classid 1:100  htb
> rate     9bps ceil    9bps  #ICMP
> 
> 
> tc class add dev eth1 parent 1:    classid 1:5    htb
> rate  144kbps ceil 256kbps  #customer A

This class has a higher ceiling than its rate, which means it is allowed
to "borrow" unused bandwidth from the other classes. I don't know if you
intended that.

> tc class add dev eth1 parent 1:    classid 1:101  htb
> rate   16kbps ceil  16kbps  #customer B
> tc class add dev eth1 parent 1:    classid 1:111  htb
> rate   32kbps ceil  32kbps  #customer C
> tc class add dev eth1 parent 1:    classid 1:121  htb
> rate   32kbps ceil  32kbps  #customer D
> 

All these classes are operating on eth1, and should restrict bandwidth
leaving that interface. If you want to restrict traffic moving in the
other direction, you may need a corresponding set of classes.

You haven't shown us any of your tc filter commands. If nothing I've
said above has helped any, then you probably have to give us more
information or we won't be able to find what's wrong.

-Corey
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2004-04-13 21:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-13 20:13 [LARTC] tc does'nt limit the bandwidth! segun adesina
2004-04-13 20:38 ` Jason Boxman
2004-04-13 21:26 ` Corey Hickey [this message]
2004-04-13 22:28 ` Roy
2004-04-14 17:12 ` segun adesina

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=407C5B03.90603@fatooh.org \
    --to=bugfood-ml@fatooh.org \
    --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.