[Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available

[Erik Tromp]

Sorry, typo:
 
Disadvantages of 2.):
- links that carry hardly any traffic are difficult to ...

should be:

Disadvantages of 1.):
- links that carry hardly any traffic are difficult to ...



> -----Oorspronkelijk bericht-----
> Van: (spam-protected) 
> [mailto:(spam-protected)] Namens Erik Tromp
> Verzonden: donderdag 13 november 2008 15:40
> Aan: 'Daniel Nitzpon'; (spam-protected)
> Onderwerp: Re: [Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available
> 
> 
> 
> I think that there are two principle ways of measuring the 
> "quality" of a
> link:
> 
> 1.) Passively, by monitoring the "quality" of the incoming packets.
> 
> 2.) Actively, by sending specially formed probe packets and 
> monitoring the "quality" of the probe packets.
> 
> Advantages of 1.):
> + No extra air time
> 
> Disadvantages of 2.):
> - links that carry hardly any traffic are difficult to 
> measure (as Daniel points out "you may never discover a 
> better alternative route due to lack of measurements on it")
> - Tapping all traffic into user space for analysis by a 
> user-space process causes a high CPU load
> - Alternatively, if tapping is not used, there is a dependcy 
> on non-standard interfaces to retrieve metrics such as 
> Layer-1 or -2 metrics (radio signal strength, number of 
> retransmissions at the MAC layer, etc.) Besides, it is 
> difficult to determine the "quality" based on only these metrics.
> 
> Advantages of 2.):
> + Permanent monitoring of quality is possible, even in low-traffic
> circumstances.
> + Low CPU load because only the probe packets are processed (socket 
> + selects
> in kernel space)
> + No dependency on non-standard interfaces
> 
> Disadvantages of 2.):
> - Requires extra air time
> 
> 
> Additional issue: what is "quality"? There are various 
> possibilities here:
> - 'specified' link speed (bit/sec) e.g. 1, 2, 5.5, 11, 54, 
> 300 Mbit/sec
> - effective throughput (bit/sec) (my personal favourite :-)
> - latency, jitter, air time (sec)
> Or maybe even things like:
> - used energy (joule)
> - power (watt)
> - battery drain (percentage)
> - humanly percieved quality :P
> - etc.
> 
> Just my 2 cents...
> 
> Erik
> 
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: (spam-protected)
> > [mailto:(spam-protected)] Namens Daniel Nitzpon
> > Verzonden: donderdag 13 november 2008 13:49
> > Aan: (spam-protected)
> > Onderwerp: Re: [Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available
> > 
> > hmmm..  i don't have an easy solution here...
> > 
> > but i wonder how you intend to deal with the underlying issues in 
> > other
> > algorithms:
> > 
> > * the "collision avoidance" issue also has a "reality factor" 
> > built-in: 
> > if you only consider the speed of a link during times on 
> which airtime 
> > for this link is available, you will end up extremely over-rating 
> > links on which generally little airtime is available.
> > 
> > * if you circumvent the "unicast traffic" issue, by only measuring 
> > existing unicast traffic you may never discover a better 
> alternative 
> > route due to lack of measurements on it.
> > as lots of real-world scenarios have little peer-to-peer-traffic 
> > (almost all unicast goes to the next internet-gateway and back), it 
> > may be a real problem, not just an academic one.
> > 
> > in how far do you consider these issues "issues"? any solutions in 
> > sight?
> > 
> > greetz,
> > daniel
> > 
> > Henning Rogge schrieb:
> > > Am Thursday 13 November 2008 09:59:55 schrieb Daniel Nitzpon:
> > > 
> > >  > what about the mechanism with measuring timing of deliberate 
> > > small/large
> > > 
> > >  > IP-packets? why did you drop this version?
> > > 
> > > There are two problems with packet-pairs...
> > > 
> > > first, WLAN is a "collision avoidance" medium, so WLAN 
> drivers may 
> > > wait for a longer time until they start to send the 
> package (longer 
> > > than the whole transmission will take). This waiting time is 
> > > independant for each package.
> > > 
> > > second, the time delay in the operation system between kernel and 
> > > userspace is sometimes larger than the WLAN transmission time too.
> > > 
> > > Maybe you could make packet-pair work by using radiotap 
> header for 
> > > sender AND receiver (so you know the exact times), but if 
> you have 
> > > enough CPU power for radiotap you don't need packet-pairs.
> > > 
> > > But the most important problem with bandwith measurements
> > is that you
> > > can only measure bandwith if there is traffic on the link. 
> > So you have
> > > to spam unicast packages to each of your neighbors and
> > waste lots of
> > > airtime.
> > > 
> > > Henning
> > > 
> > > *************************************************
> > > 
> > > Diplom Informatiker Henning Rogge
> > > 
> > > Forschungsgesellschaft für
> > > 
> > > Angewandte Naturwissenschaften e. V. (FGAN)
> > > 
> > > Neuenahrer Str. 20, 53343 Wachtberg, Germany
> > > 
> > > Tel.: 0049 (0)228 9435-961
> > > 
> > > Fax: 0049 (0)228 9435-685
> > > 
> > > E-Mail: (spam-protected)
> > > 
> > > Web: www.fgan.de
> > > 
> > > ************************************************
> > > 
> > > Sitz der Gesellschaft: Bonn
> > > 
> > > Registergericht: Amtsgericht Bonn VR 2530
> > > 
> > > Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. 
> > Joachim Ender
> > > (Stellv.)
> > > 
> > 
> > --
> > Olsr-dev mailing list
> > (spam-protected)
> > http://lists.olsr.org/mailman/listinfo/olsr-dev
> > 
> 
> 
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev
>