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