From: cmsv <cmsv@wirelesspt.net>
To: Ben West <ben@gowasabi.net>,
OpenWrt User List <openwrt-users@lists.openwrt.org>,
The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Cc: Felix Fietkau <nbd@openwrt.org>, battlemesh <battlemesh@ml.ninux.org>
Subject: Re: [B.A.T.M.A.N.] [OpenWrt-Users] [Battlemesh] Batman-adv high TQ and Low throughput
Date: Fri, 02 May 2014 10:30:08 -0400 [thread overview]
Message-ID: <5363ABF0.4030504@wirelesspt.net> (raw)
In-Reply-To: <CADSh-SOhXxvhV1_mMPcfQJAPxaRMpsTqCgnP7k4P0firBH4ZiA@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2014-05-02 14:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-24 8:34 [B.A.T.M.A.N.] Batman-adv high TQ and Low throughput cmsv
2014-04-24 9:48 ` Simon Wunderlich
2014-04-24 11:57 ` Thijs van Veen
2014-04-24 12:58 ` [B.A.T.M.A.N.] [Battlemesh] " Bastian Bittorf
2014-04-24 13:38 ` Thijs van Veen
2014-04-30 14:24 ` [B.A.T.M.A.N.] " cmsv
[not found] ` <5358D919.3010700@altermundi.net>
[not found] ` <53618E04.2010404@wirelesspt.net>
[not found] ` <CADSh-SOhXxvhV1_mMPcfQJAPxaRMpsTqCgnP7k4P0firBH4ZiA@mail.gmail.com>
2014-05-02 14:30 ` cmsv [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5363ABF0.4030504@wirelesspt.net \
--to=cmsv@wirelesspt.net \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=battlemesh@ml.ninux.org \
--cc=ben@gowasabi.net \
--cc=nbd@openwrt.org \
--cc=openwrt-users@lists.openwrt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.