I''ve done my first test with ingress,
2 ftps, and I''ve seen that the bandwidth is not shared "very
well".
From the point of view of a user, his transfer stops suddenly, and
restarts 20 seconds (or more!) later. Then the other has to wait !! I
observ a kind of feedback process, beeing the interval of stopped traffic
bigger each time, during the transference.
The bandwidth is limited to 64.000 bit per second, killing packets.
In fact it is not a real ethernet link, and the filter is on a vmware
machine computer, so maybe this test is not valid.
Anyone knows more about this behaviour ??
Could I optimize it playing with burst and mpu ?
Or am I doing something really bad ?
Thank you,
Here''s my filter:
iptables -A PREROUTING -i eth0 -t mangle --protocol all -j MARK --set-mark
1
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 5 handle 1 fw \
police rate 8000bps burst 10k mpu 64b drop flowid :1
--
__o
_ \<_
(_)/(_)
Saludos de Julián
EA4ACL
-.-
Foro Wireless Madrid
http://opennetworks.rg3.net
For me ingress works great. ok, i more or less copy/pasted from the "wondershaper" :) I guess it''s not good to have a rate of 8000bps AND a burst of 10k I''m also not shure, if the iptables-marks get noticed, but it seems so, as you said there is a shaping effect. but as your iptable-rule is so generally i''d say there''s no reason not to use the appropriate u32 filter instead of fw. VMWare shouldn''t be the problem, at least i never had ones. Tell me, if tuning rate/burst helped Greetings Tobias On Thu, Mar 21, 2002 at 12:29:09PM +0000, Julián Muñoz wrote:> > I''ve done my first test with ingress, > > 2 ftps, and I''ve seen that the bandwidth is not shared "very well". > > From the point of view of a user, his transfer stops suddenly, and > restarts 20 seconds (or more!) later. Then the other has to wait !! I > observ a kind of feedback process, beeing the interval of stopped traffic > bigger each time, during the transference. > > The bandwidth is limited to 64.000 bit per second, killing packets. > > In fact it is not a real ethernet link, and the filter is on a vmware > machine computer, so maybe this test is not valid. > > Anyone knows more about this behaviour ?? > > Could I optimize it playing with burst and mpu ? > > Or am I doing something really bad ? > > Thank you, > > Here''s my filter: > > iptables -A PREROUTING -i eth0 -t mangle --protocol all -j MARK --set-mark > 1 > > tc qdisc add dev eth0 handle ffff: ingress > > tc filter add dev eth0 parent ffff: protocol ip prio 5 handle 1 fw \ > police rate 8000bps burst 10k mpu 64b drop flowid :1 > > > -- > > __o > _ \<_ > (_)/(_) > > Saludos de Julián > EA4ACL > -.- > > Foro Wireless Madrid > http://opennetworks.rg3.net > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
the "wondershaper" by one of the authors of the LARTC-HOWTO: http://lartc.org/HOWTO//cvs/2.4routing/output/2.4routing-15.html at the very end of this html-page simply copy/paste the ingress-line and the next line which is the u32 filter for the ingress-qdisc. that worked perfect for me :)> Thank you Tobias, > > > For me ingress works great. > > ok, i more or less copy/pasted from the "wondershaper" :) > > Eh? > > > I guess it''s not good to have a rate of 8000bps AND a burst of 10k > > I have set burst to 3k, and this has not helped, I still see the "not > nice" sharing at the input. > Maybe I should increase burst ?? > >well, what do you want? i guess i want to "test" the ingress-qdisc, and as far i understand the whole thing it''s no good idea to set a specific rate but at the same time allow a burst that''s x*specific-rate. i always set my burst to something like specific-rate/10 or so in your example with 8000bps rate, i''d test a burst of 800 or even less> > I''m also not shure, if the iptables-marks get noticed, but it seems so, > > as you said there is a shaping effect. > > You say the if I use u32 maybe this effect would disappear ? > >like i said: i dont'' know exactly :) i''m not in this c / hardcore-kernelprogramming stuff, so i don''t know for shure which code comes first in case of ingress: the qdisc-stuff or the iptables stuff. if the iptables stuff comes first (and it seems so) then everything''s ok. let it be. the "effect" has nothing to do with your filter, more with your qdisc (i guess :)> > but as your iptable-rule is so > > generally i''d say there''s no reason not to use the appropriate u32 > > filter instead of fw. > > The problem is that u32 is not well documented :-( > I had to install all the ipchains and after iptables, because was unable > to do anything "coherent" with u32... > >like mentioned above: the last line of code in the html-page is the u32-filter line you need (and which does the same as your iptables-mark-rule) good luck tobias
I reread your Subject line and noticed you meant SHARING. i always read SHAPING. Make sure u can''t actually SHARE your incoming bandwith. you can just throttle it down (to gain more interactivity on a heavy loaded link) I hope we didn''t missunderstand each other Tobias
Ok, what I really wanted was to prioritize some kinds of incoming traffic (DNS or HTTP) (or penalyze some other, which is same), exactly for what you say, "gain interactivity on a heavy loaded link" but doing test, I saw this strange "non fairness sensation", which is maybe problematic ?? That''s why I ask if someone has already seen this behaviour, or it is specific of my system ? The test is very easy, do 2 ftp in parallel. I am going to recompile 2.4 on my main computer, hopping this is a caused by vmware :-) On Thu, 21 Mar 2002, Tobias Geiger wrote:> > I reread your Subject line and noticed you meant SHARING. i always read > SHAPING. > Make sure u can''t actually SHARE your incoming bandwith. you can just > throttle it down (to gain more interactivity on a heavy loaded link) > > I hope we didn''t missunderstand each other > > Tobias > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >-- __o _ \<_ (_)/(_) Saludos de Julián EA4ACL -.- Foro Wireless Madrid http://opennetworks.rg3.net
With IMQ you can ;)> Make sure u can''t actually SHARE your incoming bandwith. you can just > throttle it down (to gain more interactivity on a heavy loaded link)
On Thu, 2002-03-21 at 10:11, Martin Devera wrote:> With IMQ you can ;)Except the lack of documentation makes me scared to use it (or try to figure it out). :) Jason.
indeed. If someone want to volunteer docs I will give all neccessary info ;) devik On 21 Mar 2002, Jason Tackaberry wrote:> On Thu, 2002-03-21 at 10:11, Martin Devera wrote: > > With IMQ you can ;) > > Except the lack of documentation makes me scared to use it (or try to > figure it out). :) > > Jason. > > >
You say that IMQ could be attached to a device to the incoming side ?? On Thu, 21 Mar 2002, Martin Devera wrote:> With IMQ you can ;) > > > Make sure u can''t actually SHARE your incoming bandwith. you can just > > throttle it down (to gain more interactivity on a heavy loaded link) > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >-- __o _ \<_ (_)/(_) Saludos de Julián EA4ACL -.- Foro Wireless Madrid http://opennetworks.rg3.net