[Olsr-dev] Bug in function olsr_tc_update_edge ?

[sebastian]

hi,

Tue 19 Feb 2008 14:31, Henning Rogge wrote:
> Am Dienstag 19 Februar 2008 11:40:37 schrieb sebastian sauer:
> > hell, yes :) i would even say it's a bunch of correctness issues, and
> > hennig may have a different opinion than i but i disagree that the ETX/LQ
> > in the MIT paper suffers from the same correctness issues.
> > it's just us.
> Do you have an argument for this oppinion except "I think so" ?
an argument from /me beyond, "i think so" !? .-)
ummh, well math is just another service we try to offer, how about that:

| Kauffman, Louis: What is a Number?
| http://www.math.uic.edu/~kauffman/NUM.html

> Last time we discussed this I quoted the paper and you did not reply...
a/ i do not have enough time for almost braindead discussions, esp.
since anyone not brain-dead does it right ..
cf. "RATIO OBSERVED/PREDICTED NUMBER OF OBSERVATIONS"
http://www.epncb.oma.be/_trackingnetwork/qualityplots/yearlyratio.php?station=GSR1_14501M001&beginyear=2008&endyear=2008

b/ there's nothing wrong with the paper. it's the olsrd implementation
that is broken *in*my*opinion*.

c/ the olsrd implementation *in*your*opinion* AFAIK, which is okay too,
since with the proper config parameter, it's indeed mostly fine. (well,
at least if you apply the usual pragmatism of a coding programmer)
(but nothing prevents the naive olsr user from using config parameters
that make the it problematic from the formal point of view.)

(side-note: the olsrd implementation is also inefficent and overly
complex. and hides the actual statistical problem from the knowlegdable
eye.)

d/ e.g. ever wondered why in applied science you damn want a normalizable
wave-function? ..and why you usually 1-normalize the probability density?
cf.: http://en.wikipedia.org/wiki/Normalisable_wave_function
http://en.wikipedia.org/wiki/Probability_density_function#Simplified_explanation

> Just to do it again:
just a quick question, is the stuff from the paper *you* quote here
really that relevant?

.. esp. since we deal with the OLSR protocol?
(http://www.ietf.org/rfc/rfc3626.txt, 3.5. Message Emission and Jitter)


> See "3.1 Metric":
> (http://pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf)
> > ETX = 1 / (df * dr)
> >
> > The delivery ratios df and dr are measured using deticated link probe
> > packets. Each node broadcasts link probes of a  fixed size, at an average
> > period r (one second in the implementation). To avoid accidental
> > synchronization, r is jittered by up to +-0.1r per probe. Because the probes
..so you don not like the OLSR jitter, or what exactly are you trying to
convey here, by quoting this part!?

> > are broadcast, 802.11b does not acknowledge or retransmit them. Every node
> > remembers the probes it receives during the last w seconds (ten seconds in
> > our implementation), allowing it to calculate the delivery ratio from the
> > sender at any time t as:
> >
> > r(t) = count(t-w,t) / (w/r)

..well, and from the very same paper:
| Count(t − w, t) is the number of probes received during the win-
| dow w, and w/τ is the number of probes that should have been
| received.

> 
> The MIT paper states that all nodes use a fixed period r and a constant 
> timewindow "w" for ETX calculations...
..well the view out of the window is left an excercise for the reader ;)
esp. now that we aggree on how it should be done.

SCNR.


you may flame away now, EOF as far as /me is concerned,
s.
-- 
  ever tried. ever failed.
  no matter.
  try again. fail again.
  fail better.
                          (Samuel Becket)