[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20071130183946.GB2368@grml.local>
Date: Fri, 30 Nov 2007 19:39:46 +0100
From: Michael Blizek <michi1@...haelblizek.homelinux.net>
To: netdev@...r.kernel.org
Cc: Joerg Pommnitz <pommnitz@...oo.com>,
Jarek Poplawski <jarkao2@...pl>
Subject: Re: Does tc-prio really work as advertised?
Hi!
On 05:00 Tue 27 Nov , Joerg Pommnitz wrote:
> > So, are you still sure you've tested such a case?
>
> Well, the problem that triggered my investigation was
> that the OLSR daemon (www.olsr.org) calculates the quality
> of a link according to the packet loss for LQ HELLO packets
> (UDP broadcast packets). To prevent other traffic from
> interfering with the LQ calculation, olsrd sends the HELLO
> packets with a TOS value of 0x10 (minimize delay). This
> should give them the highest priority.
>
> What I saw was a degrading Link quality with more user traffic
> over a link. The LQ fell so far that olsrd judged the other host
> unreachable and deleted the routing entry. The user traffic in
> question was iperf (TOS value 0x00).
> --
> Regards and thanks for taking an interest
>
>
> Joerg
There is another possible cause of this problem.
In WLANs all packets are acked or retransmitted. This is done to
prevent packet loss due to noise and collisions. But this is not
done with broadcast packets.
I can't tell you if this can be enough to trigger the bevaviour
you experienced. Is the signal barely receivable?
Michi
--
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.homelinux.net
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists