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

[Markus Kittenberger]

On Tue, Jan 12, 2010 at 4:02 PM,  <(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)
> >
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20100112/cc259063/attachment.html>