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

cmsv cmsv at wirelesspt.net
Fri May 2 16:30:08 CEST 2014


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 at wirelesspt.net
> <mailto:cmsv at 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. at 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 at ml.ninux.org <mailto:Battlemesh at ml.ninux.org>
>     > http://ml.ninux.org/mailman/listinfo/battlemesh
>     >
> 
>     _______________________________________________
>     openwrt-users mailing list
>     openwrt-users at lists.openwrt.org <mailto:openwrt-users at lists.openwrt.org>
>     https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
> 
> 
> 
> 
> -- 
> Ben West
> http://gowasabi.net
> ben at gowasabi.net <mailto:ben at gowasabi.net>
> 314-246-9434
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x15C4B382.asc
Type: application/pgp-keys
Size: 36238 bytes
Desc: not available
URL: <http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/attachments/20140502/82c20db5/attachment-0001.key>


More information about the B.A.T.M.A.N mailing list