Re: [LARTC] really weird problem with 2.2.20 kernel
> On Tuesday 13 August 2002 21:58, Jussi Mäki wrote: > > I'm trying to limit the available bandwidth for an single ip address, i've > > got 3 different scripts which all work with kernel 2.2.17 and all the > > 2.4.x kernel's i've tested.. > > > > The problem is that when for example i limit the traffic to 512kbit/s i'm > > only getting about 300kbit/s and this is only with 2.2.20 kernel.. > > > > I've tried htb and cbq with different schudulers like sfq and pfifo and > > all of them have the exact same problem. > > > > I'm not very keen on upgrading to kernel 2.4.x as i have to upgrade quite > > a few machine's at once and none of them have compilation tools. > > > > Any ideas? > What if you have no qos enabled? Maybe it's a driver or hardware problem. Then it isnt limited in any way. And i've tried with different hardware, with different ethernet cards. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] really weird problem with 2.2.20 kernel
On Tuesday 13 August 2002 21:58, Jussi Mäki wrote: > I'm trying to limit the available bandwidth for an single ip address, i've > got 3 different scripts which all work with kernel 2.2.17 and all the > 2.4.x kernel's i've tested.. > > The problem is that when for example i limit the traffic to 512kbit/s i'm > only getting about 300kbit/s and this is only with 2.2.20 kernel.. > > I've tried htb and cbq with different schudulers like sfq and pfifo and > all of them have the exact same problem. > > I'm not very keen on upgrading to kernel 2.4.x as i have to upgrade quite > a few machine's at once and none of them have compilation tools. > > Any ideas? What if you have no qos enabled? Maybe it's a driver or hardware problem. Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] really weird problem with 2.2.20 kernel
I'm trying to limit the available bandwidth for an single ip address, i've got 3 different scripts which all work with kernel 2.2.17 and all the 2.4.x kernel's i've tested.. The problem is that when for example i limit the traffic to 512kbit/s i'm only getting about 300kbit/s and this is only with 2.2.20 kernel.. I've tried htb and cbq with different schudulers like sfq and pfifo and all of them have the exact same problem. I'm not very keen on upgrading to kernel 2.4.x as i have to upgrade quite a few machine's at once and none of them have compilation tools. Any ideas? ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb3 & imq
> i have acheived restrictinng both in&out trafic using imq0.. i have > marked the packets on different ineterface, hence sending them to the > rules i want & then used **FORWARD** to imq .!.. it works pretty good, > though done in a test bed of 4 ip.. i want to scale it to our running > linux box handling about 250 ip's with 1.5mbps link.. > the question now i have start thinking, after Tobias Geiger'smail is --> > what will be the cpu overhead when the linix box also runs squid in it.. > withh htb3 & imq show the same result as shown in the test ? > i hope & feel it will .. :) I think the CPU is not so important. I think there are other problems with shaping incoming bandwidth with imq. First of all, you can create an extra queue and so extra delays. But using a "shared" structure to manage incoming problems can also be a problem. Imagine a setup where 100 kbps is split in 2 parts of 50 and they can borrow from each other. One class is empty and one class is filled. When there is suddenly a burst in the empty class of 50 kbps, it will take some time before the traffic in the full class will throttle down to 50kbps. And don't forget the extra delay introduced by the imq device, so the response will even be slower. It's better to be sure the 50kbps is available for the bursty traffic. Of cours, you waste some bandwidth, but a few kbps is enough to make telnet more responsive. So you can do some shaping on incoming traffic, but bursty traffic is not so easy to mange. To be honest, I just start reading and thinking about shaping incoming traffic, so any suggestions are welcome. Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] double rule
On Tuesday 13 August 2002 17:41, Petre Bandac wrote: > I want to shape the traffic on the http port and further on shape it if the > destination ip is on some network I specify > > however, only the first rule is applied ... why ? Because you add both rules to the same parent. When one rule is matched, the packet is put in the destination class and the other rule is never matched. Atach the second rule to class 1:11 with option "parent 1:11" and it should work. Stef > #http > $filtru prio 1 u32 match ip sport 80 0x flowid 1:11 > #droop :-) > $filtru prio 1 u32 match ip src x.x.x.x \ > match ip dst x.x.x.0/24 flowid 1:13 > > where classes are defined earlier as > > $tc class add dev eth0 parent 1:1 classid 1:10 \ > htb rate 32kbit ceil 32kbit > > $tc class add dev eth0 parent 1:1 classid 1:11 \ > htb rate 64kbit ceil 64kbit > > $tc class add dev eth0 parent 1:1 classid 1:12 \ > htb rate 128kbit ceil 160kbit > > $tc class add dev eth0 parent 1:1 classid 1:13 \ > htb rate 100kbit ceil 100kbit > > and > > filtru="$tc filter add dev eth0 protocol ip \ > parent 1:0" > > > thanks in advance, > > petre -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] double rule
I want to shape the traffic on the http port and further on shape it if the destination ip is on some network I specify however, only the first rule is applied ... why ? #http $filtru prio 1 u32 match ip sport 80 0x flowid 1:11 #droop :-) $filtru prio 1 u32 match ip src x.x.x.x \ match ip dst x.x.x.0/24 flowid 1:13 where classes are defined earlier as $tc class add dev eth0 parent 1:1 classid 1:10 \ htb rate 32kbit ceil 32kbit $tc class add dev eth0 parent 1:1 classid 1:11 \ htb rate 64kbit ceil 64kbit $tc class add dev eth0 parent 1:1 classid 1:12 \ htb rate 128kbit ceil 160kbit $tc class add dev eth0 parent 1:1 classid 1:13 \ htb rate 100kbit ceil 100kbit and filtru="$tc filter add dev eth0 protocol ip \ parent 1:0" thanks in advance, petre -- 6:39pm up 6:21, 1 user, load average: 0.06, 0.10, 0.06 ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb3 & imq
Stef Coene wrote: > On Tuesday 13 August 2002 01:07, Tobias Geiger wrote: > >>Arindam Haldar wrote: >> >>>hi Alex, >>>thanx so much.. :) .. thanx to all >>>my IMQ & htb3 test rules are working ok.. the best part--> imq handling >>>both in & out traffic now.. :) >> >>I also had this setup, and i also thought of it as a "cool thing" :) >>but then Patrick told me, that it's not so clever: the incoming traffic >>must pass 2 qdiscs (interface-qdisc and imq-qdisc) and this is bad/not >>good because >>1) cpu - overhead (but this could be negleted) AND >>2) these 2 qdiscs COULD drop packets and no one would know of the other >>having dropped s.th. -> retransmit >>ok. case 2 is not so realistic, as the qdisc on the interface normaly >>is the qfifo but nevertheless point 1) and the possibility of 2) made me >>think that queing double unnecessary. > > Basic incoming shaping can be done with the ingress qdisc and the policers. > This is not a real qdisc with a queue, but it can throttle down incoming > packets without creating extra delays. It just droppes incoming packets > untill the wanted rate is reached. > > Stefi have acheived restrictinng both in&out trafic using imq0.. i have marked the packets on different ineterface, hence sending them to the rules i want & then used **FORWARD** to imq .!.. it works pretty good, though done in a test bed of 4 ip.. i want to scale it to our running linux box handling about 250 ip's with 1.5mbps link.. the question now i have start thinking, after Tobias Geiger'smail is --> what will be the cpu overhead when the linix box also runs squid in it.. withh htb3 & imq show the same result as shown in the test ? i hope & feel it will .. :) A.H ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Question on hashkey
On Tuesday 13 August 2002 04:27, Cheng Kwok Wing, William wrote: > Hi, > > Thanks for your reply. > > Does it mean that "fw" has implemented hashing > implicitly?? > > Suppose I've the following fitler rules: > tc filter add dev eth0 parent 1: protocol ip prio 3 > handle 1 fw > tc filter add dev eth0 parent 1: protocol ip prio 3 > handle 2 fw > tc filter add dev eth0 parent 1: protocol ip prio 3 > handle 3 fw > tc filter add dev eth0 parent 1: protocol ip prio 3 > handle 4 fw > and more > How does the hashing work here?? What is the hash key? There is no real hash key. If you add the filter : tc filter add dev eth0 parent 1: protocol ip prio 3 fw then the mark is used as the classid. So packets marked with 3 will end in class 1:3, etc. So you only need 1 fulter. Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb3 & imq
On Tuesday 13 August 2002 01:07, Tobias Geiger wrote: > Arindam Haldar wrote: > > hi Alex, > > thanx so much.. :) .. thanx to all > > my IMQ & htb3 test rules are working ok.. the best part--> imq handling > > both in & out traffic now.. :) > > I also had this setup, and i also thought of it as a "cool thing" :) > but then Patrick told me, that it's not so clever: the incoming traffic > must pass 2 qdiscs (interface-qdisc and imq-qdisc) and this is bad/not > good because > 1) cpu - overhead (but this could be negleted) AND > 2) these 2 qdiscs COULD drop packets and no one would know of the other > having dropped s.th. -> retransmit > ok. case 2 is not so realistic, as the qdisc on the interface normaly > is the qfifo but nevertheless point 1) and the possibility of 2) made me > think that queing double unnecessary. Basic incoming shaping can be done with the ingress qdisc and the policers. This is not a real qdisc with a queue, but it can throttle down incoming packets without creating extra delays. It just droppes incoming packets untill the wanted rate is reached. Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
