[Olsr-dev] Thoughts about an ETX-FF-Metric plugin

[Henning Rogge]

Am Donnerstag 19 Juni 2008 11:30:20 schrieb Markus Kittenberger:
> another approach would be a "exponential" window consisting of values
> representing time slots of increasing duration
>
> position: summary of x seconds
> 01 : 3
> 02 : 3
> 03 : 3
> 04 : 3
> 05 : 6(updated every 6 seconds with average of fields 3,4, so the field
> contains summary of 6..12, 9..12seconds old results)
> 06 : 6
> 07 : 6
> 08 : 12(updated every 12 seconds with average of fields 6,7)
> 09 : 12
> 10 : 12
> 11 : 24(...)
> 12 : 24
> 13 : 24
> 14 : 48(...)
> 15 : 48
> 16 : 48
Interesting idea... at the moment I'm using a ringbuffer (so I have to shift 
the array every times I write a new value), but this might be a good 
sollution too.

> from this 16 values for example the 4 worst values are averaged to wLQ
> all other values are averaged to oLQ
> and the LQ=(wLQ+oLQ)/2
>
> doing so would prefer stable links from instable links (1 minute perfectly,
> then bad, and so on) (i prefer stable/reliable connections)
> while reacting quite fast when an usually stable link becomes very
> instable,.. (in 8 seconds from LQ 1.0 to 0.5)
> and i think the results will not "hard" jump (up) too much,.. (becasue a
> group of bad values will not ever move out from history fastly, instead
> they loose they gradually loose their weight when getting into longer
> timelots) this approach is also immune to changing amounts of olsr
> traffic,..
I'm not sure if I like a LQ measurement that drops the LQ fast but increase it 
slowly... we will just get a lot bad LQ values in the network.

> maybe an even larger or steeper history would be a good idea (the above
> sample is "only" 2,5 minutes)
>
> the parameters of this window would be total length (16 was used above),
> initial slot length (3 seconds), initial slot count (4), exponential slot
> count (3)
ok.

> initialslotlength * initialslotcount >> hello interval (i think 2x hello
> interval (of the neighbour) is quite fine)
> and exponential slot count must be at least 2. (#)
hmm... maybe we could use the "hello-timeout" value here...

> the initial slot length is a bit problematic, having to small intervals
> risks creating bad values (when there is no packet per time slot)
> while making it too large makes results in slower reaction on suddenly dead
> or extremly bad links,..
>
> maybe the first summary function (for field 5 above) should be a bit
> smarter (than just blindy averaging) ##
>
> Markus

> ##
> it could analyze the 2nd or even first field in case of not enough data is
> in fields 3 and 4.
> and the "initial" slots may use two values (lost, received), like in
> hennings latest approach, to enable analysis of data "quality"
> (0:0 would be for surely not enough data to get reasonable results)

The algorithm should work for small networks too... and in small networks you 
have only a few packets per second.

Henning


*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: (spam-protected)
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)