From: "Sebastian 'spax' Pape" <pape@rbg.informatik.tu-darmstadt.de>
To: lartc@vger.kernel.org
Subject: [LARTC] Some problems with limiting downstream
Date: Wed, 13 Jun 2001 00:33:35 +0000 [thread overview]
Message-ID: <marc-lartc-99239793606978@msgid-missing> (raw)
hi!
I'm trying to control down- and upstream with a 2.4.3 kernel, iptables
and tc. I managed to limit the upstream and it works perfect, but
somehow my downstream traffic seems not to be affected from traffic
controlling. I'm not sure if I missunderstood something or perhaps
only mixed up some parameters - I tried several configurations, but
it's always the same: the traffic is filtered to the correct class,
but there's no limitation. The "strongest" connection can always
allocate allmost all downstream traffic.
So here's the setup - perhaps someone can give me a hint?
# DDEV="dev eth0"
# DBAND="bandwidth 768Kbit"
# DOPT="maxburst 20 avpkt 1000"
eth0 is the device to the lan, the average pakte size should be
arround 1000 (I got this from some netfilter byte counters) - but I'm
not sure about maxburst - I just took ist from the HOWTO - what's that
for?
# $TC qdisc add $DDEV root handle 1: cbq bandwidth 100Mbit avpkt 1000
mpu 64
# $TC class add $DDEV parent 1:0 classid 1:1 cbq bandwidth
100Mbit rate 100Mbit allot 1492 weight 10Mbit prio 8 $DOPT
# $TC class add $DDEV parent 1:1 classid 1:2 cbq bandwidth
100Mbit rate 768Kbit allot 1492 weight 77Kbit prio 6 $DOPT bounded
# $TC class add $DDEV parent 1:2 classid 1:3 cbq $DBAND rate
688Kbit allot 1492 weight 70Kbit prio 1 $DOPT
# $TC class add $DDEV parent 1:3 classid 1:100 cbq $DBAND rate
384Kbit allot 1492 weight 38Kbit prio 4 $DOPT
# $TC class add $DDEV parent 1:3 classid 1:200 cbq $DBAND rate
120Kbit allot 1492 weight 12Kbit prio 2 $DOPT
# $TC class add $DDEV parent 1:3 classid 1:300 cbq $DBAND rate
120Kbit allot 1492 weight 12Kbit prio 3 $DOPT
# $TC class add $DDEV parent 1:3 classid 1:400 cbq $DBAND rate
64Kbit allot 1492 weight 12Kbit prio 5 $DOPT
# $TC qdisc add $DDEV parent 1:100 prio
# the same with [1:200, 1:300 and 1:400]
Now `tc -s qdisc` shows that no pakets have been dropped, there's no
overlimit, but for example the 1:300-class got 60M while 1:200 and
1:100 only got 10M traffic per class.
My first thought was, that if I use the full bandwidth there won't be
anything to limit, because the classes are always borrowing bandwidth
to and from each other - so I changed the rate of class 1:3 to 688Kbit
to have 80Kbit "to share" but that also had no effect.
Now I've no more ideas what to change - any ideas?
thanks a lot for your time :)
Sebastian
--
Sebastian 'spax' Pape | Your mouse has moved. Windows NT must be
mailto: sebastian@p-a-p-e.de | restarted for the change to take effect.
pgp: http://p-a-p-e.de/pgp.asc | Reboot now? [ OK ]
--- Do you want to know more? http://www.p-a-p-e.de/ ---
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
reply other threads:[~2001-06-13 0:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=marc-lartc-99239793606978@msgid-missing \
--to=pape@rbg.informatik.tu-darmstadt.de \
--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