With the capability of using 802.11n now available, what about this scenario?
If we have a mountaintop rocket running the beta (802.11n capable) and it's talking to a mixture of MIMO and SISO devices, does it switch out of 802.11n on a per device basis, stay at the lowest protocol that it's hearing, or stay in 802.11n all the time?
Color me confused...
Thanks.
Orv
W6BI
If we have a mountaintop rocket running the beta (802.11n capable) and it's talking to a mixture of MIMO and SISO devices, does it switch out of 802.11n on a per device basis, stay at the lowest protocol that it's hearing, or stay in 802.11n all the time?
Color me confused...
Thanks.
Orv
W6BI
A node negotiates with each individual node with the fastest rate possible FOR THAT CONNECTION. So, some nodes may connect at slower speeds while others are at high speed.
I am getting up to 40 Mbps throughput indicated in 10 MHz BW.
I am guessing I need to divide by 2 to get the real number? (and 4 for a 5 MHz channel)?
Ken
Note: this are instantaneous values and what is there one second may not be true the next second as the link changes.
I am showing a sustained 40+ (typically 43 and as high as 50.9 in one update). This is one hop from my HD web cam to the tunnel node. That is pretty impressive for 10 MHz ... The camera, however, says it is outputting just over 4 Mbps average.
These are the data rates for the RF encoding. If it were below the camera rate the video would be choppy, if it's above the rate it can send packets over RF faster than the camera generates them leaving room for other unrelated data to be transfered.
This is why most software buffers data before it starts playing as the time to reach you can jump a bit but the packets are still arriving quicker than the buffer is being read so the video is always smooth.
The indicated tx bit rate (and rx bit rate) is 130.0 MBit/s MCS 15 (using "iw").
So what is reported on the mesh status screen is something else - perhaps the actual tx bytes (x8) per unit of time for that link ?
By running the web cam on one node and speedtest on the other node, I saw 50+ Mbps from each node and - adding small amounts on other nodes - the total of all links slightly exceeded 130 (probably due to non-simultaneity).
I should mention that speedtest.net was showing 26/29 Mbps up/down for one (short) hop.
This is an actual throughput so pretty good for 10 MHz and mesh.
Since it is the "other guy's" bit rate, I can also see bit rates for nodes not running this software like the raspberry pi nodes and Linksys. This is a neat feature.
The iw command doesn't take into account the fact that the channels are running smaller RF bandwidths so that 130 is 130/2 = 65mbps.
The screen on the mesh status page also takes into account the percentage of packets that have to be retransmitted as reported by the RF layer (for directed point to point packets its known that on higher speeds some packets will be lost, but loosing 10% of packets when you double the RF speed you still end up with a faster link after retransmission) brining the rate down.
Maybe I found the answer to what this number is that you are reporting - it's from the rc_stats table as described in this link:
https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/ratecontrol/minstrel#theory_of_operation
Prob_success_transmission * Mega bits transmitted throughput = ------------------------------------------------- time for 1 try of 1 packet to be sent on the air1) need sufficient data to characterize the link. Best to not read too much into the number immediately after a reboot.
2) There may be an alternative path OLSR routes traffic over = no data to calculate throughput. Thus, it will say "0" until there is data.
Joe AE6XE
I begin to dig around in the driver source code of the Throughput #s that are being reported and now showing up in Mesh Status. Long story short, we are finding these values to be inconsistent on different bands and hard to compare with a known standard. What I found were these issues:
1) The 802.11 driver source code is NOT calculating throughput on the actual data transmitted. Rather it simply used an estimate of an average packet size of 1200 bytes.
2) The driver does not use the actual time to transmit the packet. Rather it is using an inflated number = (time to transmit a packet + SIFS time): https://en.wikipedia.org/wiki/Short_Interframe_Space
3) The timing is not handled correctly between 5, 10, and 20 Mhz channels (although it still works perfectly fine to select best rate on a given band)
Consequently, I'll be rolling out a change to restate this TxMbps to be based on (EWMA * MCS protocol rate) = (Exponentially Weighted Moving Average of successful xmitted packets * the Modulation Protocol rate). Basically, this will be the raw protocol rate of transmitting bits ~adjusted for loss. This is what the numbers were originally believed to be, but have turned out not to be.
Joe AE6XE
Reading between the lines, the Modulation Protocol will vary from packet to packet depending on what's negotiated between sender and receiver - is that correct?
And slightly off topic, the actual end to end throughput rate will be highly dependent not only on the TxMbps but also on the payload (http, ftp, rtsp, whatever, with its overhead). Again, is that correct?
Thanks.
Orv W6BI
These Software Defined Radios are incredibly smart. The modulation (BPSK, QPSK, 16-PSK, etc.), Forward Error Corrections bits, # of antennas used (unique spatial streams of simultaneous data), and some other items are unique to every neighbor the radio transmits to. As conditions change, the radio keeps statistics and try <10% of look-around packets to measure and select the optimal rates for best throughput to each neighbor.
The "ThroughPut" we are talking about at this level is the entire transmitted "packet", but subtracting out lost packets. The goal is to give a better measure of the quality of the RF links to compare them across channel widths and bands. This is the "Marketing" :) definition of ThroughPut. The # currently showing in 3.16.1.0b1 in mesh status is very poorly meeting this goal. There isn't a perfect # readily defined and available to calculate or pull from. However I've checked in changes in the pipeline that much better represent this throughput. It will be close to the actual data rate, e.g. if we have 95% packet success (5% packet loss) and we are at MCS15 @ 130Mbps, the reported # will be ~123.5Mbps @ 20Mhz (or half this on 10Mhz).
3.16.1.0.b1 also opened up firewall ports to facility installing and running "iperf" between mesh nodes. This definition enables testing user level data throughput at the TCP or UDP protocol level. This is the "Engineer's" or end user's definition of ThroughPut and shows, e.g. how much video streaming data can get through the link.
The updated help.html text:
TxMbps
Transmitted Mbps (TxMbps) is calculated with the formula (TxMbps = rate * EWMA) where rate is the 802.11 data rate in use by the transmitter and EWMA is the Exponentially Weighted Moving Average or the current time weighted chance that a packet at this rate will reach the remote station. If no traffic is being routed to the Neighbor, this value may be '0' until data is available to measure and determine the optimal settings. For further details: http://wireless.wiki.kernel.org/en/developers/documentation/mac80211/rat...