[Olsr-dev] Bug in function olsr_tc_update_edge ?

[Hannes Gredler]

sebastian,

did i miss the patch in your email ?

/hannes

sebastian wrote:
> 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.