You are here

Manual MCS control?

11 posts / 0 new
Last post
k2viz
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
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
 

k2viz
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
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:   https://www.arednmesh.org/content/spectrum-chart-2GHz 

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.  

Joe AE6XE
AE6XE
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. 

Joe AE6XE
   

 
k2viz
Joe,
Joe,

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
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
nc8q's picture
supported_rates

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 ?

Chuck

AE6XE
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 ​https://en.wikipedia.org/wiki/IEEE_802.11n-2009 )

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.   

Joe AE6XE

 
va3tec
Low SNR Radio link possible solutions?

Hello All:

We are in a similar situation as we have an EXTREMELY Low SNR radio link. We have a working link but at the extreme low signal to noise at each end, this is mostly due to physical limitations of the hardware setup. We are in a unique position that we have a node at each end where there are no other nodes in the band (5.8Ghz) that are in the area, and we have access to each other nodes and able to change or hard code the data rates. But unfortunately we are transmitting through trees and over water at a distance of 7.6 Km or just under 5 miles.

From the post above, I also would like to Lock down the MCS rate to help improve the reliability of the data rate of my node.
Basically what would be the lowest bit-rate available to us, how to apply it? And how can we setup the MCS not to do the automatic searching?
If this is possible. Attached is screen capture of rc_stats of my node. (it's BAD :( )

Another possible solution to the link problem might be a little bit of an abstract one, but looking for input from people.
Would it be possible to incorporate a GPS stabilized clock Oscillator at both locations so that the local oscillators of each nodes would have the most stable clock source possible.

Thanks for all your help!

Mike Kennedy
VA3TEC
 

Image Attachments: 
AE6XE
AE6XE's picture
VA3TEC,  the data shows that
VA3TEC,  the data shows that ~90% of the time, the very lowest possible rate MCS0 Long Guard interval (LGI) is in use with an error rate at 26% transmitting a data packet.     About 10% of the attempts, it is using the Short Guard Interval (SGI) to achieve a little better rate, with 23% error rates.    I don't think it matters what you do, the SNR looks marginal even if locked in at lowest possible rate.  Locking in at the MCS0 LGI lowest possible rate, would likely make it worse, as some of the time it is using a slightly higher rate right now with SGI.

Regarding gps time synchronization.    Ubiquiti uses gps time for co-located nodes using proprietary TDMA protocols so they can coordinate their time slots to transmit.   I've not aware of a time sync in use for devices at distances apart.  Rather, the devices and 802.11n protocols measure the relative time between them (accounting for propagation delay to understand a common time).    AREDN and standard Access Points use CSMA to identify when to transmit, not based on time.  With RTS/CTS a timeslot is coordinated across nodes (and hidden nodes) under CSMA for only one device to transmit.  But my understanding, this is all based on relative time measurements. 

Joe AE6XE 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer