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