[Olsr-users] Calculating LQ in 0.5.0 (Was: olsrd-0.5.0: LQ
Mon Aug 27 13:33:37 CEST 2007
you are right. The formula has a design flaw if you use (LinkQualitySize %
4) != 0. Because we're practical guys, nobody uses such a window size for
obvious reasons. Common values are 32, 100 or 128. For example, if you use
LQW = 111, I'm not 100% sure if the loss_bitmap stuff is correctly
implemented. So I would use something with 0 == (lqw % 8) anyhow.
By coincidence, I was seeking a bug in the txtinfo plugin this weekend.
Every here and then, the txtinfo output shows an LQ/NLQ value of 0.0 for
unknown reason. Vanished if you grab it's output a second later. Possibly
the mentioned float-to-integer clipping while serializing the lq-packet due
to libmath-float-rounding-errors..? I recommend the attached changes.
"Alexey Shinkin" <(spam-protected)> schrieb im Newsbeitrag
Maybe would be better to post this to developers as well ... but I thought
this could be interesting for users.
Sven-Ola's “slow-start LinkQualityWinSize” has a nasty side effect , I’m a
bit surprised it hasn’t been noticed yet .
(even by practical guys … ).
While LQ=(total-lost)/window_size all seems ok .
As we gather enough packets , LQ = (total-lost)/super_optimized_stuff and
it starts to be greater than 1.0
(in good link condition).
Now guess what happens if you scale such LQ (yeah, multiply this by 255 and
cast to unsigned char!)
and send it to neighbors via LQ HELLO message ;)
Right, they’ll got NLQ slightly more than 0 !
Even funnier, they’ll return that NLQ to you with TC , you’ll see your own
LQ>1.0 in Links section and ~0 in Topology !
Simply clipping LQ to 1.0 solves the problem .
Change is good. See what’s different about Windows Live Hotmail. Check it
Olsr-users mailing list
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2055 bytes
Desc: not available
More information about the Olsr-users