<br><br><div class="gmail_quote">On Thu, Jan 14, 2010 at 4:28 PM, <span dir="ltr"><<a href="mailto:clauz@ninux.org">clauz@ninux.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 01/14/2010 01:34 PM, Markus Kittenberger wrote:<br>
> in the first two tests i did put them into the same flow with different<br>
> prios<br>
><br>
> and in the third test i put in in different flows<br>
<br>
</div>AFAIK the tc filter's prio parameter has a different meaning. Looking at<br>
the documentation at <a href="http://lartc.org/howto/lartc.adv-filter.html" target="_blank">http://lartc.org/howto/lartc.adv-filter.html</a> :<br>
<br>
"""<br>
Classifiers in general accept a few arguments in common. They are listed<br>
here for convenience:<br>
[...]<br>
prio<br>
<br>
The priority of this classifier. Lower numbers get tested first.<br>
"""<br>
<br>
and<br>
<br>
"""<br>
The command line of tc filter program, used to configure the filter,<br>
consists of three parts: filter specification, a selector and an action.<br>
The filter specification can be defined as:<br>
<br>
tc filter add dev IF [ protocol PROTO ]<br>
[ (preference|priority) PRIO ]<br>
[ parent CBQ ]<br>
<br>
The protocol field describes protocol that the filter will be applied<br>
to. We will only discuss case of ip protocol. The preference field<br>
(priority can be used alternatively) sets the priority of currently<br>
defined filter. This is important, since you can have several filters<br>
(lists of rules) with different priorities. Each list will be passed in<br>
the order the rules were added, then list with lower priority (higher<br>
preference number) will be processed. The parent field defines the CBQ<br>
tree top (e.g. 1:0), the filter should be attached to.<br>
<br>
The options described above apply to all filters, not only U32.<br>
"""<br>
<br>
seems like the prio parameter specifies only the order in which the<br>
filter rules are tested and does not act as a "weight" on the rule.<br></blockquote><div>sounds so, but it seems to have an effect on the ordering of the sfq aswell,.. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
In any case the third test has results that are in contrast with the<br>
other two tests? That is, in the first two tests, the flow with lower<br>
prio gets the higher bandwidth, while in the third test the flow with<br>
higher prio gets the higher bandwidth?<br></blockquote><div>not really:</div><div>the traffic that goes into 1:2 simply gets (absolutely) no bandwidth #1 if 1:1 consumes it</div><div><br></div><div>an this is regardless of what prio the rule has that goes into flow 1:2<br>
</div><div><br></div><div>#1 of course only if 1:1 if able to use up all the available bandwith itself</div><div><br></div><div>resumee:</div><div>putting olsr into it¶ own hipriority "flow" is a good idea #2 </div>
<div>but putting filter rules (that may match very much traffic) into an top/mid flow (infact a sfq queue) might be no good idea,.. (if its unwanted to completely stall traffic in lower flows (e.g. 1:3))</div><div><br></div>
<div>#2 as long as olsr has no bug and produces insanely much traffic</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Bye,<br>
Clauz<br>
<div class="im"><br>
<br>
> On Thu, Jan 14, 2010 at 1:25 PM, <<a href="mailto:clauz@ninux.org">clauz@ninux.org</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:clauz@ninux.org">clauz@ninux.org</a>>> wrote:<br>
><br>
> On 01/13/2010 10:24 PM, Markus Kittenberger wrote:<br>
> > i just testet my own scripts now,.. and they do work mostly as<br>
> expected,..<br>
> ><br>
> > i also had some problems, to get a working setup where i can test if<br>
> > traffix X gets priorized or not<br>
> > (especially as i tried to create the 2 test udp stream on the same<br>
> host,<br>
> > but i did not investigate further)<br>
> ><br>
> > my test setup<br>
> > a ... b --- c<br>
> ><br>
> > ... is a 100mbit link<br>
> > --- an 5.5mbit 801.11b wireless link capable of (somewhat stable) 2 to<br>
> > 4.5mbit useable udp throughput (in olsr terms its a rock solit ETX 1.0<br>
> > link (20meter but outoor *g))<br>
> ><br>
> > priorization was made on b<br>
> ><br>
> > traffic was created on a (udp port 5001) and b (udp port 5002)<br>
> ><br>
> > tc filter $1 dev $DEV protocol ip parent 1: prio 3 u32 match ip<br>
> protocol<br>
> > 17 0xff match ip dport 5001 0xffff flowid 1:1<br>
> > tc filter $1 dev $DEV protocol ip parent 1: prio 4 u32 match ip<br>
> protocol<br>
> > 17 0xff match ip dport 5002 0xffff flowid 1:1<br>
> ><br>
> > 5001: 1.8mbit<br>
> > 5002: 1.2mbit<br>
> ><br>
> > tc filter $1 dev $DEV protocol ip parent 1: prio 19 u32 match ip<br>
> > protocol 17 0xff match ip dport 5001 0xffff flowid 1:1<br>
> > tc filter $1 dev $DEV protocol ip parent 1: prio 3 u32 match ip<br>
> protocol<br>
> > 17 0xff match ip dport 5002 0xffff flowid 1:1<br>
> ><br>
> > 5001:0.1mbit<br>
> > 5002:1.8mbit<br>
> ><br>
> > tc filter $1 dev $DEV protocol ip parent 1: prio 4 u32 match ip<br>
> protocol<br>
> > 17 0xff match ip dport 5001 0xffff flowid 1:1<br>
> > tc filter $1 dev $DEV protocol ip parent 1: prio 3 u32 match ip<br>
> protocol<br>
> > 17 0xff match ip dport 5002 0xffff flowid 1:2<br>
> ><br>
> > 5001 4.0mbit<br>
> > 5002 0.0mbit (so no chance for traffic on port 5002, or infact for any<br>
> > traffic on flowid 1:2 or 1:3)<br>
><br>
> Hello.<br>
> You did three tests and just changed the value of the "prio" parameter<br>
> in each test, right? In the first two tests do you classify the two<br>
> flows into the same class (1:1), or it's a typo?<br>
><br>
> Clauz<br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br>