We recently swapped out a pair of 180 degree 900 APs with a full cluster of 6. I’m finding that whichever AP I put on 924 ends up having problems with noise from a competitors Ubiquiti equipment. I’m trying to puzzle out which AP is going to take the hit based on the link capacities of the SMs on them.
My question is this: If I have a customer running on 2X with a 1.9 Mbps downlink speed at 100% efficiency, are they using the entire downlink of the AP to get 1.90 Mbps, or is there still 1.3 Mbps left of the 3.2 Mbps pool for other customers?
I suppose as an alternate question, how do I determine to effective throughput of the AP as a whole?
Thank you!
Yes, a 2X link test on a 900 MHz AP will basically monopolize the entire AP’s resources. What matters is air time: A 3/1 Mbps 2X link uses the same air time as a 1.5/0.5 1X link
Determining effective throughput is really only possible by graphing the traffic in the ethernet port of the AP and checking the RF Overload statistics. You can get a reasonable ballpark by looking at all the link capacity tests as a whole.
Take the following hypothetical scenario (downlink only to keep it simple):
SM 1: 3 Mbps 2X link
SM 2: 2 Mbps 2X link
SM 3: 3 Mbps 2X link
SM 4: 1 Mbps 1X link
Again, each of these link tests represents 100% (or close to) air time dedicated to that SM. So SM 4 downloading at 1 Mbps uses the same amount of time as SM 1 downloading at 3 Mbps, and SM4 downloading at 512 Kbps uses the same amount of time as SM 1 downloading at 1.5 Mbps, etc. The total throughput in this scenario would be about 2.25 Mbps, assuming air time is shared fairly between each SM. However, depending on customer traffic, the realized capacity could be as high as 3 Mbps or as low as 1 Mbps. This gets more complicated with more links of course.
Bandwidth allocation for this reason is very tricky on 900 MHz FSK, and this is why 1X links are really very bad for the sector’s performance. If it’s stable enough, running marginal links at 2X instead of 1X can have a positive impact on bandwidth as a whole… as long as it doesn’t hurt customer experience too much.
Controlling how much of the AP’s resources can be claimed by a single SM with good QoS settings is very important. We found that a high burst size and low sustained rate gives the best compromise between user experience and limiting damage to the AP.
Hmm. So I really need to be playing with different frequency combinations until I find out which has the least impact on customers with low link capacity speeds.
Do you have any other advice on dealing with a cluster that has problems with 924 in all directions?
We initially had burst set to 24000 down and 8000 up, but ended up setting both to 0. We thought the burst was allowing customers to saturate the AP for short periods of time, leading to packet loss. Are you finding this is not the case, or did we have our bursts set too high?
Thank you again for your help!
Yeah avoiding 1X is really important. If 924 is saturated in your area the only easy thing to do is an A/B/A/B/A/B setup with 906 and 915. Another trick that helps, although costs money, is changing polarities. Most of the time interference is really on a single polarity. AP-side needs new antennas but as far as SMs go turning them sideways works great! I am assuming you are running real antennas too, not the integrated SMs. We learned very quickly to not even bother with the integrated units.
Yes, setting a massive burst will saturate the AP, but this is intentional, and - done correctly - actually better. The burst mechanism is essential to a good experience on Canopy gear. The logic is that “average” customer requests are served quickly, leaving the AP’s resources free for other customers to use. In practice of course what BWSP works best for you depends on your customer traffic patterns.
We sell 1.5 Mbps on a 2X link. Here’s the plan we provision:
Sustained: 1536 Kbps/512 Kbps
Burst: 8192 Kbytes/4096 Kbytes
Given a 3 Mbps link, a 1 MB webpage should download in 21 seconds, whereas as without the burst the AP could be tied up - or rather, the available bandwidth reduced - for 43 seconds. Now of course we’re still moving the same amount of traffic but what makes the difference is that web surfing is sporadic in nature. The likelihood that another customer is going to want to do something during those 21 seconds is less than if it was a larger 43 second window, and thus the AP is more efficient overall (and better customer experience). Plus on a speed test it usually measures about 2 Mbps hahahaha.
This doesn’t work so well with constant loads like streaming video or buttheads that leave BitTorrent running all day. About 24 hours after NetFlix came out in Canada our support line was slammed with complaints from our 900 MHz customers. Naturally everyone had to give it a try! Of course when sectors have 20 subscribers on them this doesn’t bode so well. NetFlix has great compression but it tries to constantly adjust the bitrate “for the best experience”. This probably works great on DSL or something but on poor ol’ 900 MHz, sustained rates are all over the place as the AP takes such a massive hit when your neighbor brings up Facebook.
So, this is what we did:
Sustained: 512 Kbps/128 Kbps
Burst: 16384 Kbytes/4096 Kbytes
Draconian by comparison but the calls stopped and everyone was happy. By turning up the burst allocation so most normal activity is 100% bursted at maximum air rate. Then by dropping the sustained, traffic like NetFlix not only has a drastic less effect on the AP, but it also gets that speed with a LOT more stability - so there’s less buffering on the user end! As a bonus this tests near our advertised speed too.
I tell all our customers to go under the account settings and change video quality to low to cap it at 300 MB/hr or around 700 kbps. That really helps keeping it from trying to push more that the connection can reliably provide. If they don’t set it to low, they don’t get to use Netflix, and even then it’s something we do not guarantee.
You make some very good points about burst improving overall capacity. I’ll have to do some more playing around with that.
I never thought to try an A/B/A/B/A/B with a 900 cluster. Thank you very much for the suggestion, I’m looking forward to seeing how it works.
Thank you again!