Manual:Wireless FAQ
Settings
What is CCQ and how are the values determined?
Client Connection Quality (CCQ) is a value in percent that shows how effective the bandwidth is used regarding the theoretically maximum available bandwidth. CCQ is weighted average of values Tmin/Treal, that get calculated for every transmitted frame, where Tmin is time it would take to transmit given frame at highest rate with no retries and Treal is time it took to transmit frame in real life (taking into account necessary retries it took to transmit frame and transmit rate).
What is hw-retries setting?
Number of times sending frame is retried without considering it a transmission failure. Data rate is decreased upon failure and frame is sent again. Three sequential failures on lowest supported rate suspend transmission to this destination for the duration of on-fail-retry-time. After that, frame is sent again. The frame is being retransmitted until transmission success, or until client is disconnected after disconnect-timeout. Frame can be discarded during this time if frame-lifetime is exceeded.
What is disconnect-timeout setting?
This interval is measured from third sending failure on the lowest data rate. At this point 3 * (hw-retries + 1) frame transmits on the lowest data rate had failed. During disconnect-timeout packet transmission will be retried with on-fail-retry-time interval. If no frame can be transmitted successfully during disconnect-timeout, connection is closed, and this event is logged as "extensive data loss". Successful frame transmission resets this timer.
What is adaptive-noise-immunity setting?
Adaptive Noise Immuinty (ANI) adjusts various receiver parameters dynamically to minimize interference and noise effect on the signal quality [1] This setting is added in the wireless driver for Atheros AR5212 and newer chipset cards
Setups
Will an amplifier improve the speed on my link?
It depends on your signal quality and noise. Remember that you can probably get a better link with low output power setting, and a good antenna. Amplifier increases the noise and will only cause problems with the link.
You should understand that for 802.11 devices there is really limited amount of information (or "feedback" from the environment) that devices can use to tune their behaviour:
- signal strength, which could be used to figure out best transmit rate knowing receiver sensitivity. Sill this is not reliable taking into account that sesitivity for different receivers varies (e.g. changes over time), path conditions are not simmetric (and device can only measure signal strength it receives), etc.
- by receiving/not receiving acknowledgement for frame sent.
Taking into account that using signal strength is not reliable, 802.11 device is essentially left with only one "feedback" to tune its operation - success/failure of transmission. When transmission fails (ACK not received in time), there is no way how sender can figure out why it failed - either because of noise, multipath, direct interference (and wether that disturbed actual data frame or the ACK itself) - frame just did not make it and in general it does not matter "why". All that matters is packet error rate.
Therefore RouterOS implements algorithm to try to use medium most efficently in any environment by using only this limited information, giving users the ability to control how algorithm works and describing the algorithm. And there are only a few usage guidelines, not a set of values you should use in particular situation.
In general - the larger hw-retries, the better "feedback" device gets about medium ability to deliver frame at particular rate (e.g. if sending frame with rate 54mbps fails 16 times, it is telling you more than if it fails with 2 retries) and the better it can figure out optimal transmit rate, at the expense of latency it can introduce in network - because during all those failing retries, other devices in this channel can not send. So bigger hw-retries can be suggested for ptp backbone links - where it is known that link must be always on. Less hw-retries make rate selection adapt faster at the expense of some accuracy (going below 2 is not reasonable in most cases), this can be suggested for ptmp links, where it is normal for links to connect/disconnect and keeping latency down is important.
on-fail-retry-time and disconnect-timeout controls how hard device will try to consider remote party "connected". Larger disconnect-timeout will make device not "disconnect" other party, even if there are lots of loss at the smallest possible transmission rate. This again is most useful for "weak" links that are known that they "must" be established (e.g. backbone links). In ptmp networks large disconnect timeout will again increase latency in network during the time e.g. AP will attempt to send data to some client that has just been disabled (AP will try to do this for whole disconnect-timeout).
frame-lifetime allows to tune for how long AP is attempting to use frame for transmitting before considering that it is not worth delivering it (for example, if sending frame fails at lowest possible rate, on-fail-retry-time timer is enabled, if during this timer frame-lifetime expires, particular frame is dropped and next transmission attempt will happen with next frame. Disabled frame-lifetime means that wireless will ensure in order delivery of "all" data frames, no matter how long it takes, "or" will drop the connection if everything fails). This allows to optimize for different types of traffic e.g. for real-time traffic - if primary use of wireless network is e.g. voip, then it can be reasonable to limit frame-lifetime, because voip tolerates small loss better than high latency.