Hi,
I'm currently experimenting with ath5k of kernel 2.6.33 in our
mesh network. We, were previously using madwifi in "ahdemo" mode,
which worked reasonably well.
Now, after working around various pitfalls (e.g. BSSID merging,
still does not work reliable for us!,)
It somehow "works", but I'm occasionally seeing huge latency issues:
with ping times in the order of 30-50 seconds over a 2-3 hop path.
(e.g.:)
64 bytes from 169.254.9.47: icmp_seq=1812 ttl=62 time=34703 ms
64 bytes from 169.254.9.47: icmp_seq=1813 ttl=62 time=33782 ms
64 bytes from 169.254.9.47: icmp_seq=1814 ttl=62 time=32803 ms
64 bytes from 169.254.9.47: icmp_seq=1815 ttl=62 time=31804 ms
64 bytes from 169.254.9.47: icmp_seq=1816 ttl=62 time=30810 ms
64 bytes from 169.254.9.47: icmp_seq=1817 ttl=62 time=29814 ms
64 bytes from 169.254.9.47: icmp_seq=1818 ttl=62 time=28815 ms
I noticed that some qdisc queues fill up to pretty high values.
e.g.:
hannem...@mrouter9:~ $ tc -s qdisc
[...]
qdisc pfifo_fast 0: dev ath0 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1
1 1 1 1 1 1
Sent 255864 bytes 3034 pkt (dropped 0, overlimits 0 requeues 186)
backlog 22416b 265p requeues 186
At the same time there is no reasonable traffic that justifies this high
backlog.
I'm not yet sure, but it may be related to this message in dmesg:
[ 3681.006797] ath5k phy0: no further txbuf available, dropping packet
When the queue "gets stuck" no communication with this particular node is
possible.
If I perform a ping on that node to another node, I can watch the backlog to
increase
packet by packet[1]. Usually, at some time the queue gets suddenly "flushed"
and communication is restored. However, right now I have a node where this
situation
persists for several minutes now...
Any idea how to debug this problem further?
Anyone using ath5k successfully in IBSS mode, for more than a bunch of nodes?
[1] note that I'm using static arp entries...
FYI:
[ 27.141256] ath5k 0000:00:0c.0: registered as 'phy0'
[ 27.623005] ath: EEPROM regdomain: 0x0
[ 27.623023] ath: EEPROM indicates default country code should be used
[ 27.623043] ath: doing EEPROM country->regdmn map search
[ 27.623066] ath: country maps to regdmn code: 0x3a
[ 27.623084] ath: Country alpha2 being used: US
[ 27.623099] ath: Regpair used: 0x3a
[ 27.777749] ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
[ 27.777749] ath5k phy0: RF5112B multiband radio found (0x36)
00:0c.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213
Multiprotocol MAC/baseband processor (rev 01)
Subsystem: Wistron NeWeb Corp. CM9 Wireless a/b/g MiniPCI Adapter
Flags: bus master, medium devsel, latency 168, IRQ 9
Memory at e0040000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Best regards.
Arnd
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
