[Olsr-users] Question about hidden node behavior

[Mitar]

Hi!

Just to clarify, bad ETX is just a symptom, the fact is that the link
gets very bad. So it is not a problem of problems in measuring ETX
(like fixed multicast or QoS) but that the link is bad by itself.

RTS/CTS does not help in any way.

tcpdump has shown absolutely no OLSR packets getting directly between
fri and trzaska-12.

So problem is when users on trzaska-12 download traffic. Then fri node
(uplink) is sending data to glinska-9 and glinska-9 sends this further
to trzaska-12 node. So, what is interesting that trzaska-12--glinska-9
link stay at ETX 1.0, while under this load traffic from glinska-9 to
fri seems to get lost.

On Fri, Jan 7, 2011 at 12:10 AM, Markus Kittenberger
<(spam-protected)> wrote:
> imho the easiest method to find out which link disturbs what, is to create
> (unidirectional) test-traffic from one node to a neighbour, and monitor the
> changes in other links,.. (and so on,..)

I have real data. So when traffic flows from fri towards trzaska-12
problems occur.

> furthermore i don`t think that fri cannot receive an olsr packet from
> glinska, because of trzaska is sending at this moment aswell,..

Yes. Exactly this is strange to me too. If I understand you correctly
then we are saying the same thing. That fri should not have problems
receiving from glinska-9, but only that glinska-9 should have problems
receiving from fri as trzaska-12 can send traffic at the same time
disrupting packets. But this should also be visible on a link towards
trzaska-12 as also traffic from trzaska-12 towards glinska-9 could be
disrupted. So why it is not visible? Because trzaska-12 sees traffic
(channel use) from fri (fri has a huge omni antena), but fri does not
see traffic from trzaska-12?

> (if this theory is correct, rts/cts could improve it a bit)

Does not really help, it seems. But maybe it helps for other data load
and just OLSR packets are smaller than 200 bytes so I cannot see
improvements on ETX. I could for test set threshold to 1 and see. ;-)

> ok, what kind of uplink:

VPN.

So there are two hops from fri to trzaska-12 (over glinska-9).

> priorize olsrd traffic is a very good idea!
> even when priorizing olsrd packets the effects of traffic to link-quality
> can be far bigger as u might want *G

Opened a ticket for that. Thanks. ;-)


Mitar