* RE: [LARTC] limiting doesn't work
2004-07-10 21:02 [LARTC] limiting doesn't work Stephan M. Ott
2004-07-11 0:49 ` gypsy
@ 2004-07-11 1:46 ` Andrew Athan
2004-07-11 5:57 ` AW: " Stephan M. Ott
2 siblings, 0 replies; 4+ messages in thread
From: Andrew Athan @ 2004-07-11 1:46 UTC (permalink / raw)
To: lartc
I also sent this to Stephan, hopefully I'm not too far offbase :-)
A.
------------
1) It's sfq not sqf, you should be getting errors when your two lines are
not commented out
2) Your statement that commenting these lines out "so that rate is always
limited" makes no sense. Adding the sfq's does not affect whether or not
rate is limited, it only changes how packets belonging to the classes to
which the sfq's are attached are ordered/scheduled.
3) Why use cbq at all? htb gives more reliable results and is easier to
correctly configure.
4) You cannot shape downlink packets the way you are trying to do it. You
must use an IMQ device, and to do that you probably have to patch your
kernel and/or iptables/tc (google IMQ).
Regarding why you gor 2Mbit: Perhaps your filters simply did not hit. Were
you sending to/from .51? What did tc show tell you about the number of
packets assigned to each class?
Regarding downlink shaping: The word "shaping" vs "policing" or "limiting"
implies that you are going to queue up out-of-rate packets so that you can
resend them a bit later in order to "flatten out" the usage. Policing and
limiting imply that anything out-of-rate just gets dropped/clipped.
When you are talking about downlink packets, remember that you are at the
far end of a link through which the packets have already been sent. What's
the point of queueing them in order to "shape" the arrival profile, unless
you are going to forward them further to another box??? If they are meant
for this box, then they've already "used" the link. They've already
"arrived" at their destination. No point in "shaping" them. On the other
hand, if you are going to send them further (forward/route/bridge) then you
are really shaping the OUTBOUND traffic on the given ethernet port, not the
inbound traffic on the inbound port.
That's why shaping is only relevant "on the way out". If what you want to
do is forcibly limit downlink speed, it is more appropriate to call that
"policing"--i.e., dropping packets on the floor which fall outside your rate
parameters. Now think about this: If you just drop those packets, which
have already "used" the link, will you benefit down the road?
First, it should be obvious that ignoring incoming packets makes no sense
unless you are trying to limit to some rate below the actual link speed
rate. But secondly, you should also be thinking "hmm, the packet already
used the link, if I ignore it what's the point?"
Well, it turns out that if you ignore TCP packets, the TCP implementation on
the sender should back-off and transmit more slowly--it will "train" to your
policed speed. However, if you drop UDP packets, UDP has no such concept.
Who knows what the application sending UDP will do. Most likely it will
just keep sending at the same rate. Worse, it might try to resend them. So
you're just making your life worse. When limiting downstream, drop only TCP
packets. Look around, and you'll find sample scripts that use IMQ etc. and
set up downstream rate limiting that keep ACK/SYN-ACK/etc. packets flowing.
A.
-----Original Message-----
From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]On
Behalf Of Stephan M. Ott
Sent: Saturday, July 10, 2004 5:03 PM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] limiting doesn't work
Hi folks,
I read the fantastic LARTC How-to and after that i tried to limit one
host in my LAN for both down-and upload bandwidth usage.
I took section 15.9. and added uplink-limiting as I understood it from
the previous chapters.
Unfortunately it doesn't work.
I ran the script and went to the specified PC, started a download, and
watched the rate. The rate was always about 2000 kbit/s, though I
defined (well, at least I thought so) 768 kbit/s as maximum rate.
Can anyone please look at the script and tell me, what must be corrected
in order for it to work ?
Thanks in advance.
This is the script:
#!/bin/bash
LIMITDOWNv8
LIMITUP–
DEV=ppp0
# clean up qdiscs
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
# limit up- and downlink for benni
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 2mbit
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${LIMITDOWN}kbit
allot 1500 prio 5 bounded isolated
tc class add dev $DEV parent 1: classid 1:2 cbq rate ${LIMITUP}kbit
allot 1500 prio 5 avpkt 1000
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst
192.168.0.51 flowid 1:1
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip src
192.168.0.51 flowid 1:2
#tc qdisc add dev $DEV parent 1:1 sqf perturb 10
#tc qdisc add dev $DEV parent 1:2 sqf perturb 10
I commented out the last 2 lines for testing so that the rate is always
limited.
Any ideas ?
Thanks.
Stephan
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread* AW: [LARTC] limiting doesn't work
2004-07-10 21:02 [LARTC] limiting doesn't work Stephan M. Ott
2004-07-11 0:49 ` gypsy
2004-07-11 1:46 ` Andrew Athan
@ 2004-07-11 5:57 ` Stephan M. Ott
2 siblings, 0 replies; 4+ messages in thread
From: Stephan M. Ott @ 2004-07-11 5:57 UTC (permalink / raw)
To: lartc
Hi Andrew (and hi to all others on the list).
###
1) It's sfq not sqf, you should be getting errors when your two lines
are
not commented out
Of course you're right. I did not uncomment them by now. But thanks for
the hint anyway. Saves me a little time when I activate it.
###
2) Your statement that commenting these lines out "so that rate is
always
limited" makes no sense. Adding the sfq's does not affect whether or
not
rate is limited, it only changes how packets belonging to the classes to
which the sfq's are attached are ordered/scheduled.
Hmm, as far as I understood it, these lines allow the limited host to
take unused bandwidth even if over the limit. Did I get this wrong ?
###
3) Why use cbq at all? htb gives more reliable results and is easier to
correctly configure.
Well, would take too long to explain it completely. To be short, I have
no other choice as cbq. I cannot use htb unfortunately.
###
4) You cannot shape downlink packets the way you are trying to do it.
You
must use an IMQ device, and to do that you probably have to patch your
kernel and/or iptables/tc (google IMQ).
Hmm, sounds logical. I just started with all this and when I saw this
short piece of script in the How-to I thought "well, give it a try.
Maybe this will do the trick".
In the How-to one can read:
---
15.9. Rate limiting a single host or netmask
Although this is described in stupendous details elsewhere and in our
manpages, this question gets asked a lot and happily there is a simple
answer that does not need full comprehension of traffic control.
This three line script does the trick:
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth
10mbit
tc class add dev $DEV parent 1: classid 1:1 cbq rate 512kbit \
allot 1500 prio 5 bounded isolated
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
match ip dst 195.96.96.97 flowid 1:1
---
Did I miss something ?
###
Regarding why you gor 2Mbit: Perhaps your filters simply did not hit.
Were
you sending to/from .51? What did tc show tell you about the number of
packets assigned to each class?
Now it starts getting myterious for me.
My complete downlink bandwidth is 2mbit, that's why I defined it. (I
have
ADSL-connection which is called "DSL 2000" here in germany.)
Yes, I was sending from and to client .51. I physically went to this
computer *g* and checked everything from there. So my tests really took
place at .51.
But the filters really didn't hit...
Here's what tc show tells me:
linux-gw:~ # tc -s class show dev ppp0
class cbq 1: root rate 2Mbit (bounded,isolated) prio no-transmit
Sent 706511167 bytes 1396938 pkts (dropped 117, overlimits 0)
borrowed 0 overactions 0 avgidle 3027 undertime 0
class cbq 1:1 parent 1: rate 768Kbit (bounded,isolated) prio 5
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 0 undertime 0
class cbq 1:2 parent 1: rate 96Kbit prio 5
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 0 undertime 0
What did I do wrong ? As far as I understand it, I should have specified
the client .51 correctly. But why is no single packet hitting the
filters ?
###
Regarding downlink shaping: The word "shaping" vs "policing" or
"limiting"
implies that you are going to queue up out-of-rate packets so that you
can
resend them a bit later in order to "flatten out" the usage. Policing
and
limiting imply that anything out-of-rate just gets dropped/clipped.
When you are talking about downlink packets, remember that you are at
the
far end of a link through which the packets have already been sent.
What's
the point of queueing them in order to "shape" the arrival profile,
unless
you are going to forward them further to another box??? If they are
meant
for this box, then they've already "used" the link. They've already
"arrived" at their destination. No point in "shaping" them. On the
other
hand, if you are going to send them further (forward/route/bridge) then
you
are really shaping the OUTBOUND traffic on the given ethernet port, not
the
inbound traffic on the inbound port.
That's why shaping is only relevant "on the way out". If what you want
to
do is forcibly limit downlink speed, it is more appropriate to call that
"policing"--i.e., dropping packets on the floor which fall outside your
rate
parameters. Now think about this: If you just drop those packets,
which
have already "used" the link, will you benefit down the road?
First, it should be obvious that ignoring incoming packets makes no
sense
unless you are trying to limit to some rate below the actual link speed
rate. But secondly, you should also be thinking "hmm, the packet
already
used the link, if I ignore it what's the point?"
Well, it turns out that if you ignore TCP packets, the TCP
implementation on
the sender should back-off and transmit more slowly--it will "train" to
your
policed speed. However, if you drop UDP packets, UDP has no such
concept.
Who knows what the application sending UDP will do. Most likely it will
just keep sending at the same rate. Worse, it might try to resend them.
So
you're just making your life worse. When limiting downstream, drop only
TCP
packets. Look around, and you'll find sample scripts that use IMQ etc.
and
set up downstream rate limiting that keep ACK/SYN-ACK/etc. packets
flowing.
Okay, I think I got what you tell me.
Of course I just can limit tcp packets. And that's all I want to do.
Obviously I misunderstood what the How-to wants to say. I read it the
way that these few lines will DO limiting and will drop packets coming
in out of the limit and thereby "train" the netflow.
Can you give me some hint where I should take a look for scripts doing
well ?
On the other hand... limiting upstream also does not work. Tc show tells
that no packet hits the filter. And limiting the upstream should work,
because I catch these packets before they reach the internet.
What goes wrong here ?
As you can see, I'm a newbie to all of this. I'm interested in improving
the network and LARTC sounds great. But it seems as if I get wrecked
even at the start :-(
Thanks in advance for your assistance.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread