[Battlemesh] [OpenWrt-Users] 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://ml.ninux.org/pipermail/battlemesh/attachments/20140502/82c20db5/attachment-0002.key>
More information about the Battlemesh
mailing list