[OLSR-users] Double radio mesh test

[Andrew Hodel]

As I can recall from the many conversations about mesh dynamics, and the 
lack of support for the GPL from them, they use 3 radios.  1 is to 
determine channel allocation for the other 2.

The have developed real time kernel extensions for the wireless drivers 
to allow this functionality, and this is the reason people are 
complaining about the GPL.  According to GPL they should release this stuff.

read:
http://www.smallworks.com/archives/00000072.htm

read comments here:
http://hardware.slashdot.org/article.pl?sid=05/03/06/1432243&tid=193
http://dailywireless.org/modules.php?name=News&file=article&sid=2750


Andrew


Henrion Benjamin wrote:

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