[OLSR-users] Double radio mesh test

[Henrion Benjamin]

Henrion Benjamin <(spam-protected)> [050418]:
> Stefan Sayer <(spam-protected)> [050418]:
> > Hello,
> > 
> > I wonder whether meshdynamics' multi radio network is configured in a 
> > distributed way or whether there is e.g. a central station that would 
> > let the other station channel hop - they say that the network will 
> > dynamically adapt to interference.

About meshdynamics internals, there are nice pictures of their routers
here:

http://www.linuxdevices.com/articles/AT8452908209.html

It has 4 minipci slots and 3 radios...

> > 
> > If it is really distributedly self configuring then I wonder how a 
> > station can find a neighbor station that has hopped to another channel 
> > to talk to another node (avoiding interference on the previous channel) 
> > without scanning all the time. consider this:
> > 
> > first A is talking to B on ch1
> > A 1 ----------- 1 B
> > 
> > C                 D
> > 
> > then A and C hop to ch 6 while e.g. B talks to D on ch1
> > A 6             1 B
> >   |             |
> > C 6             1 D
> > 
> > then B wants to talk to C: how does it know on which channel ?
> 
> (I assume that B does not see C directly)
> 
> Then you have 2 options:
> 
> A 1--------------1 B
> 6
> |
> |
> 6
> C
> 
> Or
> 
> A 6--------------6 B
> 1
> |
> |
> 1
> C
> 
> The protocol should choose solution 1 or 2 by having either a "Link
> Quality" value for each connexion, or either a direct bandwidth
> measurement (which can vary with the traffic). In this last case, if the
> traffic is high on one connexion at time t, it won't be necessary the
> case at t+1. Maybe a value of "real available bandwidth" would be
> interesting to have for the protocol, as a mean to choose the best path.
> 
> > In their graphics about 2,3,4 radios they never have a more realistic 
> > mesh situation where some nodes are in the same range - there is alway 
> > only two nodes in one circle.
> 
> Yes, that's a problem. Choosing which neighboor to transmit is not a
> problem, since the node has not the choice in this case.
> 
> The problem is to get values of throughput for each link. No?
> 
> > Stefan
> > 
> > 
> > Jeromie Reeves wrote:
> > >That should work fine. The trick will be to use manual channel selection 
> > >to avoid having the same channel space
> > >on every single unit (IE 1 & 11 on every unit).
> > >
> > >1 & 11 ---  1 & 6  --- 6 & 11
> > >
> > >That way you force the packets to change radios and help stop self 
> > >interferance
> > >There is no problem having units around that also use the same channels, 
> > >just dont
> > >do it network wide.
> > >
> > >Jeromie
> > >
> > >Henrion Benjamin wrote:
> > >
> > >>Very interesting report here:
> > >>
> > >>http://www.meshdynamics.com/MDTestResults3Radio.html
> > >>
> > >>You only need 2 radios/node if you don't care about "people with their
> > >>laptops" who access with the 3rd.
> > >>
> > >>Is it possible to do the same with OLSR? Maybe OLSR running on 2
> > >>different wireless interfaces on 2 different channels (like 1 and 11)?
> > >>
> > >>Do you think it might be possible?
> > >>
> > >>-- 
> > >>Benjamin Henrion <(spam-protected)>
> > >>http://bh.udev.org
> > >><<                 Software patents are a 
> > >>Temptation                     >>>
> > >><<                  Temptation leads to 
> > >>Stagnation                       >>>
> > >><<                Stagnation leads to the Dark 
> > >>Side.                     >>>
> > >>_______________________________________________
> > >>olsr-users mailing list
> > >>(spam-protected)
> > >>https://www.olsr.org/mailman/listinfo/olsr-users
> > >>
> > >> 
> > >>
> > >
> > >_______________________________________________
> > >olsr-users mailing list
> > >(spam-protected)
> > >https://www.olsr.org/mailman/listinfo/olsr-users
> > >
> > >
> > 
> 
> 
> 
> > _______________________________________________
> > olsr-users mailing list
> > (spam-protected)
> > https://www.olsr.org/mailman/listinfo/olsr-users
> 
> 
> -- 
> Benjamin Henrion <(spam-protected)>
> http://bh.udev.org
> <<                 Software patents are a Temptation                     >>>
> <<                  Temptation leads to Stagnation                       >>>
> <<                Stagnation leads to the Dark Side.                     >>>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users

-- 
Benjamin Henrion <(spam-protected)>
http://bh.udev.org
<<                 Software patents are a Temptation                     >>>
<<                  Temptation leads to Stagnation                       >>>
<<                Stagnation leads to the Dark Side.                     >>>