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

[(spam-protected)]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20100113/5575342e/attachment.sig>