Important: if you are using Atheros radios (CM9, SR5, etc), please Read This First!
Why is my radio performance poor? What can I do about it?

One of the most common complaints about the mesh system is radio performance.  We have spent many hours researching and testing ways to make our systems better.  However, a majority of the problems at customer locations have been solved by adjusting or repairing components of the hardware installation or changing radio parameters such as power, channel and fragmentation settings.

How can I tell if I have a poor connection?
1.) From a SSH terminal run the program leechtest; This will download a zip file of approximately 10MB size from a server located at Microsoft, through your gateway node, to the current node.  Observe the download speed and then reference the bandwidth settings of your system to see how quickly the system is performing.

For example, running several hops into the mesh you should realistically see transfer speeds of ~200-250 KB/s. Of course this is affected by the load at Microsoft at the time, as well as vfariations in your setup. It's also dependent on whether you're using 900Mhz, 2.4 Ghz, or 5 Ghz radios, but if performance is between, say, 20KB/s - 80KB/s you can assume that the system is not running at top performance.

2.) As of Qorvus Qcode 2.2, you can run the program /hj/qlink_test.  This will download a 1.2MB file from the 1.x.x.x address you specify and will show true performance inside the mesh that is not dependant upon your ISP gateway backhaul link, internet congestion, or Microsoft. You can use this tool through multiple hops, and even through the ethernet port to a remote Qnode. For example, qlink_test will load the file from a node attached to a fiber hub in Washington State (the same one the Stevenson MeshCam is associated with)

3.) On the status page, click on site survey and observe the data rates to the listed access points in the area of your node (this works only with prism radio as of 12/30/2006).  The data rate links can vary between radios.  Also, you may find that there are many other people using wireless systems on the same channel or near by channels with high power settings that could be causing problems with your setup. You may need to experiment with your setup to find the best solution for your installation.

4.) From a SSH terminal, run and review /hj/reporter and observe the data rate, fragmentation, power, channel, and AODV routing table information for proper settings.

5.) Hardware planning can make an important difference in the successful deployment of your mesh. The antenna selection process is important for the link between your other nodes and your clients.  Omni antennas can serve an area immediately near the node however they do not work particularly well from longer distance links.  for 2.4 Ghz, omni radio links under 1 mile in radius should be ok if you have only a few users scattered about, however for longer distance links, or for heavier user loads (over, say, 10 users) the quality diminishes quickly. For longer distance links a directional antenna such as a sector or grid is advised for best performance with perhaps another radio serving as an additional local area wireless access point.

6.) Observe the radio link graphs in the interface status page information. You can access the pages from the status page and then click on the desired interface next to bandwidth data title. (examples below)

http://1.x.x.x:81/cgi-bin/data_br0.cgi or http://1.x.x.x:81/cgi-bin/data_br1.cgi

7.) Double check your antenna connections.  Water can cause major problems with microwave systems if they are not properly setup to handle the elements.

Example of radio links.

1.) This graphs show a system under varying load and weather conditions during a one day test cycle. Note the low ratio of packet retries to the total number of packets transmitted. This has been a very reliable link. This graph is of a system using a directional antenna with 200mW radio and approximately a 10 mile link.

2.) This graph shows a system under light load with minimal packet retries. It is using an omni antenna.


3.) This graph shows a system under light load with a minor disruption to the system caused by weather in the area. Notice the dramatic increase in multiple packet retries. It is using an omni antenna.

4.) This graph shows a system under light load however there are major disruptions to the system caused by interference from many other access points in the area. This problem was solved by switching channels to a less congested channel.  Notice the high ratio of multiple packet retries to total packets transmitted. This problem can also be caused by one or more clients with poor radio signals associating with the node, causing excessive retries, and bringing everyone else's performance down.

It is using an omni antenna.