[Battlemesh] [B.A.T.M.A.N.] [OpenWrt-Users] Batman-adv high TQ and Low throughput
dan
dandenson at gmail.com
Wed Sep 3 19:30:09 UTC 2014
Justin chiming in here on the wireless aspect of the question (wISP here).
I highly suspect that you have something new in the area reflecting the
wireless signal. When you are transmitting very low throughput, the
reflections don't appear very strong and you can get a very good service at
that speed. If you then start pushing a lot of throughput across the link,
the reflections overtake the signal and your throughput plummets.
Since the TQ is calculated from small broadcast packets, they will use the
link lightly and the reflections wont cause big issues. This is a downside
of how 802.11 radios work. The radios only transmit where there is data to
be transmitted, so when the data is light the link doesn't suffer any of
the typical fresnel zone infraction and reflection issues.
This would be my first educated guess at what's causing your issue.
Nothing really to do with batman-adv, just a pitfall of wifi.
On Fri, May 2, 2014 at 8:30 AM, cmsv <cmsv at wirelesspt.net> wrote:
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20140903/e0dd5a36/attachment-0001.htm>
More information about the Battlemesh
mailing list