Re: [LARTC] HTB: far unequal behaivor at a slight conf rate change [Solved]
El Friday 24 February 2006 06:36, Andreas Klauer escribió: On Thu, Feb 23, 2006 at 11:42:16PM -0300, Luciano Ruete wrote: with vde_switch daemon listening in a tuntap device. I suppose that htb is device independet, i hope it does not matter. I don't have any experience with vde_switch and tuntap's (I don't even know what those are, so much for ignorance). The only device-dependent factor I came across with HTB so far is the overhead problem - not all devices have the same overhead (PPP over Ethernet or whatever). So HTB calculating the rate incorrectly is a possibility. It can be tuned using overhead/mpu parameters, however in order to do that, you'd need to know correct values first, and they can be a little hard to come by. I also doubt it's the cause of your problem in this case. you're rigth, and will not be the only time in this mail :-) class htb 1:7005 parent 1:7000 leaf 7005: prio 3 quantum 1500 rate 23000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 class htb 1:7004 parent 1:7000 leaf 7004: prio 1 quantum 1500 rate 207000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 class htb 1:7000 root rate 256000bit ceil 256000bit burst 12Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 7 The problem with this tree is that you took out the client class (the one with rate and ceil 23bit). When I said that child classes without siblings don't make sense, I didn't mean to actually take out the child class, but rather take out the parent of this child class; in your example that would mean making the 23bit class the root class. In your setup now, by just looking at the class tree, not the statistics, my guess would be that while each leaf class has a ceil of 23bit, they won't share the same 23kbit, but rather utilize the full 256kbit of their parent. That does not seem to be what you want. It still does not explain the rates in this setup, too. yes, once again you're rigth, but i consider it irrelevant for the test that i was doing. Anyway, as you say, it still does not explain the situation... Especially the rate of the parent class seems low - if this is a testing environment where you are filling out the classes to their maximum, it's really odd that the parent class does not use it's full bandwidth. On the other hand, I don't know how accurate the rate statistics of HTB are. I don't have access to a properly working shaping setup right now to verify wether it's the same on my setup. If it isn't, I'd probably check first how much rate HTB can actually use, because it's a very bad situation for HTB when it thinks it can use more bandwidth than the link actually can guarantee. For the third time you are so rigth, i boot a second virtual machine, and test the same htb setup betwen the two virtual machins and using my gentoo as firewall. Obviously the bandwhidth between them can be considered infinite, and the setup works properly. So i made severals test to the link whit i was testing before and at any moment i get real 256kbit/s. This expains all the situation. Shame on me!!! I've added a FAQ about this to my project after this. When i have a first public release(wich will be son), i will post here(if does not bother) for one time only the project url, and some words of what it does. For now i leave a stable snaphost of my git tree at git-clone http://www.lugmen.org.ar/~luciano/git-repo/htb-gen/.git or simply point a browser to http://www.lugmen.org.ar/~luciano/git-repo/htb-gen/ Many tanks for your help! -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc filter can target only leaf classes?
Andreas Hasenack wrote: (using htb) I'm trying to learn tc filter and it seems the flowid parameter can only point to leaf classes. Actually, it can point anywhere, but it doesn't seem to work unless it points to a leaf class. Is this correct? For example, I have this tree: eth0 | +--1:---+ | | +--1:101:20 | | | 1:301:4020: | | 30: 40: 1: is htb qdisc, with default pointing to minor 20. And this filter: iptables -t mangle -A OUTPUT -d $DSTHOST -j MARK --set-mark 1 tc filter add dev $DEV parent 1:0 prio 1 protocol ip \ handle 1 \ fw \ flowid 1:10 Now, I only see 1:10 getting the traffic if 1:30 and 1:40 don't exist. The moment I add 1:30, 1:40 and their qdiscs, the above filter stops working and this same traffic starts going to 1:20, which is the default set at 1:'s qdisc. Why does the filter stop working? I was expecting it to keep working and then I could further filter this traffic into 1:30 and 1:40 *at* 1:10. You need other filters with parent 1:10 to send to leafs below 1:10 Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] why isn't 1:1 getting the traffic? [filter question]
Andreas Hasenack wrote: With the below script, whenever I ping 10.0.16.10 (which matches the only filter I have), traffic still get's sent to the default 1:2 class instead of 1:1 and I don't know why... Any hints? (kernel 2.6.12, iproute2-2.6.15) tc qdisc del dev eth0 root /dev/null 21 tc qdisc add dev eth0 handle 1: root htb default 2 tc class add dev eth0 classid 1:1 parent 1: htb rate 100kbps ceil 100kbps quantum 1500 tc class add dev eth0 classid 1:2 parent 1: htb rate 90mbit ceil 90mbit quantum 1500 tc qdisc add dev eth0 handle 2: parent 1:2 sfq perturb 10 tc class add dev eth0 classid 1:10 parent 1:1 htb prio 0 rate 30kbps quantum 1500 tc qdisc add dev eth0 handle 10: parent 1:10 sfq perturb 10 tc class add dev eth0 classid 1:11 parent 1:1 htb prio 0 rate 70kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 20: parent 1:11 sfq perturb 10 tc class add dev eth0 classid 1:12 parent 1:1 htb rate 60kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 30: parent 1:12 sfq perturb 10 tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \ match ip dst 10.0.16.10/32 \ flowid 1:1 It's because 1:1 isn't a leaf, you need more filters with parent 1:1 to filter to the leaves. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] userlevel should not need to know about HZ?
Andreas Hasenack wrote: Em Qui 23 Fev 2006 19:47, Andreas Klauer escreveu: So, how do we reliably calculate the minimum value for buffer/burst/maxburts? Trial Error, not that I ever had much luck with TBF though... From my experiments, the minimum seems to be either MTU plus a few bytes or the result of rate/HZ, whichever is higher. Both the buffers need to be at least MTU and if you shape on eth MTU+14. You should set the limit buffer to the length of queue you want - 1*MTU(+14) is pretty useless for a limit but OK for burst. I am not sure about tbf and Hz if it's like htb you need to set burst big enough so its size * HZ can fill the link. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shaping by IP's
Laimis wrote: If in one time 3 IP adresses using internet. TC script: DEV=eth0 # LAN SERVER_IP=192.168.1.2 # eth0 ip address tc qdisc add dev $DEV root handle 1: htb default 255 tc class add dev $DEV parent 1: classid 1:1 htb rate 384Kbit quantum 1500 tc class add dev $DEV parent 1:1 classid 1:20 htb rate 128Kbit ceil 384Kbit prio 0 quantum 1500 tc class add dev $DEV parent 1:1 classid 1:21 htb rate 128Kbit ceil 384Kbit prio 0 quantum 1500 tc class add dev $DEV parent 1:1 classid 1:22 htb rate 128Kbit ceil 384Kbit prio 0 quantum 1500 tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 6 tc qdisc add dev $DEV parent 1:21 handle 21: sfq perturb 6 tc qdisc add dev $DEV parent 1:22 handle 22: sfq perturb 6 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 22 fw flowid 1:22 iptables -t mangle -I POSTROUTING -o $DEV -s ! $SERVER_IP -d 192.168. 1.20 -j MARK --set-mark 20 iptables -t mangle -I POSTROUTING -o $DEV -s ! $SERVER_IP -d 192.168. 1.21 -j MARK --set-mark 21 iptables -t mangle -I POSTROUTING -o $DEV -s ! $SERVER_IP -d 192.168. 1.22 -j MARK --set-mark 22 If we swiched on 2 PC's (192.168.1.20 192.168.1.21) many p2p programs, FTP with many conections, and on 3d PC (192.168.1.22) FTP downloading with one conection. then 3d PC getin less than 128kbit. If i want that all 3 PC's get NOT LESS than 128kbit, what should I do with my script? You need to back off from your line rates. For ingress so you can shape at all and for egress to allow for overheads (you can get patches for dsl overheads). Quantum should be 1514 as you shape on eth and sfq is really meant for bulk traffic. It would be better to mark say small tcp and udp and give them priority with the rest going to sfq. I would also limit the length of the sfqs default of 128 is far too long for shaping at these rates - you want to drop packets especially for ingress. Perturb causes packet reordering so it's best set higher than 6 - I use 20. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shared ADSL SHAPER
Rasmus Melgaard wrote: Hi, I'm trying to make a shaper / firewall to improve sharing of bandwidth on a ADSL (3mbit down / ½ mbit up) Since the ADSL is very asymmetric, down is unimportant, I make a ingress rate limit shaper to ensure, all shaping is at the Shaper, and not on the Router or the ISP. The Idea is then to make one HTB hierarchy and have each client (IP) filtererd and put in a child-HTB queue. This is the main idea, I have added prio to each HTB-child to keep priorities for each client. I currently use a reduced setup with total-uplink limited to 160kbit, and i run first the firewall script (first) and then the Shaper script, below. The problem is know that if a take Azureus, bittorrent client, and let it go (no uplink limitation), it now kills its own downlink speed. If I limit the uplink speed in Azureus the downlink will grow again, it is quiet obvious. I've tried adding some trick from the net, to especially improve ACK performance, but it hasn't helped. I haven't checked the script but assuming it's OK I think that this could be fixed - I use the python client and it seems OK. When you back off you will get fairness from the client - so you should use sfq. You will need to priorotise small packets - I use 128. You also need to limit the length of the sfq to say 20 - 30 so that you get plenty of drops and less acks for the download get piggybacked on the upload packets - bittorrent uses tcp full duplex which makes it a bit of a special case for shaping. Always remember that unless you patch/use overhead parameters that you need to back off from the advertises link rate. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] QOS server droping packets 4% loss
Calin Ilis wrote: Hi all, I have a problem with htb and wonder if anybody has encountered this. On my LAN I have more than 1000 clients, and I am using htb to shape the incoming trafic. The problem is that I am experiencing packet loss (about 4%) in the qos server. The server is droping packets even if my trafic is relatively moderate. I tried everithing estimator, senting the quantum etc etc but it doesn't seem to improve. Do you see the dropped packets counted with tc -s class ls dev eth0 ? Packet loss is normal for shaping tcp. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb root don't reach ceil rate?
Markus Schulz wrote: Am Freitag, 10. Februar 2006 14:45 schrieb Markus Schulz: 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 ok, i've understand now. Differenz comes from gross versus net data rates due to overhead of ATM-SAR and pppoe-overhead. All statistic values are netto values. Yes - you can get patches to do egress overheads for dsl - if you know your exact type and are prepared to rebuild kernel or the modules and tc. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb root don't reach ceil rate?
ok, i've understand now. Differenz comes from gross versus net data rates due to overhead of ATM-SAR and pppoe-overhead. All statistic values are netto values. Yes - you can get patches to do egress overheads for dsl - if you know your exact type and are prepared to rebuild kernel or the modules and tc. Oops didn't see you were already patched - htb counters still see things at ip level. FWIW You still can't really use 576000 - one of my modems would do it's aaal5/0 qos in whole cells so being slightly less, also if you start/restart the shaper on a live link the queue formed may never empty. Running 286kbit on a 288kbit ATM rate line has never gone over for me and slowly drains if the modem buffer is full when started. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] invert u32 match selector
richard lucassen wrote:
On Wed, 22 Feb 2006 11:43:40 +0200
Vaidas [EMAIL PROTECTED] wrote:
With u32 you cannot negate, that's why it is lame...
And why doesn't this work? (I send all port 80 to 1.2.3.4 to class 14
/before/ I send the rest to classid 13):
$TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \
match ip protocol 0x6 0xff \
match ip dport 80 0x \
match ip dst 1.2.3.4/32 \
classid 1:14
$TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \
match ip protocol 0x6 0xff \
match ip dport 80 0x \
classid 1:13
Any ideas?
Looks OK to me - try what Anton suggested to be safe but order is
usually enough.
I guess IFB means this is ingress - if you are doing nat / or the ip you
match is on that machine maybe it not passing ifb with the address you
expect.
Andy.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Multiple providers routing
Greetings Sameer,
: I have a linux router connected to two separate internet
: connection from an ISP. There is a third interface ( ip -
: 192.168.1.1 ) in the router connected to the local network.
: Configured the routing tables and added the rules and everything
: seems to be working fine from the routing box. Traceroute to
: external internet sites reveal that traffic is being routed
: correctly and that the failover mechanism is working.
:
: Now in my internal machines the gateway address is the set to the
: third interface of the router and the internal machines can ping
: the router ( 192.168.1.1 ). The problem is that the internal
: machines cant connect to the net. A quick check with pings and
: tcpdump revealed that the packets from the internal machines are
: arriving at the router and are being routed correctly... but are
: not coming BACK from the router to the internal machines.
:
: Any pointers as to why this is happening would be useful
Quick, experienced guess:
# sysctl net.ipv4.conf.default.rp_filter
If the answer provided is:
net.ipv4.conf.default.rp_filter = 1
Then, you'll need to flip the reverse path filtering toggle [0].
When this sysctl is set to 1, the kernel automatically drops packets
incoming from the wrong interface according to the primary
('main') routing table.
Good luck,
-Martin
[0]
http://ipsysctl-tutorial.frozentux.net/chunkyhtml/theconfvariables.html#AEN634
--
Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED]
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
