Recently i have experienced something quite usual to my experience and that was not happening previously in the same scenario where it is happening now.
Here is the example: 2 nodes at with adhoc at 2.4ghz at a distance of 415 meters one uses an omni 15 dbi antenna at 18dbi and another 24 dbi grid at 16 dbi.
This link was previously providing up to 21 mbit being 17 mbit a the lowest. Batman-adv TQ value was always around 230 being many times above 250.
However this has recently changed the same link with 230~250 TQ and the same txpower is now outputting 1.93 Mbits/sec
I have used iperf for bandwidth tests. Batman-adv version is 2013.4. Although i have considered several types of scenarios that can be causing this issue i have also tested against some which leaves me puzzled in regards to the presented TQ quality and dBm values as the nodes dBm are sometimes bad (ie: -80 ~ -90)
One of the main questions is: shouldn't batman-adv TQ reflect or be influenced by dBm values ? How come with -90 dBm i get batman-adv to show me 230 TQ ?
Also any feedback based on your experience regarding this type of scenario is welcome. This situation happened overnight without any access point new configurations or physical setup changes.
Recently i have experienced something quite usual to my experience and that was not happening previously in the same scenario where it is happening now.
Here is the example: 2 nodes at with adhoc at 2.4ghz at a distance of 415 meters one uses an omni 15 dbi antenna at 18dbi and another 24 dbi grid at 16 dbi.
This link was previously providing up to 21 mbit being 17 mbit a the lowest. Batman-adv TQ value was always around 230 being many times above 250.
However this has recently changed the same link with 230~250 TQ and the same txpower is now outputting 1.93 Mbits/sec
I have used iperf for bandwidth tests. Batman-adv version is 2013.4. Although i have considered several types of scenarios that can be causing this issue i have also tested against some which leaves me puzzled in regards to the presented TQ quality and dBm values as the nodes dBm are sometimes bad (ie: -80 ~ -90)
One of the main questions is: shouldn't batman-adv TQ reflect or be influenced by dBm values ? How come with -90 dBm i get batman-adv to show me 230 TQ ?
The current implementation in batman-adv counts broadcast packets to compute the TQ. Therefore this number reflects (more or less) the transmit success probability on whatever wifi broadcast modulation rate you have configured (default the lowest, e.g. 1M in 2.4 GHz). A common tweak is to set the broadcast rate (also called multicast rate) to something higher, e.g. 18M or 36M, to get a better analysis on these modulation rates. This should also help in your scenario, but might affect the range of your batman-adv network.
Cheers, Simon
Hi,
I would like to add some additional insights I gained while working on my bachelor thesis (which of course used batman :D ).
The dBm you see is the power at which packets are received (Prx). The value of Prx depends on a lot of factors, primarily distance and interferrence caused by re/deflections [1]. There is a minimum Prx at which the signal must arrive in order for your Wi-Fi module to be able to see it as a proper signal rather than noise. This minimum, combined with (thermal) noise (N) gives you a signal-to-noise ratio, which should at least be about 15 dB (SNR = Prx - N >= 15). N is usually somewhere around -100 dBm, meaning that a Prx of about -85 dBm is generally the minimum you need for succesful transmissions. Note that these numbers don't take into account any antennae you might be using, these are only really relevant for calculating the Prx. A higher number means the signal is clearer, but that's really all it means. Because the Prx can only be determined if a packet arrives, the number in itself is meaningless without a time reference, which in turn would only indicate when the last packet was received.
Like Simon said, the transmission quality batman-adv returns is based on the probability of packets arriving properly on the other side of the Wi-Fi link. Batman-adv uses counters to determine how many packets were lost and as a result gives a more informative view of how well the link behaves. Because the counters are based on packet reception, this means the Prx also has to be above the minimum.
In summary: high dBm = the things that are received, are received very clearly high TQ = nearly everything you send is received. High chance of proper reception => less retransmissions => higher throughput => happy you.
[1]: http://en.wikipedia.org/wiki/Path_loss
* Thijs van Veen dicht@operamail.com [24.04.2014 14:45]:
N is usually somewhere around -100 dBm, meaning that a Prx of about -85
unsure about that: it depends on the WiFi-receiver's quality, isn't it?
when i use 'iwinfo' the noise is always '-95', no matter on which location. it seems to come from nl80211_get_noise() but i dont understand it fully.
or do i mix something up? bye, bastian
It depends a bit on the receiver's quality, I've had experiences where the SNR could drop to about 8 and the link would still somewhat work.
The thermal noise is mostly intrinsic to how energy relates at a particle level, this is denoted by the Boltzmann constant (k). Further, it depends on the bandwidth (B) used and temperature (T). Nthermal = B * k * T = 20*10^6 Hz (802.11 channel) * 1.38065*10^-23 J/K * 300 K (27 Celsius) ~= 8.28 * 10^-11 This gives the noise in Watts, to change it to dBm (which references miliWatts), you take 10*log10( N * 1000 ) ~= -100. [1] Has a nice table with examples of this noise.
In reality, there's more interference than just from the temperature. It's quite probable your receiver adds another 5 dBm to its reported noise to account for this. I also recall from my time working on my thesis that receivers/drivers tend to return a static value for noise, rather than actually measure it.
[1]:http://en.wikipedia.org/wiki/Thermal_noise#Noise_power_in_decibels
Inline reply
On 04/24/2014 05:48 AM, Simon Wunderlich wrote:
Recently i have experienced something quite usual to my experience and that was not happening previously in the same scenario where it is happening now.
Here is the example: 2 nodes at with adhoc at 2.4ghz at a distance of 415 meters one uses an omni 15 dbi antenna at 18dbi and another 24 dbi grid at 16 dbi.
This link was previously providing up to 21 mbit being 17 mbit a the lowest. Batman-adv TQ value was always around 230 being many times above 250.
However this has recently changed the same link with 230~250 TQ and the same txpower is now outputting 1.93 Mbits/sec
I have used iperf for bandwidth tests. Batman-adv version is 2013.4. Although i have considered several types of scenarios that can be causing this issue i have also tested against some which leaves me puzzled in regards to the presented TQ quality and dBm values as the nodes dBm are sometimes bad (ie: -80 ~ -90)
One of the main questions is: shouldn't batman-adv TQ reflect or be influenced by dBm values ? How come with -90 dBm i get batman-adv to show me 230 TQ ?
The current implementation in batman-adv counts broadcast packets to compute the TQ. Therefore this number reflects (more or less) the transmit success probability on whatever wifi broadcast modulation rate you have configured (default the lowest, e.g. 1M in 2.4 GHz). A common tweak is to set the broadcast rate (also called multicast rate) to something higher, e.g. 18M or 36M, to get a better analysis on these modulation rates. This should also help in your scenario, but might affect the range of your batman-adv network.
what's the mcast_rate value? having 230~250 TQ on a -80/-90dBm link seems like you have a very low mcast_rate.
I did try change the mcast_rate as well as the rate and while at first it did show some gains the same did not maintained after a few days.
dbm levels and throughput have not changed and in fact in a few cases my throughput got worse.
I tried with 36000 as well as 6000
I am now believing 2 possible scenarios:
1: Software/driver problems or bug a) big or weak support that only came into effect after playing wit firmware settings. (re-flashing the routers without new or the same firmware should clear this doubt)
2: Interference caused by: a) weather conditions that have changed since the nodes lost huge performance levels. b) Although i am able to have the local community cooperation by having them changing their home routers to non overlapping frequencies i wonder how much of it can be caused by the network nodes and their co-existent channels. Then again this does nto explain why the loss of performance did not happened right away after the network upgrade.
However all these possibilities do not answer the fact that these nodes worked flawlessly for some time and one day overnight the problem happened.
c) deliberate interference caused by some possible competitor. although i cannot be sure at this moment; i see it as the biggest possibility.
In the past this has led me to look for this: https://lists.openwrt.org/pipermail/openwrt-users/2013-April/002420.html which keeps me thinking about Wi-Spy + Chanalyzer or equivalent if any.
Which i am currently, once again very included to do and suggestions/alternatives are welcome as well as wanted.
b.a.t.m.a.n@lists.open-mesh.org
-
Bastian Bittorf -
cmsv -
Simon Wunderlich -
Thijs van Veen