On Thu, 2008-11-13 at 15:39 +0100, Erik Tromp wrote:
> 
> 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.):
JftSoC: Disadvantages of 1.):

> - 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
Yes, but such stuff plain simply belongs into a kernel - especially if
it comes to layer 1 and 2 monitoring. BTW perhaps a BPF/LPF or iptables
can reduce the amount of userspace interaction.

> - 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
Given sane environments, at least the exported data on one OS should be
consistent and the API too (no, I don't consider having an ioctl() per
WLAN driver which delivers hardware-specific byte blobs a "sane
environment". But even that is better than nothing (read: as of now).
And it has the virtue of being "OS-independent" - at least in some
way ...).
Having an OS-dependent (or driver/hardware-dependent) "import" of
statistics date is IMHO not really an issue.

> difficult to determine the "quality" based on only these metrics.

> Advantages of 2.):
> + Permanent monitoring of quality is possible, even in low-traffic
> circumstances.
s/even/only/ - and it sucks on high-traffic situations.
For too-low-traffic situations, perhaps the "measuring entity" can
generate pseudo-traffic to end the too-low-traffic situations?

> + 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
Another problem is that with too many antennas in the same collision
domain, the probability of collisions rises more then linear.
Perhaps that's an non-issue in rural areas but some people are living in
real cities. Seeing half dozen WLAN networks is nothing special in
Vienna.

> 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)
If it comes to VoIP, you want probably these.

> Or maybe even things like:
> - used energy (joule)
> - power (watt)
> - battery drain (percentage)
> - humanly percieved quality :P
That's the only really interesting. But it's hard to find one definition
for it most of the people agree with ...;-)
> - etc.
> 
> Just my 2 cents...
and mine ....

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




