rebelwireless wrote:This is a fairly common complaint, and tons of people have asked for even an M5 radio with more CPU to handle more clients.
I keep telling people that that the CPU in the Rocket has NOTHING to do with anything really other than running the UI if the radio is in bridge mode.
Now if you have the Rocket M5 in NAT or Router mode then the CPU actually has a bearing on performance as it touches all the packets but if the Radio is in Bridge mode the packets simply bridge from one interface to the other and never see the CPU. The CPU will query the Radio Chip for stats such as clients, and signal levels and such but the CPU is simply working as a control interface to the radio.
When you have a Rocket setup in BRIDGE mode which most people should the CPU has nothing to do with the packets getting BRIDGED from the wireless interface to the Ethernet interface.
Just like with our WISP Switch, the CPU utilization under the the Device/Status page has NOTHING to do with the switch capacity as the CPU is simply there to run the UI/CLI and also run Daemons for SMTP, SNMP, RSTP, LACP, and stats collection but has NOTHING to do with switching capacity.
In fact with the Rocket the CPU is an AR7241 which is connected to another Atheros chip (depending on if it is an M2, M3, or M5) which is the radio.
When in bridge mode CPU and Memory is not really doing much but when it is in NAT or Router mode then the Memory and CPU become important.
There is some CPU usage if using airMAX for the TDMA but that takes little CPU overhead. The problem they really had was the CPU was not fast enough to do what they wanted with TDMA but the CPU was never overloaded. In fact if you set up SNMP to monitor CPU usage on an AP that is in bridge mode the CPU usage is VERY LOW.
However the use of TDMA was primarily use to over come the "Hidden Node" problem but years ago over on UBNT forums I showed people how to get better peak performance without using airMAX.
This is how you do it:
Make sure you enable RTS Threshold on "ALL" client radios and set the value to 1. Do not do this on the AP because the AP can obviously see all the Clients.
WARNING: If you miss just one client radio setting RTS to Enable and to 1 you blow the whole concept.
Now you will actually see slightly better peak through put with airMAX turned OFF but under heavier loads your jitter will be slightly higher.
Also airMAX "sometimes" helps but "sometimes" does worse when you have 1 bad client eating up too much air time, but results very.
How it works:
With RTS Enabled and set to 1 you are telling all clients to ask permission to transmit even 1 bite to the AP.
If the AP is busy it will not respond or say NO to the client so he waits preventing clients from talking on top of each other which was the Hidden Node problem as not all clients can see each others transmissions breaking CSMA and thus talked on top of each other trashing communications for both parties.
I have run my towers both ways and the performance is similar. Since they got most of the bugs worked out I enable airMAX if for no other reason the little graphical bars look cool.
This was another reason why I did not understand the point of Titanium, bigger CPU and more memory = no performance increase if in BRIDGE mode.
And why the hell did you need 1G interface especially on M2 when QAM64 was the limiting factor?
You got better performance with Legacy M2, sectors and RF Armor shield kits and saved $250+ per AP.
With the Titanium M5 you spent $200+ more then you had to add our shield kits anyway and then they suffered like 90% failure rates and NO performance increase.
