[LARTC] Lowering priority & increasing drop likelyhood of UDP data

[Justin Todd]

Hello. I have a wireless system (link bandwidth = 700 kbit/s) that 
transmits realtime udp video data and other various tcp protocols.


I don't care if I lose the occassional udp packet but i'd like all of 
the tcp traffic to get through.


I'm thinking that a Generalized RED will give me the best results:
2 queues, one for TCP (very low probability of dropping) and one for UDP 
(high probability of dropping).


How would I configure TCC/TC to do this?

Regards,

Justin
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] htb root don't reach ceil rate?

[Markus Schulz]

Hello,

i have a htb setup where the root and (nearly) all child classes has a 
ceil rate with max up from my adsl line. But the root class don't reach 
the ceil value but some childs are get a huge backlog.

My setup: (tc -d class show dev ppp0) [cleaned a bit]

class htb 1:1 root rate 576000bit ceil 576000bit burst 30Kb/8 cburst 
1739b/8 overhead 14b level 7
class htb 1:10 parent 1:1 leaf 100: prio 0 quantum 7500 rate 58000bit 
ceil 115000bit burst 1480b/8 cburst 1508b/8 overhead 14b level 0
class htb 1:20 parent 1:1 leaf 200: prio 1 quantum 256 rate 282000bit 
ceil 576000bit burst 396b/2 cburst 543b/2 overhead 14b level 0
class htb 1:30 parent 1:1 leaf 300: prio 2 quantum 9000 rate 117000bit 
ceil 576000bit burst 1509b/8 cburst 1739b/8 overhead 14b level 0
class htb 1:40 parent 1:1 leaf 400: prio 3 quantum 9000 rate 58000bit 
ceil 576000bit burst 1480b/8 cburst 1739b/8 overhead 14b level 0
class htb 1:50 parent 1:1 leaf 500: prio 7 quantum 2000 rate 2bit 
ceil 576000bit burst 1461b/8 cburst 1739b/8 overhead 14b level 0
class htb 1:60 parent 1:1 leaf 600: prio 7 quantum 3000 rate 23000bit 
ceil 576000bit burst 1462b/8 cburst 1739b/8 overhead 14b level 0
class htb 1:70 parent 1:1 leaf 700: prio 7 quantum 1000 rate 14000bit 
ceil 576000bit burst 1458b/8 cburst 1739b/8 overhead 14b level 0


Now the classes 1:50 - 1:70 are often get much backlog, but the 
root-class 1:1 don't reach the ceil rate. 
statistic looks like:

tc -s -d class show dev ppp0
class htb 1:1 root rate 576000bit ceil 576000bit burst 30Kb/8 mpu 0b 
overhead 0b cburst 1739b/8 mpu 0b overhead 14b level 7
 Sent 1485575598 bytes 3140554 pkts (dropped 0, overlimits 0)
 rate 480008bit 115pps
 lended: 1904616 borrowed: 0 giants: 0
 tokens: 385702 ctokens: -26458

class htb 1:10 parent 1:1 leaf 100: prio 0 quantum 7500 rate 58000bit 
ceil 115000bit burst 1480b/8 mpu 0b overhead 0b cburst 1508b/8 mpu 0b 
overhead 14b level 0
 Sent 1186471 bytes 15097 pkts (dropped 0, overlimits 0)
 rate 152bit
 lended: 15097 borrowed: 0 giants: 0
 tokens: 194207 ctokens: 99943

class htb 1:20 parent 1:1 leaf 200: prio 1 quantum 256 rate 282000bit 
ceil 576000bit burst 396b/2 mpu 0b overhead 0b cburst 543b/2 mpu 0b 
overhead 14b level 0
 Sent 39131574 bytes 884694 pkts (dropped 0, overlimits 0)
 rate 13296bit 39pps
 lended: 884643 borrowed: 51 giants: 0
 tokens: 8453 ctokens: 6229

class htb 1:30 parent 1:1 leaf 300: prio 2 quantum 9000 rate 117000bit 
ceil 576000bit burst 1509b/8 mpu 0b overhead 0b cburst 1739b/8 mpu 0b 
overhead 14b level 0
 Sent 1027775 bytes 5392 pkts (dropped 0, overlimits 0)
 rate 112bit
 lended: 5332 borrowed: 60 giants: 0
 tokens: 61194 ctokens: 15701

class htb 1:40 parent 1:1 leaf 400: prio 3 quantum 9000 rate 58000bit 
ceil 576000bit burst 1480b/8 mpu 0b overhead 0b cburst 1739b/8 mpu 0b 
overhead 14b level 0
 Sent 370952 bytes 750 pkts (dropped 0, overlimits 0)
 lended: 617 borrowed: 133 giants: 0
 tokens: 172179 ctokens: 21731

class htb 1:50 parent 1:1 leaf 500: prio 7 quantum 2000 rate 2bit 
ceil 576000bit burst 1461b/8 mpu 0b overhead 0b cburst 1739b/8 mpu 0b 
overhead 14b level 0
 Sent 249243996 bytes 608136 pkts (dropped 0, overlimits 0)
 rate 88512bit 22pps
 lended: 133117 borrowed: 475019 giants: 0
 tokens: -439382 ctokens: 5148

class htb 1:60 parent 1:1 leaf 600: prio 7 quantum 3000 rate 23000bit 
ceil 576000bit burst 1462b/8 mpu 0b overhead 0b cburst 1739b/8 mpu 0b 
overhead 14b level 0
 Sent 831028684 bytes 1288890 pkts (dropped 62, overlimits 0)
 rate 278224bit 42pps backlog 38p
 lended: 154838 borrowed: 1134014 giants: 0
 tokens: -65884 ctokens: -21987

class htb 1:70 parent 1:1 leaf 700: prio 7 quantum 1000 rate 14000bit 
ceil 576000bit burst 1458b/8 mpu 0b overhead 0b cburst 1739b/8 mpu 0b 
overhead 14b level 0
 Sent 363652940 bytes 337633 pkts (dropped 0, overlimits 0)
 rate 100144bit 11pps
 lended: 42294 borrowed: 295339 giants: 0
 tokens: -421519 ctokens: 2886


Why the ceil rate can't be reached? 
rate 480008bit from 576000bit a little bit to huge difference. And 
besides this i'm using the overhead patch from Jesper Dangaard Brouer 
(iproute+htb) which takes the ATM+AAL5+SSCS Overhead into account.
Can a slightly inaccurate clock has something todo with this?

Another question: why "tc show class" prints the overhead and mpu value 
twice? And why is the first overhead value = 0? 

-- 
Markus Schulz
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] filter fw and ingress qdisc

[Markus Schulz]

Hello, 
i've found this page (lartc currently down)
http://www.lartc.org/howto/lartc.cookbook.synflood-protect.html 
where someone used iptables firewall mark to mark specific packets which 
will be shaped thru ingress qdisc with a fw filter and rate policy 
appended.

I've tried similar this way, but it don't work. Now i'm belief this 
could'nt work cause the traffic is marked with iptables after it has 
passed the ingress qdisc? Correct?

I've tried this two ways:


$TC qdisc add dev $DEV handle : ingress
$TC filter add dev $DEV parent : protocol ip prio 50 handle 7 fw \   
   police rate ${DOWNSTREAM}kbit burst 10k mtu $MTU drop flowid :1

This don't work. shapes nothing.


$TC qdisc add dev $DEV handle : ingress
$TC filter add dev $DEV parent : protocol ip prio 50 u32 match ip \
   src 0.0.0.0/0 police rate ${DOWNSTREAM}kbit burst 10k drop flowid :1


This works fine, shapes all traffic down to $DOWNSTREAM limit.

-- 
Markus Schulz

> >Is that verb regular?  Does "ich kann den Mond sprengen" sound less
> >awkward than "ich kann den Mond explodieren" ?
> The first sentence is correct, the second one is just nonsense. But 
> you will need quite a big amount of explosives to do so.
I'm sure America has plenty.  :)
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Conceptual question ;-)

[Georgi Alexandrov]

Jody Shumaker wrote:
> I don't believe -j CLASSIFY targte can target sub-classes.  Pretty
> sure you can only target classes whose parent is the root class of the
> qdisc. You would need to use tc filters to do this, or get rid of your
> redundant classes.  For THB for some reason you have a root class and
> a child class with the same limit? This makes no sense, you'd be fine
> with just the 2:2 class and attaching the sfq to that, and setting the
> classify to that.
> 
> Otherwise, yes I think this would work in setting a limit on those ppp
> devices as they come up to XXXkbit of bandwidth.
> 
> - Jody

Actually it looks like it can target sub-classes:

pppoe users - eth1-gw/router-eth0 - WAN/Internet

For shaping pppoe users upload i do the following:
attached a root qdisc to eth0
then attached a htb class to it (1:10 for example)

Then i attach dynamicaly classes to 1:10 with numbers (1:91 for ppp1 for
example) with parent 1:10. There are also dynamic iptables rules (alot
of dynamic stuff going on .. lol ;) saying "traffic from that pppoe user
going out trough eth0 CLASSIFY as 1:91"
When a ppp43 is up, a class 1:943 with parent 1:10 will be attached to
eth0 and iptables rule saying traffic from that pppoe user going out
trough eth0 CLASSIFY as 1:943"

and it seems to work fine, upload seems to be shaped at the desired rates.
But that is in a "one pppoe user" test environment, i think it should
work fine when deployed too, and each pppoe user will get their upload
rates ;-)


-- 
regards,
Georgi Alexandrov

Key Server = http://pgp.mit.edu/ :: KeyID = 37B4B3EE
Key Fingerprint = E429 BF93 FA67 44E9 B7D4  F89E F990 01C1 37B4 B3EE



signature.asc
Description: OpenPGP digital signature
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc