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

[(spam-protected)]

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

I think that:
1) Wireless links do not fall into the category of "link speed being
equal to the available bandwidth".

2) If you have three SFQs attached to a PRIO, neither the SFQs nor the
PRIO will own the queue. This is because the PRIO is work-conserving and
also because there are three unlimited SFQs attached to the same qdisc.

However I am about to make a test. I will post my results...

Bye,
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/20100112/53531dba/attachment.sig>