From: Andras.Horvath@cern.ch
To: lartc@vger.kernel.org
Subject: [LARTC] borrowing+priority, help req
Date: Thu, 24 Jul 2003 07:19:37 +0000 [thread overview]
Message-ID: <marc-lartc-105903125214535@msgid-missing> (raw)
Hi!
I'm new to this list :) I have a problem (or misunderstanding) trying to
set up the very basic example: giving priority to outgoing traffic from
a host (on 100Mbit Ethernet) towards a subset of nodes based on their IP
address (not on QoS flags), while allowing others to use all 'leftover'
bandwidth.
I have tried with htb and cbq qdiscs as well and neither seems to be
doing what I want. :) Here is my CBQ setup:
tc qdisc add dev eth1 root handle 1:0 cbq bandwidth 100Mbit \
rate 100Mbit avpkt 1000 cell 8
tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate 100Mbit \
weight 1Mbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded
tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth 100Mbit rate 80Mbit \
weight 0.8Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000
tc class add dev eth1 parent 1:1 classid 1:4 cbq bandwidth 100Mbit rate 20Mbit \
weight 0.2Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000
tc qdisc add dev eth1 parent 1:3 handle 30: sfq
tc qdisc add dev eth1 parent 1:4 handle 40: sfq
tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match \
ip dst 10.0.0.0/16 flowid 1:3
tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match \
ip dst 10.1.0.0/16 flowid 1:4
What this simply does for me is that when both IP ranges start
'fighting' for bandwidth they get about 50% each while as I understood
(? :) from the HOWTO they should have got a 8:2 ratio.
If I make one of 1:3 or 1:4 'bounded', the other is able to borrow its
bandwidth, but not the other way around (no surprise).
I tried the prio qdisc too:
tc qdisc add dev eth1 root handle 1: prio
tc qdisc add dev eth1 parent 1:1 handle 10: sfq perturb 10
tc qdisc add dev eth1 parent 1:2 handle 20: sfq perturb 10
tc qdisc add dev eth1 parent 1:3 handle 30: sfq perturb 10
tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match \
ip dst 10.1.0.0/16 flowid 1:3
tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match \
ip dst 10.0.0.0/16 flowid 1:1
which seems to have 'no effect' as well (50% bandwidth goes to both
parties).
The packets indeed make it to the right class/qdisc according to tc -s.
Measurements were taken using iptables counters.
Could you help me (either by pointing out where I don't understand
something or providing a working example)?
Thanks a lot in advance,
Andras
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next reply other threads:[~2003-07-24 7:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-24 7:19 Andras.Horvath [this message]
2003-07-28 17:57 ` [LARTC] borrowing+priority, help req Stef Coene
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-105903125214535@msgid-missing \
--to=andras.horvath@cern.ch \
--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