[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.
cheers,
s.
More information about the Olsr-dev
mailing list