[Olsr-users] How to prioritize OLSR UDP packets.

[Markus Kittenberger]

i just testet my own scripts now,..  and they do work mostly as expected,..

i also had some problems, to get a working setup where i can test if traffix
X gets priorized or not
(especially as i tried to create the 2 test udp stream on the same host, but
i did not investigate further)

my test setup
a ... b --- c

... is a 100mbit link
--- 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))

priorization was made on b

traffic was created on a (udp port 5001) and b (udp port 5002)

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
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

5001: 1.8mbit
5002: 1.2mbit

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
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

5001:0.1mbit
5002:1.8mbit

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
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

5001 4.0mbit
5002 0.0mbit (so no chance for traffic on port 5002, or infact for any
traffic on flowid 1:2 or 1:3)

mostly this results are as expected,

regards Markus

On Wed, Jan 13, 2010 at 1:13 PM, <(spam-protected)> wrote:

> On 01/12/2010 05:22 PM, Markus Kittenberger wrote:
> > On Tue, Jan 12, 2010 at 4:02 PM,  <(spam-protected)
> > <mailto:(spam-protected)>> wrote:
> >
> >     On 01/12/2010 03:10 PM, Michael Rack wrote:
> >     >
> >     >> ... to specify the available bandwith. Otherwise (i.e. with
> >     "infinite"
> >     >> bandwidth available") the tc queues will always have zero packets
> and
> >     >> prioritization will not work.
> >     >
> >     > Markus Kittenberger has posted a short snipped of the QOS Setup.
> >     > Message-ID: (spam-protected)
> >     <mailto:(spam-protected)>
> >     >
> >     > This setup handle 3 SFQs (Stochastic Fairness Queuing). The filter
> >     > methods have priority settings 1,2,3,4 and 5. With this setup you
> >     don't
> >     > have to know the uplink speed. Matching packets that are queued
> will
> >     > reordered as defined the rest is done by your OS network-stack.
> >
> >
> >     The man page of SFQ [http://linux.die.net/man/8/tc-sfq] says:
> >
> >     """
> >     Please note that SFQ, like all non-shaping (work-conserving) qdiscs,
> is
> >     only useful if it owns the queue. This is the case when the link
> speed
> >     equals the actually available bandwidth. This holds for regular phone
> >     modems, ISDN connections and direct non-switched ethernet links.
> >
> >     Most often, cable modems and DSL devices do not fall into this
> category.
> >
> > because they are potentially doing their own packet reordering and
> > droppping, and have usually a faster link to your router than to the
> > other end of the DSL or whatever,..
> >
> >     The same holds for when connected to a switch and trying to send data
> to
> >     a congested segment also connected to the switch.
> >
> >     In this case, the effective queue does not reside within Linux and is
> >     therefore not available for scheduling.
> >
> >     Embed SFQ in a classful qdisc to make sure it owns the queue.
> >
> > fyi The PRIO qdisc is a classful qdisc!
> >
> >     """
> >
> >     I think that:
> >     1) Wireless links do not fall into the category of "link speed being
> >     equal to the available bandwidth".
> >
> >
> > 1 is true imho
> >
> > noone says that the speed must be static *G
>
> Hello.
> I hope that this can be useful to go through the issue. On the Linux
> advanced routing and traffic control howto, at this page:
> http://lartc.org/howto/lartc.qdisc.classful.html
> I found the following, at 9.5.1 - Flow within classful qdiscs & classes:
> """
> Besides containing other qdiscs, most classful qdiscs also perform
> shaping. This is useful to perform both packet scheduling (with SFQ, for
> example) and rate control. You need this in cases where you have a high
> speed interface (for example, ethernet) to a slower device (a cable modem).
>
> If you were only to run SFQ, nothing would happen, as packets enter &
> leave your router without delay: the output interface is far faster than
> your actual link speed. There is no queue to schedule then.
> """
>
> And at 9.5.3 - The PRIO qdisc:
> """
> Because it doesn't actually shape, the same warning as for SFQ holds:
> either use it only if your physical link is really full or wrap it
> inside a classful qdisc that does shape. The latter holds for almost all
> cable modems and DSL devices.
>
> In formal words, the PRIO qdisc is a Work-Conserving scheduler.
> """
>
> Ciao,
> Clauz
>
>
>
> --
> Olsr-users mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20100113/a6ff4d6f/attachment.html>