[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