AW: Does tc-prio really work as advertised?

AW: Does tc-prio really work as advertised?

[Joerg Pommnitz]

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

The OLSR traffic was obviously generated locally (not forwarded).
You claim, that the TOS value for locally generated traffic does
not influence its priority?

Now I THINK that I did my tests both, for forwarded and for
local traffic, but I'll redo my tests to make sure.

 
--  
Regards and thanks for taking an interest

 
       Joerg




        __________________________________  Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern.  www.yahoo.de/clever

Re: Does tc-prio really work as advertised?

[Jarek Poplawski]

On Tue, Nov 27, 2007 at 05:00:55AM -0800, Joerg Pommnitz wrote:
...
> The OLSR traffic was obviously generated locally (not forwarded).
> You claim, that the TOS value for locally generated traffic does
> not influence its priority?

I wouldn't say "I claim": I've found something like this 'long time
ago' (enough to forget), and didn't need this information since
then. Now, I see you have 'nearby' problem, so it's only a hint.
After your first message I think you should be able to check this
by yourself. But, if there are any problems with this, you find my
idea wrong or not valid anymore, I'm interested in knowing about
this.

Cheers,
Jarek P.

Re: Does tc-prio really work as advertised?

[Michael Blizek]

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

AW: Does tc-prio really work as advertised?

[Joerg Pommnitz]

 > It works fine here, I'm guessing that Jörg is using an old kernel
 > version that had a bug in prio classification without filters.

This is 2.6.20.21, from 17-Oct-2007. 
 
--  
Regards
 
       Joerg




       __________________________________  Ihre erste Baustelle? Wissenswertes für Bastler und Hobby Handwerker. www.yahoo.de/clever

Re: AW: Does tc-prio really work as advertised?

[Patrick McHardy]

Joerg Pommnitz wrote:
>  > It works fine here, I'm guessing that Jörg is using an old kernel
>  > version that had a bug in prio classification without filters.
> 
> This is 2.6.20.21, from 17-Oct-2007. 


Yes, that version is broken. I think it was fixed in 2.6.22 or 2.6.23.

AW: Does tc-prio really work as advertised?

[Joerg Pommnitz]

Jarek,
this is all about outgoing packets, e.g. egress to use your word.
It doesn't matter whether the packets are originated locally or
whether the packets are forwarded from another host (I tried
both).

To restate the problem: according to my observations the prio qdisc
(and probably pfifo_fast, but I couldn't observe this) does not prioritize
at all and always uses the band indicated by the first entry in the
priomap.

By default the priomap looks like this:
qdisc prio 1: dev eth1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

there are 3 bands (1:1, 1:2 and 1:3). In theory the traffic should go through
the different bands according to the TOS value of the packets. My observation
is, that the traffic always uses the band pointed to by the first entry in the
priomap. This value is 1 by default, so all traffic goes through band 1:2.

Now it's entirely possible that I did something stupid, but nobody came forward
to show me the error of my ways (neither here nor on the lartc list).

-- Regards
 
       Joerg

----- Ursprüngliche Mail ----
Von: Jarek Poplawski <jarkao2@o2.pl>
An: Joerg Pommnitz <pommnitz@yahoo.com>
CC: netdev@vger.kernel.org
Gesendet: Dienstag, den 27. November 2007, 10:58:38 Uhr
Betreff: Re: Does tc-prio really work as advertised?

On Tue, Nov 27, 2007 at 01:28:43AM -0800, Joerg Pommnitz wrote:
> Jarek,
> iptables chains (this is what I think you are referring to) are not  the issue.

Yes, but this could (wrongly) look like this according to my 1-st  message.

> This
> is about the qdisc that sits immediately over the device driver and  decides the
> order waiting packets are sent over the line/air/carrier pigeon/... .
> My suspicion is that skb->priority used to be set to a value that  derived from the
> TOS bits. Then something changed and nobody noticed.

I'm not sure of your problem: did you try this on a box which
gets packets with TOS set earlier, does forwarding, and uses this
prio on egress? If so, and this doesn't work, then you are right
something could be wrong.

Regards,
Jarek P.






        __________________________________  Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern.  www.yahoo.de/clever