We are seeing some outdiscards on the AP radios (Statistics->Radio tab) and had a few questions regarding this statistic.
The 450 user guide has this definition for outdiscards:
outdiscards Count: This field displays how many outbound packets were discarded without
errors that would have prevented their transmission. (Some of these
packets may have been discarded to increase buffer space.)
That definition is quite vague for the purpose of figuring out what is causing the discards.
What is the algorithm for determining what increments the outdiscards count? What is an acceptable discard rate over time for the radio transmitting to SMs? Are there any tweaks/parameters/settings we can look at to reduce these discards?
The statistic itself is there to measure the discarded packets. I have asked engineering to respond to this with possible reasons why this stat would be incremented...
We are seeing some outdiscards on the AP radios (Statistics->Radio tab) and had a few questions regarding this statistic.
The 450 user guide has this definition for outdiscards:
outdiscards Count: This field displays how many outbound packets were discarded without
errors that would have prevented their transmission. (Some of these
packets may have been discarded to increase buffer space.)
That definition is quite vague for the purpose of figuring out what is causing the discards.
What is the algorithm for determining what increments the outdiscards count? What is an acceptable discard rate over time for the radio transmitting to SMs? Are there any tweaks/parameters/settings we can look at to reduce these discards?
rnelson,
RF Out Discards happen when the VC's queue is backed up and is dropping the packet. This can be caused for a few reasons: 1) A very fast burst of packets on one VC can fill up the queue. This is most commonly seen on some uplink Video Surveillance equipment that sends a huge burst of data but only once a second. To address this there is an option "Configuration -> Radio -> Large VC data Q". However, in general too much queueing is not beneficial for TCP, so generally not recommend to have this option for a typical SM.
2) The more common problem is the RF is generally full. This can be seen from Statistics -> Frame Utilization. When this is at 100% then the RF is maxed out and will be dropping packets and pegging this stat. I don't have a good answer for an acceptable rate, as it depends upon your model and over subscription. Perhaps other providers can chime in on their experience. In general it's not a terrible thing as TCP traffic will be retransmitted. So this is normal stat that is expected during busy RF periods. To increase the RF pipe can be done in lots of ways and here's a few:
Larger Channel Bandwidth (of course not always possible)
Increasing modulation of traffic (like adding dish or moving to cleaner channel)
Adjusting downlink/uplink ratio (if only one of the directions is full, but of course careful to do this for whole sector)
Moving SMs to other APs
Decreasing the Sustained Data Rate of SMs using all the bandwidth, so that the RF has more room for other users.
If SMs have RF out discards, maybe increasing the number of Contention Slots will help the SM get Bandwidth Requests up to the AP so it can be scheduled. This is a tough one to say in general, but we are planning an Auto Contention feature to optimize this automatically.
Even if not seeing high Frame Utilization for a 1 minute period, it's possible for a portion of that it had several full frames in a row, backing up the RF.