September 2011

Laboratory limitations as of 17.08.2011.

Test parameters:
  • IEEE 802.11 a/g operation with 20MHz-wide channels
  • wireless frequency separation between interfaces >= 40MHz
  • fixed 54 Mbps bitrate
  • disabled WiFi ACK mechanism
  • "packet" command (see iitis-generator-traffic(5))
Observed statistics:
  • snt_err: number of frame send errors; counter is increased when wireless driver queue is full; this is interpreted as a symptom of a busy transmission medium
  • internal-stats/scheduler_lag: number of events that were handled too late; this is interpreted as a high CPU load
  • snt_ok vs remote rcv_ok and rcv_lost: verification of the number of frames that were successfully delivered
Test results:
  1. Transmission medium accessed via single wireless interface saturates at some packet rate, what depends on frame length. Stable maximum packet rates for single channel are:
    • ~3500 pps for 100B frames
    • ~2100 pps for 1500B frames
  2. Node CPU saturates at some packet rate, taken as aggregate of all its wireless interfaces. Stable maximum packet rates for all channels aggregated are:
    • only receiving:
      • ~10500 pps for 100B frames
      • ~6300 pps for 1500B frames
    • only transmitting:
      • >8000 pps for 100B frames
        • ~10500pps can be achieved using the "burst" option of the "packet" command, e.g. by sending on each interface 35 packets in burst each 10 ms
      • ~6300 pps for 1500B frames
  3. As result, at most 9.3MB/s (~74Mbps) can be delivered to a single node through 3 channels, 3.1MB/s (~25Mbps) each.

Currently, the only significant limitations due to CPU power is during transmission of small frames, and this can probably be fixed by improving the event scheduler (as revealed by the usage of "burst"). However, CPU is highly loaded anyway when attaining the other limits, e.g. during frame reception. Without a thorough research, space for improvement is in the field of architecture of the whole system (driver + kernel + iitis-generator), rather than in the field of source code optimization.

Observed transmission medium limitations need to be further analyzed. Point of observation for this phenomenon is the length of wireless interface queue. An assumption is made, that the queue shrinks as fast as possible, that is, as fast as the underlying medium permits for this (maximum queue length is 123 packets, as defined in ath9k source code).

However, a medium capable of 54Mbps has been used, and less than 50% of this has been achieved. This is not caused by the need to acknowledge the packets, as in a typical real-world TCP transfer. Space for improvement is probably the packet injection facility of the Linux mac80211 subsystem.