[olsr-dev] LQ-FishEye + LinkQualityDjikstraLimit

[elektra]

Hello -

I think it should be better communicated on the web page that olsrd only 
works reasonable if ETX/LQ *and*  LinkQualityFishEye is used. Without 
the LinkQualityFishEye-Mechanism and redundant TC-messages (they should 
be more frequent than Hello messages, I'd say two or three times)  olsrd 
creates nice routing tables as long as there is no payload. As soon as 
payload is introduced routes flap and routing loops occur. So it is no 
longer true that LinkQualityFishEye-Mechanism is a experimental feature 
- it was that important missing improvement that made olsr finally 
functional for the Freifunk networks. Since LinkQualityFishEye it is no 
problem anymore to perform a FTP download over a route of 8 hops here in 
Berlin...

I think the configuration-file with ETX/LQ *and*  LinkQualityFishEye in 
/files/ should become the default when performing a make install. 
LinkQualityFishEye is compatible with olsr-nodes that don't use the 
algorithm - but I would recommend to update all nodes in your 
mesh-networks as soon as possible to have the mesh work nicely. See the 
Readme about FishEye. When I was in Dharamsala/India it became obvious 
that the AirJaldi mesh suffered Routing Loops because they didn't know 
how to configure olsrd for stable and reliable routes. They were using 
it with LQ/ETX and  a sliding window size that was too small and didn't 
know about LinkQualityFishEye.

LinkQualityDjikstraLimit is important in large mesh-networks like Berlin 
on embedded systems - otherwise the CPUs will overheat. But the 
implementation in 0.4.10 is still buggy, I think.

I'd suggest is high time to release a new 'stable' release of olsrd - 
there are too many important bugs in 0.4.10 which have been fixed in 
CVS. Last important one was the limitation of 32 hops max. that causes 
olsrd to crash.

I wrote a short text called 'The olsr-story' for www.open-mesh.net - 
Thomas Lopatic read it and we both think it would be a interesting read 
for people interested in the background of the development at Freifunk. 
It will give people a good insight about our experiences and thoughts 
about olsr.

Some people subscribed to the olsr-mailinglists may also be interested 
in the development of the B.A.T.M.A.N routing-daemon that we started 
after olsr-0.4.10.

B.A.T.M.A.N-III-0.1 binaries and sources will be available from December 
13th at www.open-mesh.net. Let's see how it performs in real life :)

I'm still using olsrd-0.5 pre every day - but I'm looking forward to the 
experiences with B.A.T.M.A.N. Gateway switching is a constant annoyance 
in olsrd when using stateful protocols like IM, VOIP etc.

cu elektra