[olsr-dev] Status olsrd-0.4.10

[onelektra]

Hi -

apart from the issues with the HTTP plugin 0.4.10 cvs should be ready to 
go on linux machines, as far as I was told from Thomas.

I'm confident the LQ fisheye mechanism will improve olsrd a lot, like 
ETX did. It is likely that the succession of TTL values that is 
hardcoded at the moment will benefit from some tweaking based on 
experiences we'll gather when LQ-fisheye will be in use on bigger meshes 
than the local testbed.

There is not much left from the INRIA ideas in olsrd as far as the 
Berlin mesh is concerned. We dropped hysteresis and replaced it with 
ETX. We dropped MPRs in Berlin, too - by now we are telling every node 
that it is a MPR. I suggest we'd better go for an option to switch off 
MPRs and MPRs messages completely. Every node should forward TCs as long 
as the TTL of the TC is valid. This is nothing new - it is the fisheye 
algorithm that was available in mobilemesh several years ago. I believe 
it is superior to MPRs regarding CPU overhead and routing loops.

MPR information is a unneccesary message class in my opinion. A network 
with lossy links needs redundancy to keep information in sync on a local 
level. Adding another message class increases the headaches by 
introducing another source of failure that must be kept in sync.

Like I wrote in previous posts there is no need to have routing 
information in sync in every node for the whole mesh. This is only 
useful for source routing. In fact a node needs only a vague idea what 
is going on 6 hops away and can trust the information of nodes that are 
nearer to a distant destination. A node needs to know who is out there 
and in which direction. It should have decent information abould 
adjacent nodes.

Thus, I believe by using the fisheye mechanism we can reduce CPU 
overhead and gain stability. In a huge mesh with 250 routes TC messages 
arrive every 1 or 2 milliseconds because they are forwarded all the time.

TC messages that have their origin several hops away have a lot of 
packet loss until they reach the oppposite end of the mesh cloud. That's 
fine as long as a few TC messages make their way and their validity time 
is long enough.

Of course there is no guarantee that I'm right. But the feeling in my 
stomach says: Go for it! ;-)

Btw: There is a nice 4-page article about olsrd and the Berlin mesh in 
the isssue of the german c't-magazin that was published this week.

It would be nice to announce 0.4.10 before christmas and do a press 
release. I would volunteer to write it in english and german.

But with all the recent changes it is hard to claim it is still olsr...
;-)


cu elektra

> We have a release candidate ready, but we are still awaiting verification
> from use on various OSes. I hope we can have it ready before Christmas.
> 
> (hmmm... perhaps the internal buffersize of the HTTP plugin should be user
> configureable...)
> 
> - Andreas
> 
> 
>>Hey,
>>
>>what's the status of the release? We now have 250~280 routes in the berlin
>>mesh and experience some probs. I would like to deplay a fixed version,
>>because:
>>
>>- httpinfo-plugin uses fixed buffer too small for that route count
>>- we would like to give the fisheye routing feature a chance
>>
>>LG, Sven-Ola
>>
>>
>>_______________________________________________
>>olsr-dev mailing list
>>(spam-protected)
>>https://www.olsr.org/mailman/listinfo/olsr-dev
>>
> 
> 
> 
> 
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
> 
>