[Olsr-dev] OLSRd 0.5.4 and 0.5.5 with ETT available
Thu Nov 13 15:39:43 CET 2008
I think that there are two principle ways of measuring the "quality" of a
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
+ 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
Just my 2 cents...
> -----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
> * the "collision avoidance" issue also has a "reality factor"
> 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?
> 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
More information about the Olsr-dev