You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Limit the speed of the wifi. It might be useful to stop a device continually trying to bump the speed up if that's not ever practical for a given link. Might produce more consistent performance (maybe).
The text was updated successfully, but these errors were encountered:
This was my understanding in researching this issue in the past - I assume the available documentation still represents today's implementation. In ath9k, the rate selection logic tests the throughput with up to 10% of the traffic continually trying adjacent rates to measure. For a higher rate to be selected, these probing/testing tries would have to be a higher max throughput over a period of time before bumping up/down the rate selection. This hysteresis delay would avoid the jitter of up/down/up/down concerns. In inspection of the rate selection table, adjacent rates are tested, not all rates. If a weak signal, the higher rates would have negligible to no attempts. The rates tested are like a bell curve around the highest throughput rate -- only testing a few rates higher/lower than the max_tp.
Limit the speed of the wifi. It might be useful to stop a device continually trying to bump the speed up if that's not ever practical for a given link. Might produce more consistent performance (maybe).
The text was updated successfully, but these errors were encountered: