<br><br><div><span class="gmail_quote">On 6/18/08, Henning Rogge <<a href="mailto:rogge@fgan.de">rogge@fgan.de</a>> wrote:<br>>I just did another test implementation of the new algorithm, this one with FPM<br>>and with a sliding window (length fixed to 16 seconds) for calculating the<br>
>average (instead of the exponential moving average).<br><br>>Test results or more ideas are welcome.<br><br>another approach would be a "exponential" window consisting of values representing time slots of increasing duration<br>
<br>position: summary of x seconds<br>01 : 3<br>02 : 3 <br>03 : 3<br>04 : 3<br>05 :  6(updated every   6 seconds with average of fields 3,4, so the field contains summary of 6..12, 9..12seconds old results)<br>06 : 6 <br>
07 : 6<br>08 :  12(updated every  12 seconds with average of fields 6,7)<br>09 : 12<br>10 : 12<br>11 :  24(...)<br>12 : 24<br>13 : 24<br>14 :  48(...)<br>15 : 48<br>16 : 48<br><br>from this 16 values for example the 4 worst values are averaged to wLQ<br>
all other values are averaged to oLQ<br>and the LQ=(wLQ+oLQ)/2<br><br>doing so would prefer stable links from instable links (1 minute perfectly, then bad, and so on) (i prefer stable/reliable connections)<br>while reacting quite fast when an usually stable link becomes very instable,.. (in 8 seconds from LQ 1.0 to 0.5)<br>
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)<br>
this approach is also immune to changing amounts of olsr traffic,..<br><br>maybe an even larger or steeper  history would be a good idea (the above sample is "only" 2,5 minutes)<br><br>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)<br>
<br>initialslotlength * initialslotcount >> hello interval (i think 2x hello interval (of the neighbour) is quite fine)<br>and exponential slot count must be at least 2. (#)<br><br>the initial slot length is a bit problematic, having to small intervals risks creating bad values (when there is no packet per time slot)<br>
while making it too large makes results in slower reaction on suddenly dead or extremly bad links,..<br><br>maybe the first summary function (for field 5 above) should be a bit smarter (than just blindy averaging) ##<br></span><span class="gmail_quote"><br>
</span></div>Markus<br><br>#<br><span class="gmail_quote">this   represents the number of values representing the same time slot duration, (before doubling it again)<br>with it you can tune the steepness of history, or you can interprete it as avaerged duration increase between the  Xth and Xth + 1 field in history<br>
2 means 1,41 sqrt(2)<br>3 1,25 = 2^(1/3)<br>4 1,19 = </span><span class="gmail_quote">2^(1/4)</span><span class="gmail_quote"> <br><br></span>##<br><span class="gmail_quote">it could analyze the 2nd or even first field in case of not enough data is in fields 3 and 4.<br>
 and the "initial" slots may use two values (lost, received), like in hennings latest approach, to enable analysis of data "quality"<br>(0:0 would be for surely not enough data to get reasonable results)<br>
</span><span class="gmail_quote"><br></span><br>