[Olsr-dev] Seeking comments: OLSR+ETX v/s DSR+ETX

sebastian sauer (spam-protected)
Fri Dec 21 18:56:47 CET 2007

Fri 21 Dec 2007 13:55, Henning Rogge wrote:
> Am Mittwoch 19 Dezember 2007 15:58:53 schrieb elektra:
> > And btw. I don't see any irrational 'voodoo' in LQ/NLQ/ETX
sorry, i do see it, as far as the LQ is concerned.

( in fact i do not see a LQ, i only saw a loss_link_quality. .-)

> when I looked through the sources of the LQ extension of olsrd 5.4, I noticed
> this formula in the file "src/link_set.c":
> entry->loss_link_quality =
>     (float)(entry->total_packets - entry->lost_packets) /
>     (float)(olsr_cnf->lq_wsize < (2 * 4) ? olsr_cnf->lq_wsize:
>     4 * (((float)olsr_cnf->lq_wsize / 4 - 1) * entry->total_packets +
> olsr_cnf->lq_wsize) / olsr_cnf->lq_wsize);

yeah, this is what i meant, and already discussed in PM, a while ago.

> This looks like "Voodoo", but if you break it down it is the formula:
> lq = (total - lost) / (total + 4 * (cfgwindow - total)/cfgwindow)

IMO it is still the finest of all voodoos. 

> So it's just a formula
yes, and i'm eager to hear any rational explaination for it. plz prove me
as formal as possible why this formula is really justified.

> I propose the formula could be changed to a simple weighted average
> (I use a constant "a" for tuning the formula):
> lq = (total - lost) / (  (total * (a-1) + cfgwindow) / a)

why should it depend on so many config options, which may be even
differnt btwn. my olsrd and my neighbor's?
(who is biasing whom in this case ? .-)

IMO the constraints given by our situation are so unreliable that the
only somewhat sound assummtion with out loss of generality is a 
quasi bernulli-trial. either a packet makes it throu, or not, and
linkquality is the answer to the question: given a integer interval of 
n packets, how may out of all n packets came throu? .. so what is the
probability a packet will make it?

this is basically anyone with some clue is doing in this situation. and
after i saw the voodoo in olsrd i was very pleased that the MIT guys did
it decent, but only olsrd implementation has this voodoo. 


More information about the Olsr-dev mailing list