[Olsr-dev] OLSRd 0.6.0 with ETT available

Teco Boot (spam-protected)
Tue Oct 5 11:32:27 CEST 2010


Hi Erik,

I'll re-evaluate this.

We updated old version a bit:
 - add more bandwidth values
 - added hysteresis
 - speed up convergence
These made the plugin more useful.
I'll get updated this version and send patches later on.

I have some ideas to improve the concept. To list a few:
 - remove distinct data rate values completely
 - use first measurements instead of (possibly very wrong) default
 - auto-calibrate RSSI. This implies passive probing.
 - combine measured cost with ETX

Can we transform this to a lq-lc plugin? 
Then, add this in the repository?

Thanks, Teco



Op 1 okt 2010, om 08:45 heeft Erik Tromp het volgende geschreven:

> 
>> 
>> Van: Henning Rogge [mailto:(spam-protected)] 
>> Verzonden: donderdag 30 september 2010 17:22
>> Aan: (spam-protected)
>> CC: Erik Tromp; 'Henning Rogge'
>> Onderwerp: Re: [Olsr-dev] OLSRd 0.6.0 with ETT available
>> 
>> 1.) The OLSR RFC says "every OLSR message have to be 4 byte aligned".
>> 
>> 2.) If you have unaligned fields within your message, you might get
> trouble.
>> 
>> 3.) If you have unaligned LENGTH all messages after you in the same packet
>> will have trouble. The more recent OLSR code will just drop all messages
> with
>> an odd length.
>> 
>> 4.) ARM_NO_WARN_ALIGN is mostly for byte-arrays... or for cases where we
> know
>> more than the compiler.
>> 
>> Henning Rogge
> 
> 
> Ok, so no ARM/MIPS cpu crash :-)
> 
> B.t.w., are you sure about point 1.) ? I cannot seem to find your quote
> ("every OLSR message have to be 4 byte aligned") anywhere in RFC 3626 .
> In fact I cannot even find the any form of the word "align" in the RFC ...
> 
> Point 2.): what trouble? Current RFC-compliant packets already have
> unaligned
> fields, see e.g. Htime and Willingness in par. 6.1 ("HELLO Message Format").
> 
> About point 3.): I removed this check in the OLSR-LC code.
> 
> Anyway, never mind: I will update the code. 32-bit alignment seems to
> be ... better. But then again, one could reason that 64-bits alignment
> would be 'even more better' for the future.
> 
> Best Regards,
> Erik
> 
> 
> 
> 
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev





More information about the Olsr-dev mailing list