All,  I've been looking at the Link Quality (LQ) and Estimated Transmission Count (ETX) values and finding they don't seem to be representative of "common understanding" reality and don't compare to, for example, the results from a ping.   Granted, this issue may not be a problem as the current #s may work perfectly fine to calculate the best routing paths.  But it bugs me.  Here's a write up of my investigation to tune olsrd parameters in case this bugs you as well.  

The source code of olsrd is using a weighted exponential moving average.   The default olsrd parameter for this weighting is "HysScaling" and a value of "0.5".  The default HelloInterval is 2 seconds.  

This translates to a weighting that only makes significant (~98%) the last 6 packets in 12 seconds to base route decisions on.   The most recently received HELLO packet, if missed, would instantly drop the LQ down 50%, 2 missing in a row, down 75% and close to the threshold to drop the node out of the route table.

The weighting looks like this (add up the values for which of the last 6 hello packets were received to determine LQ):

I'm putting in a HysScaling value of "0.1" to see if LQ and ETX values are better representative.   The 0.5 value may be better for mobile nodes with dynamic environments to better compensate.  But our nodes here in Southern CA are fixed based and LQ should not change so rapidly.   For a weight scaler of "0.1" the route decision (~98%) would be based on the prior 40 packets over 80 seconds.  The first 6 look like this (smoothing further over time):

The weighting value is determined =x(1-x)^i, where x=HysScaling value 0>1, and i is 0, 1,...

This is the theory.  Feel free to shot holes in this, I'd rather not be going down a bogus path and not know it...

Joe AE6XE

Under the hood of olsr...

After further research into this and looking under the hood in 1.1.x BBHN release, it is a different ball game from my first post. Introduced in the 1.1.x release is Device to Device (DtD) bridging of nodes with a cat5 network cable. This requires usage of the "ffeth" Link Quality (LQ) algorithm which is incompatible with prior methods. "ffeth" was added to handle ETX values < 1. '1' is considered a perfect RF link and this algorithm uses '0.1' value for ethernet links.

Trivia: ffeth = Funkfeuer/Freifunk (the guys that wrote the implementation) + ethernet support in olsr

So what is the algorithm used to determine Link Quality (LQ) which is used to calculate Expected Transmission Count (ETX)?

Short answer: The % of the last 32 Hello packets received from a node (in ~64 seconds) + bias due to several packets lost in a row (link may have dropped so don't wait ~40 secs before declaring it dead)

Long answer: here's the code :) :

/* calculate link quality */

/* LQ_FFETH_WINDOW = 32 */

/* lq.valueLq = 255 is 100% LQ and 0 is 0% LQ */

244 if (total == 0) {

245 tlq->lq.valueLq = 0;

246 } else {

247 // start with link-loss-factor

248 ratio = fpmidiv(itofpm(link->loss_link_multiplier), LINK_LOSS_MULTIPLIER);

249

250 /* keep missed hello periods in mind (round up hello interval to seconds) */

251 if (tlq->missed_hellos > 1) {

252 received = received - received * tlq->missed_hellos * link->inter->hello_etime/1000 / LQ_FFETH_WINDOW;

253 }

254

255 // calculate received/total factor

256 ratio = fpmmuli(ratio, received);

257 ratio = fpmidiv(ratio, total);

258 ratio = fpmmuli(ratio, 255);

259

260 tlq->lq.valueLq = (uint8_t) (fpmtoi(ratio));

261 }

262

263 /* ethernet booster */

264 if (link->inter->mode == IF_MODE_ETHER) {

265 if (tlq->lq.valueLq > (uint8_t)(0.95 *

255)) {

266 tlq->perfect_eth = true;

267 }

268 else if (tlq->lq.valueLq > (uint8_t)(0.90 * 255)) {

269 tlq->perfect_eth = false;

270 }

271

272 if (tlq->perfect_eth) {

273 tlq->lq.valueLq = 255;

274 }

275 }

276 else if (link->inter->mode != IF_MODE_ETHER && tlq->lq.valueLq > 0) {

277 tlq->lq.valueLq--;

278 }