5

I'm preparing for a load test of a classroom wifi system. The pupils all turn on their laptops at the start of the lesson, which launches the web browser and then they start the lesson - which involves downloading a flash based lesson (from a server within the school), generally half to 2 MB download.

In some cases, the load time is stretching to 5 or 10 minutes. So I want to monitor all parts of the system to say with confidence where the bottlenecks are, and how many clients can use a single wifi access point reasonably. So we are planning to run tests with up to 50 clients and see what happens (I know that most people recommend 20-25 clients per access point, but the client wants to test this - and I want to get good data to show the client one way or another).

I already know how to monitor the server. The wifi access point supports SNMP, and seems to provide quite a lot of variables, but I don't want to have to wade through too much.

So the question is, what wifi-related variables are the key ones to monitor to characterise when the system is getting overloaded, clients are waiting, collisions are happening etc?

I'm happy to be told the generic names for what should be there and hunt through the files myself, but if you want/need to see the details, then the access point we are using is the Ubiquity Nanostation 2. The MIB files for Ubiquity products are linked from the bottom of their SNMP page. Though I also found that they seem to support at least part of the Mikrotik MIB.

Hamish Downer
  • 9,142
  • 6
  • 36
  • 49

2 Answers2

4

If all you are trying to do is prove to the client that they are overloading the AP, you can use the dot11RetryCount and dot11MultipleRetryCount OID's.

dot11RetryCount - 1.2.840.10036.2.2.1.4

dot11MultipleRetryCount - 1.2.840.10036.2.2.1.5

This will give you a rough estimate of how congested the air is. Once the Retry count reaches more than about 10% of the dot11TransmittedFrameCount, you will start to see slowdowns.

Here's Cisco's MIB object walker - that should help if you need to figure out other OID's to examine.

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.2.840.10036.2.2.1.13#oidContent

smithian
  • 1,746
  • 14
  • 15
2

The simple approach would be just monitoring the IF-MIB::ifInOctets.<ifIndex> / IF-MIB::ifOutOctets.<ifIndex> OIDs periodically and checking against the available bandwidth. From your linked MikroTik MIB you can discover the currently set rates by reading the mtxrWlStatTxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex> and mtxrWlStatRxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex>. This of course would not take wireless specifics into account, but be able to give you a rough idea if the total available bandwidth on your interface is the bottleneck (it likely is if you see usages near the total channel capacity).

In general, unless your stations or antennae are located poorly and the ether is clean at the chosen channel's frequency, you can expect a throughput of roughly 2-3 MB/s from a single G-channel (54 MBps 2,4 GHz).

If you need more specific information on retries and errors from the AP side, you can read the dot11Counters table of the IEEE802dot11 MIB - specifically the dot11RetryCount, dot11MultipleRetryCount and dot11FailedCount values of the appropriate instance.

802.11 does not have any collisions but physical carrier sensing and optionally an RTS/CTS handshake prior to transmission of frames. Monitoring the dot11RTSFailureCount will give you a rough idea of how often an RTS request is not replied by a CTS, thus not granting the channel to the sending station.

Note that you may see a relatively low amount of retries and RTS failures if it is your access point generating the vast majority of the traffic (i.e. the stations are mainly receiving data). You might want to take a look at IF-MIB::ifOutDiscards.<ifIndex> at the wireless interface or IF-MIB::ifInDiscards.<ifIndex> at the wired interface as well as these numbers would increment whenever the buffer is full and cannot receive any additional frames (i.e. the AP is sending at full rate but frames at the Ethernet interface keep arriving at a faster rate).

the-wabbit
  • 40,319
  • 13
  • 105
  • 169