Capacity of a UBNT AP vs the number of clients

Almost all the time I get asked: “How many clients can an AP handle?” . My answer is always a very long and drawn out one. There is no set in stone answer. There are many factors which can affect this. I will go into some of these and then explain how to calculate this.

Some things that we will assume.
1.You are calculating on an 802.11N Ap with some kind of polling (TDMA, NSTREME, AIRMAX, etc)
2.You know the MCS values and/or data rates at channel widths.
3.When I say in an ideal situation I mean basically in the lab. This is our baseline. This means no outside noise, everything is working properly, and all the connected clients are excellent.

Before I get into what affects how many clients can an AP handle we need to shift our thinking a little. We don’t think in terms of how many clients can an AP handle. We need to think in terms of how much capacity an AP has. This is very important to think in these terms. If you do so things will become more clear and more quantifiable.

So now, on to what affects the total capacity of an AP.

1.The channel width. In and ideal situation you will get more Capacity out of a 20 mhz channel than you will a 10mhz channel.
2.Noise. In the real world you will have interference. If you have interference the noise floor drops, customer signals can’t reach maximum modulation, and there are retransmits.
3.Plain old signal. Things such as trees, distance, fresnel zone, and antenna gain all affect signal
4.The speed you are giving to each customer.
5.Overselling. The concept of overselling has been around since the dial-up days. You are betting your customers are not all online at the same exact time doing the exact same stuff. So you can oversell your capacity. I will explain this a little more in a bit how this factors in.

Okay, so let’s dive into this. I am going to use a Ubiquity Rocket M5 as an example. Again, this can be applied to any polling type N radio.

Say we have a Rocket M5. At a 20MHZ channel the best modulation this M5 will do is MCS 15 at 130 Megs of over the air. What do you mean Over the Air? Well there is a difference between actual throughput and the Wireless Data Rate (aka over the air). Your actual throughput/capacity will be 1/2 of the over the air rate minus a little for overhead. I factor in 10% overhead for easy figuring.

Back to our figuring. You have 130 megs of capacity on your AP in an ideal situation on a 20 mhz channel. If we do our math:
130 / 2 = 65 Megs of Capacity to sell on the AP.
Now here comes the overselling part.
If we oversell at a 2:1 ratio we have 130 Megs of capacity on the AP.
If we oversell at a 3:1 ratio we have 195 megs of capacity on the AP.

We can do higher ratios, but it starts to become a moving target. With the spread of Netflix, Youtube, Hulu, and other streaming services the average customer is sucking down more and more bandwidth for longer periods of time. Think of a restaurant with so many tables. If your customers are staying longer and longer, you don’t have as much seating capacity to turn over for new people to sit down and consume your food. This is for another blog post.

So, let’s say we are overselling at 3:1. We have 195 megs of capacity. We now need to think about what packages we are selling to our customers. If they are all say 5 meg packages, this means we can safely sell 39 connections to the AP. 195 / 5 = 39. You can figure up the math if you have 3 Meg, 10 meg, or a mixture.

Now to the real world (aka why do my customers hate me and my AP sucks?).

The following is a real AP in the wild.  Blacked out to protect the innocent from script kiddies.

Couple of things to Note (circled in Red).

20 MHZ Channel
Capacity at 45% . This is more important than anything, even CCQ.
43 clients associated.

Let’s apply our math we learned earlier. We know a 20 mhz channel nets us MCS15 – 130 Megs

Here is the kicker.  Our capacity is at 45%.  This means we only have 45% of 130 megs of Over the air capacity.  Take this in half (130 / 2= 65   45% of 65 = 29.25.
This means all 43 of these customers are sharing 29 megs of capacity on the AP.  And the quality isn’t the greatest (37%).  So this means there are retransmissions going on between the client and the AP. The client can’t talk as fast as it is capable of in most cases. This means you can’t oversell the AP as much due to the quality of the signals being poor.  It is important to note I am talking about the quality and capacity of the signals, not signal strengths.

If those 43 people are all paying for, let’s say, 2 Megs download.  That means your AP needs to support a minimum of 86 megs. Thats without overselling.  We only have 29 megs in the current state!

We need to get those capacity numbers up.  How do we do that?

1. Channel selection. A noisy channel will drag everyone down.

2. Antenna gain.  This can be done at both the client and the AP.  A higher gain or better quality antenna can cause the clients to “hear” better.  You might not get an increase in signal strengths, but you are looking for an increase in quality. I use a loudspeaker metaphor.  You can hear a loudspeaker from a far distance, but you might not always be able to make out what is being said.  If you can somehow make out what is being said more clearly, then you don’t have to have the speaker turn up the volume.

3. Shielding. This helps eliminate the amount of stuff a client or AP hears.

4. Channel Width.  Sometimes dropping the channel width down can increase signals, thus raising the overall capacity.  Keep in mind it will lessen the overall capacity of the AP.

5.Simply getting rid of customers that shouldn’t be installed.  We have all done installs that were iffy.  These can drag down the overall capacity.

I hope this has helped understand.  The biggest thing I want you all to take away from this is think in terms of the amount of capacity you have to sell, not the number of connections.



MTIN Services

WISP and Wireline/Fiber Design and Operation

MPLS Design and Implementation

Multicast Routing IGMP, PIM

eBGP/iBGP design/implementation

Cisco Routers 2800, 3600, 7200, 7600, ASR, ISR

Cisco Switches 2950, 3550, 3560, 3750, 6500

Switching (Layer 2) STP, RSTP, EOIP, MSTP, VLAN – dot1q and q-in-q

Routing (layer 3) OSPF, BGP, MPLS, L2VPN

Policy Based Routing, Routing Redistribution, Route Reflection, Failover

Cisco Firewalls

Mikrotik 450, 493, 750, RB1100, RB1200, RB2011, CCR, Cloud Core Switches

Ubiquity Products

Ruckus Wireless

Alvarion WiMAX

Tandberg Multiplexers and Encoders

IPTV Products – ADB, Entone, Avail

Asterisk SIP PBX

MTIN becomes CLoudFlare Partner

This is a guest post written and contributed by CloudFlare.  CloudFlare makes it easy for any site to be as fast and secure as the Internet giants.

CloudFlare, a web performance and security company, is excited to announce our partnership with MTIN Consulting If you haven’t heard about CloudFlare before, our value proposition is simple: we’ll make any website twice as fast and protect it from a broad range of web threats.

Today, hundreds of thousands of websites—ranging from individual blogs to e-commerce sites to the websites of Fortune 500 companies to national governments—use CloudFlare to make their sites faster and more secure. We power more than 65 billion monthly page views—more than Amazon, Wikipedia, Twitter, Zynga, AOL, Apple, Bing, eBay, PayPal and Instagram combined—and over 25% of the Internet’s population regularly passes through our network.

Faster web performance

CloudFlare is designed to take a great hosting platform like MTIN’s and make it even better.

We run 23 data centers strategically located around the world. When you sign up for CloudFlare, we begin routing your traffic to the nearest data center.

As your traffic passes through the data centers, we intelligently determine what parts of your website are static versus dynamic. The static portions are cached on our servers for a short period of time, typically less than 2 hours before we check to see if they’ve been updated. By automatically moving the static parts of your site closer to your visitors, the overall performance of your site improves significantly.

CloudFlare’s intelligent caching system also means you save bandwidth, which means saving money, and decreases the load on your servers, which means your web application will run faster and more efficiently than ever. On average, CloudFlare customers see a 60% decrease in bandwidth usage, and a 65% in total requests to their servers. The overall effect is that CloudFlare will typically cut the load time for pages on your site by 50% which means higher engagement and happier visitors.

Broad web security

Over the course of 2011, CloudFlare identified a 700% increase in the number of distributed denial of service attacks (DDoS) we track on the Internet (see the chart below). As attacks like these increase, CloudFlare is stepping up to protect sites.

CloudFlare’s security protections offer a broad range of protections against attacks such as DDoS, hacking or spam submitted to a blog or comment form. What is powerful about our approach is that the system gets smarter the more sites that are part of the CloudFlare community. We analyze the traffic patterns of hundreds of millions of visitors in real time and adapt the security systems to ensure good traffic gets through and bad traffic is stopped.

In time, our goal is nothing short of making attacks against websites a relic of history. And, given our scale and the billions of different attacks we see and adapt to every year, we’re well on our way to achieving that for sites on the CloudFlare network.

Signing up

Any website can deploy CloudFlare, regardless of your underlying platform. By integrating closely with MTIN we make the process of setting up CloudFlare “1 click easy” through your existing MTIN dashboard. Just look for the CloudFlare icon, choose the domain you want to enable, and click the orange cloud. That’s it!

We’ve kept the price as low as possible and plans offered through MTIN are free. Moreover, we never charge you for bandwidth or storage, therefore saving you tons via reduced bandwidth costs.

MTIN Spam Filtering for your domain

$15 per month Contact MTIN for more details

Outperforms the competition
We catch more spam and do it with substantially fewer false positives than other spam filtering solutions.
Easy to use
Nothing to install, configure or train. SpamHero will even detect your valid email addresses.
Tracking 100+ million senders
Sender behaviors are tracked in realtime. The sender’s reputation is weighed during the filtering process.
Over 4 million filters
Every message is scrutinized through a mind blowing number of filters. All filters are consistently tested for accuracy.
17,000+ filters added daily
Using spam traps around the world we are able to detect new spam attacks as they occur and adapt to them instantly.
Expert administration
team of spam techs work 24/7 to test and create filter rules.  The result: consistently accurate filtering. 
Incoming, unfiltered email directed to your domain.   Along with the good email you want, it includes a barrage of spam, phising and virus emails that you don’t want.
A simple change to your domain’s MX record puts MTIN’s extremely powerful and remarkably accurate filtering service to work for you.
The bad stuff is put in a “quarantine viewer” so that there’s no chance of ever losing good email.  In the unlikely event that a good message is blocked by SpamHero, it can be viewed in either the included shared quarantine or optional individual quarantine viewers.
GOOD email is delivered to your domain without delay …BUT… the bad email is captured (quarantined) by MTIN!

-Less Infrastructure for you to maintain. Our servers do the processing of the spam
-Less false positives and spam for you to deal with
-No expensive hardware or support contracts
-Low cost $15 per domain per month
-Web-Based control panel

CentOS 7 changes Apache

So Centos 7 makes some changes from the way we are used to doing thing.  Many of the packages you are used to no longer start with the normal init.d scripts.  Let’s take apache for example.  Once installed via yum  you have to issues the following commands:

To make sure the httpd service start automatically at the boot time, enter:
systemctl enable httpd.service

The following command will disable the httpd service at the boot time:
systemctl disable httpd.service

To Start httpd:
systemctl start httpd.service

To verify that the httpd service is running, enter:
is-active httpd.service



Router OS 6.18 released

From The ChangeLog

What's new in 6.18 (2014-Aug-01 10:47):

*) sstp - report TLS encryption as well;
*) safe mode - do not allow user with less permissions to disrupt active safe mode;
*) console - print command does not try to reuse item numbers assigned by
    previous invocations of 'print' when doing 'print where' or 'print follow',
    items are numbered consecutively starting from '0'.
*) console - fix compact export of some partially modified
    configuration values;
*) api - use the same syntax for property values as is used in 'print detail'
    output, with the exception of numbers, that are not shown with suffixes
    (K/M/G/T or bitrate) and are not contracted or separated into digit groups,
    and "yes"/"no" values that continue to be reported as "true"/"false".
*) console - show internal numbers in the form returned by 'find' (like *9A0F)
    instead of "(unknown)" when configuration refers to
    deleted items. This change also applies to API.
*) ipsec - fix addition of default policy template;
*) console - values of type 'nil' were returning 'nil' as result of most
    operations. Now it compares less than all values except 'nil'
    and 'nothing', and compares inequal to all values except 'nil'.
    This was changed to make 'print where' and 'find where' more useful.
    An example. Previously the following command
        /ip route print where routing-mark!=nosuch
    Would not print routes that had no value for 'routing-mark' set, because
    (nil != "nosuch") was equal to nil. Now it evaluates to 'true', and this
    command will also print all routes that have no 'routing-mark' value set.
*) l2tp - fixed problem on CCR where server responded with wrong source address;
*) console export - put qutes around item names that start with a digit;
*) sntp client - added support for dns lookup of ntp servers;
*) console - when exporting to file, use name ending in '.in_progress', and
   rename when export finishes;
*) bridge setups sometimes could crash on CCR devices;
*) fixed port flapping in 1G mode on sfp-sfpplus1 on CRS226;
*) fixed SXT ac model losing it's interface if changing regulatory settings in "routerboard" menu