900 Links Down for 0-15 seconds???

After returning all of our 900 subscribers to Software Schedualing, we noticed ALOT more Green on our intermapper. Their links were much more stable and no more 10000+ re-registers.

However, we will notice that up to 3/4 of all the subscribers on a 900 AP will go down at the same time and remain down from anywhere between 0-15 seconds. This does not show up in the re-registration count. I know I have left out alot of information, which I can fill in as needed. Below is an example of what we see.


Status: UP (Reachable since Jun 09, 16:13:24)
Protocol: Wireless - Canopy (SM) (port 161)
Up Time: 2 days, 5 hours, 23 minutes

Availability: 99.9 % (of 65 days, 3 hours, 16 minutes)
Packet Loss: 0.27 % (of 543621 total attempts) [Reset]
Recent Loss: 3 pkts at Jun 09, 16:13:16
Round-trip time: 109 msec
Canopy SM Information
RSSI: 1459
Jitter: 2 (1-15)
Round Trip Delay: 197 x 100ns
Power Level: -68 dBm
Session Status: REGISTERED
AP MAC Address: 0a-00-3e-90-10-3a
Color Code: 1
Recent Outages:
06/09 16:13:22: DOWN for 2 seconds
06/09 15:11:58: DOWN for 3 seconds
06/09 14:52:34: DOWN for 6 seconds
06/09 14:23:08: DOWN for 4 seconds
06/09 14:14:55: DOWN for 1 second
06/09 13:32:56: DOWN for 12 seconds
06/09 13:02:22: DOWN for 2 seconds
06/09 12:44:04: DOWN for 1 second
06/09 12:20:39: DOWN for 2 seconds
06/09 12:07:17: DOWN for 2 seconds
Last updated Jun 09, 16:15:56; interval: 30 seconds

If a link would be down for 2 seconds, would that count as a reregister? I KNOW it takes longer than 5-10 seconds for a SM to reboot also. Thanks for any help guys.

Zach

Since you are using software scheduler look at the SM’s expanded status pages. Under there you will see uplink stats. The first or second field will be bandwidth request timeout. Is this value increasing? If it is then the AP needs more control slots for communicating with the sm’s. The default value is 3 and you can go all the way up to 16. You should try to increase these to reduce the number of bandwidth request timeouts.

Intermapper maybe the problem.

Here are 3 random 900 Subscribers expanded stats/uplink stats info. Using Software Schedualing.

Uplink Statistics
BadTID Count 3516
BwReqTmout Count 123511
BwReqContinuation Count 21965
BwReqIdle Count 23119
VCTxDone Count 23118
SendBWReq Count 168650
RcvdBWGrnt Count 48486
BwGrntFailBWCbRtnd Count 1162
BwGrntFailNoRoom Count 0
UpLnk Control Q Lost Count 0
UpLnk Data Q Lost Count 239
ActualTxFragsCnt Count 145827
ExpectedTxFragsCnt Count 158127
BwReqXmtCmpltTmout Count 6507
UpLnkEnable Count 255
UpLnkDisable Count 254
TxPacket Count 25041
CurrentSize 0

Uplink Statistics
BadTID Count 5205
BwReqTmout Count 23005
BwReqContinuation Count 10528
BwReqIdle Count 30643
VCTxDone Count 30643
SendBWReq Count 64176
RcvdBWGrnt Count 46376
BwGrntFailBWCbRtnd Count 29
BwGrntFailNoRoom Count 0
UpLnk Control Q Lost Count 0
UpLnk Data Q Lost Count 345
ActualTxFragsCnt Count 176488
ExpectedTxFragsCnt Count 189638
BwReqXmtCmpltTmout Count 0
UpLnkEnable Count 1
UpLnkDisable Count 0
TxPacket Count 40162
CurrentSize 0

Uplink Statistics
BadTID Count 8604
BwReqTmout Count 82517
BwReqContinuation Count 27206
BwReqIdle Count 484922
VCTxDone Count 484921
SendBWReq Count 594645
RcvdBWGrnt Count 520728
BwGrntFailBWCbRtnd Count 83
BwGrntFailNoRoom Count 0
UpLnk Control Q Lost Count 0
UpLnk Data Q Lost Count 17278
ActualTxFragsCnt Count 2284774
ExpectedTxFragsCnt Count 2358202
BwReqXmtCmpltTmout Count 0
UpLnkEnable Count 5
UpLnkDisable Count 4
TxPacket Count 856257
CurrentSize 2