AP go-slow

I have an 5.8ghz Adv AP with 85 SM’s registered. The customers are nearly all residential and the AP peaks about 3megs at peak times.
It is running 7.3.6 in hws

Today the AP ground to a halt. Maximum bandwidth through it was about 400k and it was taking 30/40 seconds for its web page to display (via wired connection!)

A reset of the AP fixed the problem. It has happened once before.

Have I got this AP overloaded ? or could there be another problem here. I know the Moto figure of 200 sm is optimistic, but at what sm figure do you start to see problem (packet loss etc.)

Any ideas ?

Cheers- John

Could have been a PPS issue with 85 SMs on a single AP. What time of day was it? A busy time for your network?

I know the Moto figure of 200 sm is optimistic, but at what sm figure do you start to see problem (packet loss etc.)

I think the realistic number if you are offering service comparable to DSL/cable is 80 SMs per AP.
What do you have your throughput set at? Bursts and sustained?


It was late afternoon, so not particularly heavy load at this time.

The majority of customers are on 1Mb at 40:1. This is managed at the gateway rather than the SM.

Adding additional AP (s) is probably the way to go, just interesting to know if others have seen this happen. It has not happened on other AP’s yet.


Mu busiest AP only has 35 SMs on it so I do not have experience with the max numbers slowing them down. Yet… :smiley:


I have more than five AP-s that have over 90 SMs. No problems like this.

The real troubles begin after 100 SMs. We have troubles registrating in peak hours, we have packet loss 1-2%, we have complains about speed. Speeds are 512/128 kbps for residential user, 10 GB limit. The AP transmits up to 5 mbps down, and 1 mbps up. 1000 pps.

when that happens you should take a traffic sample…

throw ethereal on a laptop and just capture a few minutes of traffic

with 85 users you could find maybe 5 people are doing bit torrents and eat us your pps.

also watch your ICMP traffic…if you arnt good at looking at ethereal logs email me some over and i would glady take a look for you.


Thanks for the tips guys -

I don’t get too many complaints about speed or packet loss, its just a little worrying the way it flipped over like this.

If it happens again I will take a sample, but you know the deal - when the phone is jumping, the temptation is to get it back up again.
The first time it fell over was a month ago, so hopefully my AP’s on backorder will arrive and be fitted before any more problems surface.

Nice to know that I’m getting bang for the buck with the AP’s as they are pricey!

Cheers - john

This might be an obvious question, but you do have enough control slots? For 51-150 SMs on 1 AP, it should have 2 Control Slots.

Hey ais3101:
I love the way that factoid just rolls off your keyboard!!! :smiley:

Not many people would remember that detail (or that number!!)

Well done!


lol! :lol: I remembered about the control slots, but I did have to look that number up. Shhh! Don’t tell anyone :wink:

It (was) set to zero…

Will try 1 and see if this works better.


typo… will try 2 … thanks (this forum is a mine of information )

Just a caveat: the Max Range, # Control Slots, and Data Downlink % should be the same for each AP in the cluster, however if they aren’t the same AND you start to see a lot of problems like re-registrations, then you can use the Frame Calculator to balance out the APs. That will help the sync work properly. If you haven’t read about the Frame Calculator, here’s what you do:

First find out the settings for Max Range, Control Slots and Downlink Data % for each AP in your cluster.

Open the Frame Calculator in any AP (it’s the last link in the Expanded Stats for 7.3.6 anyway).

Fill out the corresponding info for one AP in the cluster. Click Apply Settings (don’t worry, it doesn’t change the actual settings for the AP), and then click Calculate.

In the Calculated Frame Results look for the Uplink Rcv SQ Start value. Ignore everything else.

Repeat the above steps and find the Uplink Rcv SQ Start value for each AP.

The Goal is to get the Uplink Rcv SQ Start value of ALL the APs within 300 (ideally 150) bits of each other.

If these values are NOT within 300 bits of each other, then you’ll want to play with and adjust the Control Slots, Max Distance, and Downlink Data % in the Frame Calculator until you get within 300 bits or better for each AP.

Just a couple more notes: The Max Distance should be the max distance of the FURTHEST SM. It’s not recommended to set this number higher than the furthest SM. Second, the Downlink data % is the best value to tweak because it’s the least critical and it won’t affect performance TOO much if it’s slightly changed.

Now, here’s another caveat: all of the above is taking directly from my notes. I don’t have any actual real world experience with using this and adjusting my AP settings in an active Canopy network. But if someone here has played with the Frame Calculator AND adjusted the settings in your active APs, please share your experience. I’m curious to find out if and how much this helps.

LOL :lol: I just went back to your original post and realized you have only 1 AP. :oops:

Well, if you every do build a cluster of APs, then you’ll know what to do :wink:

By the way, please let me know if setting the control slots to 2 helped.

I am impressed again…you actually took notes in class!!!


Well done!!!

Thanks Charles :smiley: I can’t wait to actually use what I’ve learned in class. We have a very small Canopy network up now, but I haven’t run into alot of the issues that others here on the board have. I just hope I’m prepared when a problem does arise.

Forum (ais3101)

Just a update on this issue. This AP has not missed a beat since changing the control slots to 2. In the recent weeks, the bandwidth through the AP has peaked over 4megs without any problems.

Also - I had a situation today where an SM would not register with an AP (with 70SM). The signal was -62dBm jit 1. I had to change control slots to 2 on this AP also, and reboot.
SM registered first time…

Thanks for help - John

John, thanks for the update. I’m just ecstatic that I was actually able to contribute something to this forum.