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?
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?
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
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
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
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.
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
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
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
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