You are here

Manual MCS control?

9 posts / 0 new
Last post
Manual MCS control?

Is there a method, either through a package or command-line change, to restrict the MCS from reaching above a certain value?  Such as "1"? or Less than "10"

We've been experimenting with long-distance (24 mile) links through high-RF areas.  If both units are at full-power, we have 20db or more on  both ends and the MCS rate exceeds 10 or more.  This causes very erratic performance, but a high raw data-throughput.  By reducing power levels to 40mw, I am able to drop the signal level to 9-10db at each end and the link becomes more reliable.

Our goal is a slow/reliable link, not a fast link with unreliable performance.  It would be nice to run higher power levels for a higher link margin and restrain/lower the MCS from going higher than a level we determine.

Any suggestions?


K6AH's picture
Could be on the timeout edge

The maximum distance for a 20MHz channel is 29 miles (based on the internal protocol timeouts).  If your devices are low on RAM, or bogged down with extra software running on them, then 25 miles may be on the ragged edge.  Consider reducing the bandwidth to 10MHz where the max distance value jumps to 64 miles.  Let us know what you find... I don't know that anyone has ever documented what happens on the timeout edge.

Andre, K6AH

I'm running 5mhz channels &

I'm running 5mhz channels & have been able to replicate the issues in different circumstances.  I appreciate the response, but it appears to be for a different issue.  With the power-level at "ideal levels", the link runs PERFECT (20,000 pings with 1 drop, I consider that perfect for an unlicensed RF link).  What I'm trying to account for is "the real world" with people who aren't experts using it. I've replicated this with different equipment in different locations.  When running too much power, the RSSI maxes out, the encoding jumps to QAM16 (or something expecting lower interference) and then you see the radio constantly throttling up/down on MCS levels, occasionally dropping packets during the ramp-down.   By lowering power, it lowers RSSI, which reduces the MCS level to 0 or 1, which is much less prone to interference.    --I might have to just as the AREDN team how much it would cost to add this feature.  It's included in commercial gear like Airfiber simply because sometimes you want to control the encoding AND the power, not just power.

AE6XE's picture
There's no option in this

There's no option in this opensource driver to lock the MCS rate.

Both the reduction of bandwidth and increase in power negatively affects the ave-to-peak power of the signal.   At full power on 5MHz, the signal quality is not good likely due to sending the the PA out of linearity and distorting the signal.   Compare the signals between 5MHz and 10MHz at the different power levels: 

The higher power may not be performing well due to this issue.  What do you find on a 10MHz channel?    I suspect you will not have to lower the power as much and will achieve higher thoughput over 10MHz channel.  


AE6XE's picture
K2VIZ,   We may be able to

K2VIZ,   We may be able to lock the rate, by limiting the list of rates the radio will choose from.  There is a setting for this.   This can be tested by editing /etc/config/wireless on one of the nodes.   Find and make this section look like this, by adding the "supported_rates" list.  

config 'wifi-device' 'radio0'
    option network 'wifi'
    option mode 'adhoc'
    option ssid 'AREDN-5-v3'
    option encryption 'none'
    list supported_rates '6000 9000 12000'

Note, MCS 5, 6, and 7 all use the same modulation of 64QAM, thus it would take a jump from 7 down to 4 to change modulation technique.   Also, do consider that when lowering the rate, it takes longer to transmit the same data.  This additional air time means it increases the probability of a collision or interference. 

I suspect there is more to explain in the environment, and other options to improve performance. 





This is perfect -- Do you have a list of what 6000, 9000, 12000 correlates to?  I will experiment with this.  I suspect your first suggestion that of non-linear/distorted transmissions(from too much power) may be the culprit, but in the spirit of science -- I must test both situations.  

AE6XE's picture
Values are in kb.  So 6Mb,

Values are in kb.  So 6Mb, 9Mb, ... .  The values need to match to the MCS rates.

nc8q's picture

Thanks, Joe:

This is interesting.
I am a little baffled as the numbers seem to match 802.11bg not 802.11n.
I do notice that there are eight values; '6000 9000 12000 18000 24000 36000 48000 54000'.
This matches the quantity of single channel Modulation Coding Schemes.
I assume there is a relationship.

IIRC, when a dual stream device is using MCS0-7 it is transmitting the same data on both streams.
This may allow the receiver to more reliably capture the data without regard to the arriving polarity.

So, for fewer dropped UDP packets, how might one 'force' a dual stream device to use <= MCS7 ?


AE6XE's picture
Yes, we may be in uncharted

Yes, we may be in uncharted 'testing' territory.   I didn't find any chatter in forums on this option in recent years, however this is the same ath9k driver in use for many years.  The rate selection mechanism is the same across 802.11a/b/g/n, so 'should' still work.   Note, that in 802.11n, there are different rates depending on Long or Short Guard Interval.   Generally, I see only SGI in use or even showing on short distance links.   I'd put in the following to give a try:

6500, 7200, 1300 1440, 1950, 2170, 2600, ...,  6500, 7220

(see table at ​ )

Also, the Guard Interval is designed to be the length of how long a reflected or faded signal could be delayed and received.  The time allocated is to ensure the next symbol received on the direct path is not trashed, or always comes in after the previous symbol's reflections.   This interval is doubled when cutting the channel width in half.   If there's a chance the SGI is in use, then can leave out these rates to only include LGI rates in the list to ensure this extra time is given.   But, giving more time on the channel, also means more probability of a collision, which is working against the goal of a robust link.

"when a dual stream device is using MCS0-7 it is transmitting the same data on both streams.
This may allow the receiver to more reliably capture the data without regard to the arriving polarity."

The rate selection table has a wealth of information:
"cat  /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/<mac of neighbor>/rc_stats"

In MCS0-7, the receiver combines the received signals on the 2 antennas to maximize the SNR of the combined signal.   This table includes the actual measured success of transmitting packets.   If we accept a little more error rate of, say 3% to 5% of failed packets using MCS8-15 where 2x the data is transmitted  with different bits sent out each polarization, we might get more data over the channel.   We're looking for the sweet spot of all of the MCS options -- the algorithm defines this as maximum data thoughput.

Look in this rate selection table to compare the probability of successfully transmitting the packets to a given neighbor.  If the success rate is still ~98%, but voip and other things are still not working well, the problem is probably because the transmitter can't get time on the channel--something is preventing the transmitter from getting air time.   There might not be anything that can be done.  If it is another 802.11a/b/g/n/ac signal, then I'd look at lowering the  packet size threshold to trigger RTS/CTS, which coordinates time on the channel, and by default is set to the max packet size or close to it.   



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer