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

[Markus Kittenberger]

On Thu, Jan 14, 2010 at 4:28 PM, <(spam-protected)> wrote:

> On 01/14/2010 01:34 PM, Markus Kittenberger wrote:
> > in the first two tests i did put them into the same flow with different
> > prios
> >
> > and in the third test i put in in different flows
>
> AFAIK the tc filter's prio parameter has a different meaning. Looking at
> the documentation at http://lartc.org/howto/lartc.adv-filter.html :
>
> """
> Classifiers in general accept a few arguments in common. They are listed
> here for convenience:
> [...]
> prio
>
>    The priority of this classifier. Lower numbers get tested first.
> """
>
> and
>
> """
> The command line of tc filter program, used to configure the filter,
> consists of three parts: filter specification, a selector and an action.
> The filter specification can be defined as:
>
> tc filter add dev IF [ protocol PROTO ]
>                     [ (preference|priority) PRIO ]
>                     [ parent CBQ ]
>
> The protocol field describes protocol that the filter will be applied
> to. We will only discuss case of ip protocol. The preference field
> (priority can be used alternatively) sets the priority of currently
> defined filter. This is important, since you can have several filters
> (lists of rules) with different priorities. Each list will be passed in
> the order the rules were added, then list with lower priority (higher
> preference number) will be processed. The parent field defines the CBQ
> tree top (e.g. 1:0), the filter should be attached to.
>
> The options described above apply to all filters, not only U32.
> """
>
> seems like the prio parameter specifies only the order in which the
> filter rules are tested and does not act as a "weight" on the rule.
>
sounds so, but it seems to have an effect on the ordering of the sfq
aswell,..

>
> In any case the third test has results that are in contrast with the
> other two tests? That is, in the first two tests, the flow with lower
> prio gets the higher bandwidth, while in the third test the flow with
> higher prio gets the higher bandwidth?
>
not really:
the traffic that goes into 1:2 simply gets (absolutely) no bandwidth #1 if
1:1 consumes it

an this is regardless of what prio the rule has that goes into flow 1:2

#1 of course only if 1:1 if able to use up all the available bandwith itself

resumee:
putting olsr into itś own hipriority "flow" is a good idea #2
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))

#2 as long as olsr has no bug and produces insanely much traffic

>
> Bye,
> Clauz
>
>
> > On Thu, Jan 14, 2010 at 1:25 PM, <(spam-protected)
> > <mailto:(spam-protected)>> wrote:
> >
> >     On 01/13/2010 10:24 PM, Markus Kittenberger wrote:
> >     > 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)
> >
> >     Hello.
> >     You did three tests and just changed the value of the "prio"
> parameter
> >     in each test, right? In the first two tests do you classify the two
> >     flows into the same class (1:1), or it's a typo?
> >
> >     Clauz
> >
> >
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20100114/14d01e9a/attachment.html>