[B.A.T.M.A.N.] Batman-adv high TQ and Low throughput

[B.A.T.M.A.N.] Batman-adv high TQ and Low throughput

[cmsv]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

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.






-- 


Site: http://wirelesspt.net
Mesh: http://tinyurl.com/wirelesspt
Admin: http://wirelesspt.net/wiki/Cmsv
Twitter: http://twitter.com/wirelesspt
Youtube: https://youtube.com/wirelesspt
Facebook: https://www.facebook.com/wirelesspt
Suporte técnico via sms: 91 19 11 798
Donativos/Paypal: http://tinyurl.com/doar-verba
Chave publica PGP/SSH: http://wirelesspt.net/arquivos/pk
Email ao abrigo de: https://creativecommons.org/licenses/by-nc-sa/3.0/pt/


[-- Attachment #2: 0x15C4B382.asc --]
[-- Type: application/pgp-keys, Size: 36238 bytes --]

Re: [B.A.T.M.A.N.] Batman-adv high TQ and Low throughput

[Simon Wunderlich]

> 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

Re: [B.A.T.M.A.N.] Batman-adv high TQ and Low throughput

[Thijs van Veen]

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


On Thu, Apr 24, 2014, at 11:48, 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.
> 
> Cheers,
>     Simon

-- 
http://www.fastmail.fm - Choose from over 50 domains or use your own

Re: [B.A.T.M.A.N.] [Battlemesh] Batman-adv high TQ and Low throughput

[Bastian Bittorf]

* 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

Re: [B.A.T.M.A.N.] [Battlemesh] Batman-adv high TQ and Low throughput

[Thijs van Veen]

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

-- 
  Thijs van Veen
  dicht@operamail.com


On Thu, Apr 24, 2014, at 14:58, Bastian Bittorf wrote:
> * 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

-- 
http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again

Re: [B.A.T.M.A.N.] Batman-adv high TQ and Low throughput

[cmsv]

[-- Attachment #1.1: Type: text/plain, Size: 3530 bytes --]

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.














[-- Attachment #1.2: 0x15C4B382.asc --]
[-- Type: application/pgp-keys, Size: 36799 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [B.A.T.M.A.N.] [OpenWrt-Users] [Battlemesh] Batman-adv high TQ and Low throughput

[cmsv]

[-- Attachment #1: Type: text/plain, Size: 13677 bytes --]

Hello Ben

Last night i decreased all the network access points  to 17 dBm thinking
if my problem is due too much noise from co-existent channels from same
network nodes and unless i my conclusion is wrong i do not think the
Ap's cause problems to each other because after the decrease in txpower;
not only batman-adv TQ got lower as well as dBm and throughput. In other
words there was no improvement and this is not the first time i try the
sort of test.

Today i reverted to normal higher values and things improved but still
far from whet they were when the nodes were upgraded.

I will describe the situation i have with 2 of the 3 access points.
They all run ath9k on one radio with vap interfaces.



AP (A) uses a 15 dbi omni Atheros AR9132 rev 2
AP (B) uses a 8 dbi omni Atheros AR7240 rev 2

Distance from each other is about 100 metres.
Right now AP A is at 20 dbm and AP B at 19 dBm

From AP (B) to AP (A) i get:

Station AP (B) (on adhoc0)
	inactive time:	20 ms
	rx bytes:	1087140
	rx packets:	9708
	tx bytes:	906
	tx packets:	7
	tx retries:	14
	tx failed:	2
	signal:  	-49 [-49, -58] dBm
	signal avg:	-49 [-49, -58] dBm
	tx bitrate:	2.0 MBit/s
	rx bitrate:	1.0 MBit/s
	authorized:	yes
	authenticated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no


Batman-adv TQ at 91 and with a hop in the middle. Without the hop
batman-adv does not even see AP (A). The hop has a penalty of 150.

iperf reports:
0.0-10.3 sec  7.38 MBytes  6.02 Mbits/sec

However batman-adv chooses another gateway which is further away but doe
not have a hop and gets less throughput


and continues to

	inactive time:	30 ms
	rx bytes:	4320939
	rx packets:	40264
	tx bytes:	2561
	tx packets:	18
	tx retries:	55
	tx failed:	9
	signal:  	-59 [-59, -68] dBm
	signal avg:	-58 [-59, -67] dBm
	tx bitrate:	2.0 MBit/s
	rx bitrate:	1.0 MBit/s

From AP (A) to AP (B)


Station AP (A) (on adhoc0)
	inactive time:	1110 ms
	rx bytes:	106752
	rx packets:	629
	tx bytes:	1753
	tx packets:	13
	tx retries:	70
	tx failed:	5
	signal:  	-91 [-94, -111, -93] dBm
	signal avg:	-89 [-93, -107, -91] dBm
	tx bitrate:	6.5 MBit/s MCS 0
	rx bitrate:	6.0 MBit/s
	authorized:	yes
	authenticated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no


Batman-adv TQ at  101 with the same hop in the middle
iperf reports  7.38 MBytes  6.11 Mbits/sec


And this is somewhat an okay scenario since this link was at 17 dBm from
AP (B) providing 15 mbit and with a TQ of 250 average.

Usually i get tx and rx  bitrate around 1mbit from AP (A) side.

There is a huge discrepancy here with link quality and how batman-adv is
doing the choice as well as signal and signal average.

Before Both sides were around -50 dBm in average but now  AP (A) is
always around -80 and worse.

Notice that these results are only possible due to the existence of  a
middle node that was setup  as a backup.
Without the middle node AP (A) does not see AP (B).

I am inclined to think about a driver issue that got into play after i
played with some configurations. I see this as a possibility for the
tp-link routers i have in the mesh as the dlinks seem to perform better.

and continues to

	inactive time:	1730 ms
	rx bytes:	186480
	rx packets:	1303
	tx bytes:	2381
	tx packets:	17
	tx retries:	92
	tx failed:	8

Some more info bellow from AP (A)


Wireless kernel debug

Reset:
    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
     TX Path Hang:  0
      PLL RX Hang:  0
        MCI Reset:  0

Ani:
            ANI: ENABLED
      ANI RESET: 175
        SPUR UP: 37
      SPUR DOWN: 37
 OFDM WS-DET ON: 0
OFDM WS-DET OFF: 0
     MRC-CCK ON: 0
    MRC-CCK OFF: 0
    FIR-STEP UP: 27
  FIR-STEP DOWN: 49
 INV LISTENTIME: 0
    OFDM ERRORS: 192247
     CCK ERRORS: 200380

Interrupt:
                   RX:    2352822
                RXEOL:          0
                RXORN:          0
                   TX:     498420
                TXURN:          0
                  MIB:          0
                RXPHY:          0
                RXKCM:          0
                 SWBA:    2634014
                BMISS:          0
                  BNR:          0
                  CST:        788
                  GTT:      34321
                  TIM:          0
               CABEND:          0
             DTIMSYNC:          0
                 DTIM:          0
               TSFOOR:          0
                  MCI:          0
             GENTIMER:          0
                TOTAL:    5313102
SYNC_CAUSE stats:
             Sync-All:    5165669
              RTC-IRQ:    2863390
              MAC-IRQ:    4227348
EEPROM-Illegal-Access:    2837451
          APB-Timeout:      57826
    PCI-Mode-Conflict:      57422
          HOST1-Fatal:      43642
           HOST1-Perr:      66006
       TRCV-FIFO-Perr:      92477
          RADM-CPL-EP:      58826
  RADM-CPL-DLLP-Abort:      60567
   RADM-CPL-TLP-Abort:      51149
    RADM-CPL-ECRC-Err:      54651
     RADM-CPL-Timeout:      89152
    Local-Bus-Timeout:      69195
            PM-Access:      80875
            MAC-Awake:     104915
           MAC-Asleep:     137511
     MAC-Sleep-Access:     761892

Dma:
Raw DMA Debug values:

0: 88888888 1: 00000000 2: 12249249 3: 00000000
4: 00000000 5: 00000000 6: 001d264c 7: 000281c0

Num QCU: chain_st fsp_ok fsp_st DCU: chain_st
 0           0      1      1            0
 1           0      1      1            0
 2           0      1      1            0
 3           0      1      1            0
 4           0      1      1            0
 5           0      1      1            0
 6           0      1      1            0
 7           0      1      1            0
 8           0      0      1            0
 9           0      0      1            0

qcu_stitch state:    0    qcu_fetch state:         0
qcu_complete state:  0    dcu_complete state:      0
dcu_arb state:       0    dcu_fp state:            0
chan_idle_dur:     147    chan_idle_dur_valid:     1
txfifo_valid_0:      0    txfifo_valid_1:          0
txfifo_dcu_num_0:    9    txfifo_dcu_num_1:       14
pcu observe: 0x2890
AR_CR: 0x4

Xmit:
                            BE         BK        VI        VO

MPDUs Queued:             5747          0         0      7405
MPDUs Completed:        137383          0         0      4183
MPDUs XRetried:           7730          0         0      3222
Aggregates:              17209          0         0         0
AMPDUs Queued HW:            0          0         0         0
AMPDUs Queued SW:       308165          0         0         0
AMPDUs Completed:       168767          0         0         0
AMPDUs Retried:          12546          0         0         0
AMPDUs XRetried:            32          0         0         0
TXERR Filtered:              3          0         0         0
FIFO Underrun:               0          0         0         0
TXOP Exceeded:               0          0         0         0
TXTIMER Expiry:              0          0         0         0
DESC CFG Error:              0          0         0         0
DATA Underrun:               0          0         0         0
DELIM Underrun:              0          0         0         0
TX-Pkts-All:            313912          0         0      7405
TX-Bytes-All:        161389767          0         0    233291
HW-put-tx-buf:              12          0         0       146
HW-tx-start:            262235          0         0      7405
HW-tx-proc-desc:        262416          0         0      7405
TX-Failed:                   0          0         0         0

Queues:
(VO):  qnum: 0 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(VI):  qnum: 1 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BE):  qnum: 2 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BK):  qnum: 3 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(CAB): qnum: 8 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0


On 04/30/2014 10:00 PM, Ben West wrote:
> What does "iw wlan0 station dump" have to say?  In particular, what is
> the ratio of TX packets to TX retries (or failures)?
> 
> I've generally seen 10% TX retries, compared to total TX packets, to be
> quite ideal.  A substantially higher percentage of TX retries,
> especially if over 100%, usually indicates a problem with noise or
> interference.
> 
> 
> On Wed, Apr 30, 2014 at 6:57 PM, cmsv <cmsv@wirelesspt.net
> <mailto:cmsv@wirelesspt.net>> wrote:
> 
>     inline reply
> 
>     On 04/24/2014 05:27 AM, Nicolás Echániz wrote:
>     > El 24/04/14 05:34, cmsv escribió:
>     >> 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.
> 
>     > 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 have always used the driver default setup to decide the bitrate and
>     that worked up to a certain moment. Specifying it did not do much better
>     but today i found this message
> 
>     ath: phy0: unsupported hw bitrate detected 0x1f using 1 Mbit
> 
>     Currently:
>     wireless.@wifi-iface[0].mcast_rate=6000
> 
>     and i tested with up to 36000
> 
>     But i have also gotten the unsupported hw bitrate message without
>     setting mcast_rate
> 
>     iwinfo reports:
>               Tx-Power: 19 dBm  Link Quality: 36/70
>               Signal: -74 dBm  Noise: -95 dBm
>               Bit Rate: 29.7 MBit/s
>               Encryption: WPA PSK (CCMP)
>               Type: nl80211  HW Mode(s): 802.11bgn
>               Hardware: unknown [Generic MAC80211]
>               TX power offset: unknown
>               Frequency offset: unknown
>               Supports VAPs: yes
> 
>     iw reports:
> 
>     Frequencies:
>                             * 2412 MHz [1] (20.0 dBm)
>                             * 2417 MHz [2] (20.0 dBm)
>                             * 2422 MHz [3] (20.0 dBm)
>                             * 2427 MHz [4] (20.0 dBm)
>                             * 2432 MHz [5] (20.0 dBm)
>                             * 2437 MHz [6] (20.0 dBm)
>                             * 2442 MHz [7] (20.0 dBm)
>                             * 2447 MHz [8] (20.0 dBm)
>                             * 2452 MHz [9] (20.0 dBm)
>                             * 2457 MHz [10] (20.0 dBm)
>                             * 2462 MHz [11] (20.0 dBm)
>                             * 2467 MHz [12] (20.0 dBm)
>                             * 2472 MHz [13] (20.0 dBm)
>                             * 2484 MHz [14] (disabled)
> 
>     And o notice that i am at the moment unable to set 20dBm unless i
>     re-flash the device.
> 
>     wireless.radio0.htmode=HT20
> 
>                     Bitrates (non-HT):
>                             * 1.0 Mbps
>                             * 2.0 Mbps (short preamble supported)
>                             * 5.5 Mbps (short preamble supported)
>                             * 11.0 Mbps (short preamble supported)
>                             * 6.0 Mbps
>                             * 9.0 Mbps
>                             * 12.0 Mbps
>                             * 18.0 Mbps
>                             * 24.0 Mbps
>                             * 36.0 Mbps
>                             * 48.0 Mbps
>                             * 54.0 Mbps
> 
>     I also tested while removing HT functionality but without better results
> 
>     Horst shows;
>     91% usage for 1M rate
>     3.4% usage for 6M rate
>     4% usage for 36M rate
> 
>     another node shows me :
>     ath: phy0: unsupported hw bitrate detected 0x33 using 1 Mbit
> 
>     Chips in at the moment in use: Atheros AR9130 rev 2 and Atheros
>     AR9132 rev 2
> 
>     So far it looks like a i have a bug according to atheros mailing lists
>      _______________________________________________
>     > Battlemesh mailing list
>     > Battlemesh@ml.ninux.org <mailto:Battlemesh@ml.ninux.org>
>     > http://ml.ninux.org/mailman/listinfo/battlemesh
>     >
> 
>     _______________________________________________
>     openwrt-users mailing list
>     openwrt-users@lists.openwrt.org <mailto:openwrt-users@lists.openwrt.org>
>     https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
> 
> 
> 
> 
> -- 
> Ben West
> http://gowasabi.net
> ben@gowasabi.net <mailto:ben@gowasabi.net>
> 314-246-9434

[-- Attachment #2: 0x15C4B382.asc --]
[-- Type: application/pgp-keys, Size: 36238 bytes --]