Hey Thomas, On Tue, Feb 19, 2013 at 10:32:29AM +0100, Thomas Hühn wrote: > Hi all, > > You motivate your proposal of collecting several statistics from non-peering stations in IBBS networks with: > (1) "The statistics are then used to evaluate link quality and make some higher level decisions" > & > (2)"reading every packet from this monitor interface has a huge thoughput limitation" > > Could you go into more details about what "higher level" decisions you have in mind ? > Until now you just listed a bunch of values you like to monitor on a per packet level without any concrete usage idea or algorithms that could make use of it. > I could guess that a common goal would be to increase performance in wireless networks, but lets get concrete about the approach you have in mind. > A lot of recent theoretical research in wireless goes towards interference management, multi-user and so the gains of using channel state information as feedback that is worth its overhead. But this direction would question the packet level granularity you described… so what about aggregated statistics ? thanks for your questions, we did not explain this in detail and I think Mathias can give some more background on this, but I'll try to explain: We are currently evaluating some statistics in userspace by collecting packets via the monitor interface. We evaluate sequence number jumps (which indicate packet loss due to interference), signal levels and such to throw this in a model to assess the channel quality. This is used to make routing decisions according to channel qualities within a network (assume a multihop mesh-like network). One problem we see here is that reading and evaluating these packets in userspace is performance, reading every packet just uses a lot of CPU cycles (because of the transfer kernel->userspace and such). Therefore we would like to move this statistics collection into kernelspace, and only retrieve aggregated statistics. So the goal for us to improve performance of the channel assessment we are already doing, and use it for this custom routing software. Maybe other users can use a similar approach on other kinds of routing software, or even completely different tasks I'm currently not aware of (e.g. these 802.11s use cases). Cheers, Simon
Attachment:
signature.asc
Description: Digital signature
