Hi all,
we are experiencing a very strange behavure with a link of nearly 30 Km consisting of a pair of PBE-M5-400 devices.
The link is affected by a nearly 20 dbm fading ( from -55dbm till .75dbm) with a very very slow rate haft an hour to several minutes....
rtt and packet loss are acceptable but tx speed is floating from few mbps to 30 mbps
channel width is 5Mhz at present; by extending channel width to 10 Mhz we get same behavure but with much higher rtt values and packet loss
We noted from station rc_stats that the device is trying to use bot SGI and LGI modes flipping ...
by comparing with other nodes using rocket radio we never seen this flipping...
my question is: there is any method to force LGI in order to try to make more stable the link ?
any hint or suggestion is welcome
Attached a dump of the rc_stats
Mike
best ____________rate__________ ________statistics________ ________last_______ ______sum-of________
mode guard # rate [name idx airtime max_tp] [avg(tp) avg(prob) sd(prob)] [prob.|retry|suc|att] [#success | #attempts]
HT20 LGI 1 MCS0 0 1477 5.6 5.6 100.0 0.0 100.0 3 0 0 1 1
HT20 LGI 1 MCS1 1 739 10.5 10.5 100.0 0.0 100.0 0 0 0 1 1
HT20 LGI 1 MCS2 2 493 14.9 14.9 100.0 0.0 100.0 0 0 0 1 1
HT20 LGI 1 MCS3 3 369 18.7 18.7 98.0 1.8 100.0 5 0 0 36 46
HT20 LGI 1 MCS4 4 246 25.3 25.3 96.1 1.4 100.0 5 0 0 1078 1332
HT20 LGI 1 DP MCS5 5 185 30.6 30.6 92.3 1.8 100.0 5 0 0 2168 3129
HT20 LGI 1 MCS6 6 164 32.9 23.0 62.9 2.0 100.0 5 0 0 1865 3154
HT20 LGI 1 MCS7 7 148 35.0 23.8 61.0 1.4 100.0 5 0 0 1337 3161
HT20 LGI 2 MCS8 10 739 10.5 10.5 100.0 0.0 100.0 4 0 0 1 1
HT20 LGI 2 MCS9 11 369 18.7 18.7 96.0 1.3 100.0 5 0 0 82 100
HT20 LGI 2 MCS10 12 246 25.3 25.3 95.6 1.1 100.0 5 0 0 1962 2243
HT20 LGI 2 C MCS11 13 185 30.6 30.6 99.3 1.1 100.0 5 0 0 9218 10522
HT20 LGI 2 B MCS12 14 123 38.9 37.0 85.8 1.6 50.0 6 0 0 37752 44669
HT20 LGI 2 MCS13 15 93 44.8 22.4 45.2 1.2 100.0 6 0 0 23902 29957
HT20 LGI 2 MCS14 16 82 47.3 0.0 2.2 1.9 0.0 6 0 0 33005 40303
HT20 LGI 2 MCS15 17 74 49.4 11.5 21.2 1.5 0.0 5 0 0 56950 64582
HT20 SGI 1 MCS0 30 1329 6.2 6.2 100.0 0.0 100.0 3 0 0 1 1
HT20 SGI 1 MCS1 31 665 11.5 11.5 100.0 0.0 100.0 0 0 0 1 1
HT20 SGI 1 MCS2 32 443 16.1 16.1 95.1 1.2 100.0 0 0 0 30 38
HT20 SGI 1 MCS3 33 332 20.2 20.2 99.4 1.0 100.0 5 0 0 380 402
HT20 SGI 1 MCS4 34 222 27.1 27.1 95.8 1.4 100.0 5 0 0 3478 4097
HT20 SGI 1 MCS5 35 166 32.8 22.8 63.1 1.2 0.0 5 0 0 2963 4383
HT20 SGI 1 MCS6 36 148 35.0 17.5 44.9 1.6 100.0 5 0 0 3347 5393
HT20 SGI 1 MCS7 37 133 37.2 22.5 54.4 1.5 0.0 6 0 0 2052 3799
HT20 SGI 2 MCS8 40 665 11.5 11.5 100.0 0.0 100.0 4 0 0 2 2
HT20 SGI 2 MCS9 41 332 20.2 20.2 96.1 1.3 100.0 5 0 0 108 129
HT20 SGI 2 MCS10 42 222 27.1 27.1 98.0 1.7 100.0 5 0 0 3300 3764
HT20 SGI 2 MCS11 43 166 32.8 22.2 61.1 0.9 100.0 5 0 0 22121 24846
HT20 SGI 2 A MCS12 44 111 41.0 41.0 97.3 1.8 100.0 6 2 2 88856 101406
HT20 SGI 2 MCS13 45 83 46.9 29.1 55.7 1.8 0.0 6 0 0 48776 57984
HT20 SGI 2 MCS14 46 74 49.2 20.2 36.9 1.8 0.0 5 0 0 93963 106066
HT20 SGI 2 MCS15 47 67 51.4 10.6 18.7 0.7 0.0 6 0 0 149250 163569
Total packet count:: ideal 566623 lookaround 21531
Average # of aggregated frames per A-MPDU: 1.1
we are experiencing a very strange behavure with a link of nearly 30 Km consisting of a pair of PBE-M5-400 devices.
The link is affected by a nearly 20 dbm fading ( from -55dbm till .75dbm) with a very very slow rate haft an hour to several minutes....
rtt and packet loss are acceptable but tx speed is floating from few mbps to 30 mbps
channel width is 5Mhz at present; by extending channel width to 10 Mhz we get same behavure but with much higher rtt values and packet loss
We noted from station rc_stats that the device is trying to use bot SGI and LGI modes flipping ...
by comparing with other nodes using rocket radio we never seen this flipping...
my question is: there is any method to force LGI in order to try to make more stable the link ?
any hint or suggestion is welcome
Attached a dump of the rc_stats
Mike
best ____________rate__________ ________statistics________ ________last_______ ______sum-of________
mode guard # rate [name idx airtime max_tp] [avg(tp) avg(prob) sd(prob)] [prob.|retry|suc|att] [#success | #attempts]
HT20 LGI 1 MCS0 0 1477 5.6 5.6 100.0 0.0 100.0 3 0 0 1 1
HT20 LGI 1 MCS1 1 739 10.5 10.5 100.0 0.0 100.0 0 0 0 1 1
HT20 LGI 1 MCS2 2 493 14.9 14.9 100.0 0.0 100.0 0 0 0 1 1
HT20 LGI 1 MCS3 3 369 18.7 18.7 98.0 1.8 100.0 5 0 0 36 46
HT20 LGI 1 MCS4 4 246 25.3 25.3 96.1 1.4 100.0 5 0 0 1078 1332
HT20 LGI 1 DP MCS5 5 185 30.6 30.6 92.3 1.8 100.0 5 0 0 2168 3129
HT20 LGI 1 MCS6 6 164 32.9 23.0 62.9 2.0 100.0 5 0 0 1865 3154
HT20 LGI 1 MCS7 7 148 35.0 23.8 61.0 1.4 100.0 5 0 0 1337 3161
HT20 LGI 2 MCS8 10 739 10.5 10.5 100.0 0.0 100.0 4 0 0 1 1
HT20 LGI 2 MCS9 11 369 18.7 18.7 96.0 1.3 100.0 5 0 0 82 100
HT20 LGI 2 MCS10 12 246 25.3 25.3 95.6 1.1 100.0 5 0 0 1962 2243
HT20 LGI 2 C MCS11 13 185 30.6 30.6 99.3 1.1 100.0 5 0 0 9218 10522
HT20 LGI 2 B MCS12 14 123 38.9 37.0 85.8 1.6 50.0 6 0 0 37752 44669
HT20 LGI 2 MCS13 15 93 44.8 22.4 45.2 1.2 100.0 6 0 0 23902 29957
HT20 LGI 2 MCS14 16 82 47.3 0.0 2.2 1.9 0.0 6 0 0 33005 40303
HT20 LGI 2 MCS15 17 74 49.4 11.5 21.2 1.5 0.0 5 0 0 56950 64582
HT20 SGI 1 MCS0 30 1329 6.2 6.2 100.0 0.0 100.0 3 0 0 1 1
HT20 SGI 1 MCS1 31 665 11.5 11.5 100.0 0.0 100.0 0 0 0 1 1
HT20 SGI 1 MCS2 32 443 16.1 16.1 95.1 1.2 100.0 0 0 0 30 38
HT20 SGI 1 MCS3 33 332 20.2 20.2 99.4 1.0 100.0 5 0 0 380 402
HT20 SGI 1 MCS4 34 222 27.1 27.1 95.8 1.4 100.0 5 0 0 3478 4097
HT20 SGI 1 MCS5 35 166 32.8 22.8 63.1 1.2 0.0 5 0 0 2963 4383
HT20 SGI 1 MCS6 36 148 35.0 17.5 44.9 1.6 100.0 5 0 0 3347 5393
HT20 SGI 1 MCS7 37 133 37.2 22.5 54.4 1.5 0.0 6 0 0 2052 3799
HT20 SGI 2 MCS8 40 665 11.5 11.5 100.0 0.0 100.0 4 0 0 2 2
HT20 SGI 2 MCS9 41 332 20.2 20.2 96.1 1.3 100.0 5 0 0 108 129
HT20 SGI 2 MCS10 42 222 27.1 27.1 98.0 1.7 100.0 5 0 0 3300 3764
HT20 SGI 2 MCS11 43 166 32.8 22.2 61.1 0.9 100.0 5 0 0 22121 24846
HT20 SGI 2 A MCS12 44 111 41.0 41.0 97.3 1.8 100.0 6 2 2 88856 101406
HT20 SGI 2 MCS13 45 83 46.9 29.1 55.7 1.8 0.0 6 0 0 48776 57984
HT20 SGI 2 MCS14 46 74 49.2 20.2 36.9 1.8 0.0 5 0 0 93963 106066
HT20 SGI 2 MCS15 47 67 51.4 10.6 18.7 0.7 0.0 6 0 0 149250 163569
Total packet count:: ideal 566623 lookaround 21531
Average # of aggregated frames per A-MPDU: 1.1
I do agree with your considerations... my question was just limited to the guard interval due to the fact that on other radios in the mesh I always see just the LGI entries,not any SGI entry...
Regarding interferencies by doing a wifi scan we do not see any other station at least with the same channel width..
I have not tried to use any ISO shield till now because not available... for sure there could be significant multipath due to near obstacles because both link end are in the city center...
The main point anyway is that the link goes across the napoli goulf, so most of the link is over the sea surface with surely significant temperature/humidity issues....
BTW as fas as you know can you confirm that the minstrel algorithm truies to check bot the LGI and SGI modalities for the various MCS ?
thanks again..
Mike
"BTW as fas as you know can you confirm that the minstrel algorithm truies to check bot the LGI and SGI modalities for the various MCS ?"
To my knowledge yes. Minstrel is very well documented here https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/ratecontrol/minstrel however the gist of it is that minstrel tries to find the fastest throughput data rate and uses it for the majority of packets, if a packet is lost over the air (this is before it would show up at the IPv4 level as lost) it is retransmitted at the next fastest data rate, if that fails it moves to data rate with highest probability of connecting and if that fails it finally falls back to the base rate. At the same time minstrel is also selecting random packets (10% of directed packets) to send out at random data rates to sample and determine how the remaining data rates are behaving.
Looking at the table you posted I would expect it to flip from SGI to LGI anytime a normal packet (a packet that is not intentionally being used to rate check the network) gets lost over the air which will happen frequently in a wireless system like AREDN but your primary appears to be SGI with LGI being the fallback. This chart at the time it was taken reads like MCS12 is the perfect encoding rate but since packets do get lost in all wireless networks staying at MCS12 but having a longer guard on the LGI is the best he system can do to maintain speed but adhere to the minstrel protocol that it try the 'next fastest' speed for a retry
Also for the LGI/SGI showing up: This will also depend what version of the firmware is running on each side of the link. IIRC the current stable release (3.16.1.x) doesn't support SGI so if your node is speaking to is 3.16.1.x then only LGI entires will show up in the list because the other neighbor doesn't support SGI it won't be a possible rate to choose from. The table is different per neighbor, if you happened to bring an older BBHN Linksys device (if this were 2.4GHz) you would actually not even see the MCS* Options at all, likewise if you bring an older BBHN Ubiquiti device in range the same thing happens where the firmware previosuly didn't have dual chains enabled so you wouldn't see MCS8-15 at all as the table only lists supported data rates with that neighbor.
I also got to the conclusion that actually the first choise after the minstrel thinking is to use an SGI mode, but this most of the times fails for some reason so it flips back to the safer LGI... so my hint is that the main issue is multipath that create intersimbol interference that the short guard time is not able to sustain, while the long guard time does....
All the nodes at at present are using the latest 3.17.0.1.RC1 sw release....
So my question was arising if with this latest SW release there is any way to disallow minstrel to select SGI and keep using ONLY the LGI....
any info on this ?
Thanks for your attention
Mike
1. Are your distance parameters set correctly?
2. Is your path totally "clear? Re-check aiming on both ends?
3. Try a different channel?
I have not found hardly any situations where 5 Mhz bandwidth works better than 10 Mhz for throughput in difficult situations. My longer links are running around 55 KM with little fading or problems, except for extreme weather and temperature inversion conditions. 30KM should be very solid if there aren't any external interference issues. Even if you don't "see" adjacent channel (or on-channel) conflicts, there may be something hidden out there affecting performance.
The distance parameter is set to 35 km on both ends
The path is mostly on the sea surface, so for sure temperature/humidity issues have to be taken into account...
The links enda are anyway in the city center, so for sure we have near end obstacles like tree and buildings...
Tried using different channel but no evidence of changes...
Interesting that you are managing successfully 55km links... could you give me an idea of the signal strength and SNR and fading ranges for such links ?
which values of rtt and eventualy packet loss do you have on such links ?
Thanks for support..
Mike
yes I hink o add a shield is for sure a good suggestion.. I should manage to get some of them for our powerbeams...
at preset all our nodes are upgrded to the 3.17.1.0.RC1 SW version....
Signal -77dbm - -75dbm, SNR 18 - 10dbm, TXRate: 19.5Mbps TXMCS:4 RX Rate: 19.5Mbps RXMCS:10
at present here in our mesh we are testing over the sea links because we are around the goulf of Napoli in southern italy... so beeing these links mostly over the sea water we should expect issues depending on the tropo conditions...
at present we have other two links 18Km and 28 Km also experiencing deep fading ... infact to have a stable connection we are using 25db and 30db antennas for these links...
The present link I am discussing about is particularly critical ... we see 20db deeps as you can see in the attached file ( 5min sampling rate for the link) ... the tx speed obviuosly reflect these stuation.. all with a channel width 5Mhz.
mike
They used 2 or 3 transmitter sites on land (can’t recall which it was) to get to Catalina because how frequently the links would go down, and even with the multiple sites they would still have blackouts where they just couldn’t reach the Island because of atmospherics.
I got TX speeds up to 130 Mbps with the 20Mhz and the instrel was always trying to select the SGI but flipping ...
I also did an iperf test across the link and got interesting results: with 20 Mhz troughput was around 400-500 Kbit/sec, whille with 10 Mhz I got around 1 Mbit/sec and with the 5Mhz up to 9 Mbit/sec...
the most stable in terms of RTT and packet loss was the 5 Mhz...
this should be a confirmation that the fat that the optimum setting should be the 5Mhz... maybe this is due to intersymbolic interference due some multipath effect...
nice for the seagulls :) there are a lot here !!!!!
... BTW one of the ends of the link has some big mediterranean pine trees very close... so it is possible that this is creating some strong reflections ....
we will try to move a little bit the installation point in order to see what happens.. in the mean time I will try to get a shield for the PBE ...
hI, the present positioning of the two antennas is on the corner of a building 20 m from the ground...
The main issue is that both ends are in the city center, so there are other building around ; in one case there are some big pines over the path...
The radio mobile simulation, show a clear path if we skip the near end obstacoles; there is no problem for ground curvature.
The sea level heigth is from 100 to 200 m so I do not see at 5Ghz evidence of ocean waves issues ...
BTW the main strangness is the fact that the main component of fading is very very slow... I attach today sample just to show a typical example..