<div>i just testet my own scripts now,.. and they do work mostly as expected,..<br></div><div><br></div><div>i also had some problems, to get a working setup where i can test if traffix X gets priorized or not<br>(especially as i tried to create the 2 test udp stream on the same host, but i did not investigate further)<br>
</div><div><br></div><div>my test setup</div><div>a ... b --- c</div><div><br></div><div>... is a 100mbit link</div><div>--- an 5.5mbit 801.11b wireless link capable of (somewhat stable) 2 to 4.5mbit useable udp throughput (in olsr terms its a rock solit ETX 1.0 link (20meter but outoor *g))</div>
<div><br></div><div>priorization was made on b</div><div><br></div><div>traffic was created on a (udp port 5001) and b (udp port 5002)</div><div><br></div><div>tc filter $1 dev $DEV protocol ip parent 1: prio 3 u32 match ip protocol 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 protocol 17 0xff match ip dport 5002 0xffff flowid 1:1</div>
<div><br></div><div>5001: 1.8mbit</div><div>5002: 1.2mbit<br><br></div><div>tc filter $1 dev $DEV protocol ip parent 1: prio 19 u32 match ip protocol 17 0xff match ip dport 5001 0xffff flowid 1:1<br></div><div><div>tc filter $1 dev $DEV protocol ip parent 1: prio 3 u32 match ip protocol 17 0xff match ip dport 5002 0xffff flowid 1:1<br>
</div><div><br></div><div>5001:0.1mbit<br>5002:1.8mbit<br></div><div><br></div></div><div>tc filter $1 dev $DEV protocol ip parent 1: prio 4 u32 match ip 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 protocol 17 0xff match ip dport 5002 0xffff flowid 1:2<br>
</div><div><br></div><div>5001 4.0mbit<br>5002 0.0mbit (so no chance for traffic on port 5002, or infact for any traffic on flowid 1:2 or 1:3) </div><div><br></div><div>mostly this results are as expected, </div><div><br>
</div><div>regards Markus</div><div><br></div>
<div class="gmail_quote">On Wed, Jan 13, 2010 at 1:13 PM, <span dir="ltr"><<a href="mailto:clauz@ninux.org" target="_blank">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>On 01/12/2010 05:22 PM, Markus Kittenberger wrote:<br>
> On Tue, Jan 12, 2010 at 4:02 PM, <<a href="mailto:clauz@ninux.org" target="_blank">clauz@ninux.org</a><br>
</div><div>> <mailto:<a href="mailto:clauz@ninux.org" target="_blank">clauz@ninux.org</a>>> wrote:<br>
><br>
> On 01/12/2010 03:10 PM, Michael Rack wrote:<br>
> ><br>
> >> ... to specify the available bandwith. Otherwise (i.e. with<br>
> "infinite"<br>
> >> bandwidth available") the tc queues will always have zero packets and<br>
> >> prioritization will not work.<br>
> ><br>
> > Markus Kittenberger has posted a short snipped of the QOS Setup.<br>
> > Message-ID: <a href="mailto:op.u6etk32h871hnn@markit.mshome.net" target="_blank">op.u6etk32h871hnn@markit.mshome.net</a><br>
</div>> <mailto:<a href="mailto:op.u6etk32h871hnn@markit.mshome.net" target="_blank">op.u6etk32h871hnn@markit.mshome.net</a>><br>
<div><div>> ><br>
> > This setup handle 3 SFQs (Stochastic Fairness Queuing). The filter<br>
> > methods have priority settings 1,2,3,4 and 5. With this setup you<br>
> don't<br>
> > have to know the uplink speed. Matching packets that are queued will<br>
> > reordered as defined the rest is done by your OS network-stack.<br>
><br>
><br>
> The man page of SFQ [<a href="http://linux.die.net/man/8/tc-sfq" target="_blank">http://linux.die.net/man/8/tc-sfq</a>] says:<br>
><br>
> """<br>
> Please note that SFQ, like all non-shaping (work-conserving) qdiscs, is<br>
> only useful if it owns the queue. This is the case when the link speed<br>
> equals the actually available bandwidth. This holds for regular phone<br>
> modems, ISDN connections and direct non-switched ethernet links.<br>
><br>
> Most often, cable modems and DSL devices do not fall into this category.<br>
><br>
> because they are potentially doing their own packet reordering and<br>
> droppping, and have usually a faster link to your router than to the<br>
> other end of the DSL or whatever,..<br>
><br>
> The same holds for when connected to a switch and trying to send data to<br>
> a congested segment also connected to the switch.<br>
><br>
> In this case, the effective queue does not reside within Linux and is<br>
> therefore not available for scheduling.<br>
><br>
> Embed SFQ in a classful qdisc to make sure it owns the queue.<br>
><br>
> fyi The PRIO qdisc is a classful qdisc!<br>
><br>
> """<br>
><br>
> I think that:<br>
> 1) Wireless links do not fall into the category of "link speed being<br>
> equal to the available bandwidth".<br>
><br>
><br>
> 1 is true imho<br>
><br>
> noone says that the speed must be static *G<br>
<br>
</div></div>Hello.<br>
I hope that this can be useful to go through the issue. On the Linux<br>
advanced routing and traffic control howto, at this page:<br>
<a href="http://lartc.org/howto/lartc.qdisc.classful.html" target="_blank">http://lartc.org/howto/lartc.qdisc.classful.html</a><br>
I found the following, at 9.5.1 - Flow within classful qdiscs & classes:<br>
"""<br>
Besides containing other qdiscs, most classful qdiscs also perform<br>
shaping. This is useful to perform both packet scheduling (with SFQ, for<br>
example) and rate control. You need this in cases where you have a high<br>
speed interface (for example, ethernet) to a slower device (a cable modem).<br>
<br>
If you were only to run SFQ, nothing would happen, as packets enter &<br>
leave your router without delay: the output interface is far faster than<br>
your actual link speed. There is no queue to schedule then.<br>
"""<br>
<br>
And at 9.5.3 - The PRIO qdisc:<br>
"""<br>
Because it doesn't actually shape, the same warning as for SFQ holds:<br>
either use it only if your physical link is really full or wrap it<br>
inside a classful qdisc that does shape. The latter holds for almost all<br>
cable modems and DSL devices.<br>
<br>
In formal words, the PRIO qdisc is a Work-Conserving scheduler.<br>
"""<br>
<br>
Ciao,<br>
Clauz<br>
<br>
<br>
<br>--<br>
Olsr-users mailing list<br>
<a href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
<a href="http://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-users</a><br></blockquote></div><br>