Hostapd, wireless latency and configuration issues

As discussed before on the list, I've installed a PCI Express 802.11a/b/g/n card to serve as my wireless access point, employing an Atheros 9300 controller. I'm encountering high latency and jitter when I ping any device on the wireless network (i.e., my laptop and a new Android phone). I also discovered that, as reported on various Web sites, the Intel iwl5100/5300 controller in my laptop isn't very reliable under 802.11n. Using the firmware for the card provided at wireless.kernel.org rather than that in the Debian firmware-iwlwifi package yields more reliable throughput however, and seems to reduce the incidence of failure to associate with the access point. Also, it isn't clear to me how best to configure the ht_capab option in /etc/hostapd/hostapd.conf. For the moment, I've copied a sample line published in a post by another user of the same card: ht_capab=[HT40-][HT40+][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40][LDPC] but naturally I would rather know what I ought to do in this regard. Any suggestions about the latency problems would be welcome as well as general configuration advice. It should be noted that others using the same hardware don't appear to be encountering issues, judging by various blog posts. The kernel here is 3.10-2 from the Debian package currently in Sid.

Jason White <jason@jasonjgw.net> writes:
Also, it isn't clear to me how best to configure the ht_capab option in /etc/hostapd/hostapd.conf. For the moment, I've copied a sample line published in a post by another user of the same card: ht_capab=[HT40-][HT40+][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40][LDPC] but naturally I would rather know what I ought to do in this regard.
I'm afraid I don't remember ever touching an option like that, when I was fiddling with hostapd. Mine apparently is using root@widow:~# grep capab /var/run/hostapd-phy0.conf ht_capab=[HT20][SHORT-GI-40][DSSS_CCK-40] To me, it looks similar to an SSL allowed ciphers list, so I suggest listing only the entries you actually need/use. You can hopefully find that out by removing things and seeing what breaks, although ISTR I also resorted to reading the hostapd source for the poorly-documented sections. Wikipedia is probably also useful if those are standard codecs (which, presumably, they must be).

Jason White <jason@jasonjgw.net> writes: A quick look at OpenWRT's sources (/lib/wifi/mac80211.sh) show how to find out what caps your card+driver has: root@widow:~# iw phy phy0 info | grep Capabilities: Capabilities: 0x104e ...which is a XORed list 1 LDPC 16 GF 32 SHORT-GI-20 64 SHORT-GI-40 128 TX-STBC 768 RX-STBC1 768 RX-STBC12 768 RX-STBC123 4096 DSSS_CCK-40 LDPC = https://en.wikipedia.org/wiki/Low-density_parity-check_code GI = https://en.wikipedia.org/wiki/Guard_interval STBC = https://en.wikipedia.org/wiki/Space–time_block_code DSSS = https://en.wikipedia.org/wiki/DSSS CCK = https://en.wikipedia.org/wiki/Complementary_code_keying

Trent W. Buck <trentbuck@gmail.com> wrote:
Jason White <jason@jasonjgw.net> writes:
A quick look at OpenWRT's sources (/lib/wifi/mac80211.sh) show how to find out what caps your card+driver has:
root@widow:~# iw phy phy0 info | grep Capabilities: Capabilities: 0x104e
...which is a XORed list
Thanks. This is exactly what I needed. Mine gives 0x11ef 0001000111101111 if I remember my number bases correctly. Now given your list: 1 LDPC yes 16 GF no 32 SHORT-GI-20 yes 64 SHORT-GI-40 yes 128 TX-STBC yes 768 RX-STBC1 no 768 RX-STBC12 no 768 RX-STBC123 no 4096 DSSS_CCK-40 yes

Is it possible the devices you are pinging are sleeping using wireless power management? http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions This will cause devices to deliberately turn off the radio and ask the AP to queue packets until they poll. On Tuesday, September 3, 2013, Jason White wrote:
Trent W. Buck <trentbuck@gmail.com <javascript:;>> wrote:
Jason White <jason@jasonjgw.net <javascript:;>> writes:
A quick look at OpenWRT's sources (/lib/wifi/mac80211.sh) show how to find out what caps your card+driver has:
root@widow:~# iw phy phy0 info | grep Capabilities: Capabilities: 0x104e
...which is a XORed list
Thanks. This is exactly what I needed.
Mine gives 0x11ef
0001000111101111 if I remember my number bases correctly.
Now given your list: 1 LDPC yes 16 GF no 32 SHORT-GI-20 yes 64 SHORT-GI-40 yes 128 TX-STBC yes 768 RX-STBC1 no 768 RX-STBC12 no 768 RX-STBC123 no 4096 DSSS_CCK-40 yes
_______________________________________________ luv-main mailing list luv-main@luv.asn.au <javascript:;> http://lists.luv.asn.au/listinfo/luv-main

Noah O'Donoghue <noah.odonoghue@gmail.com> wrote:
Is it possible the devices you are pinging are sleeping using wireless power management?
http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions
This will cause devices to deliberately turn off the radio and ask the AP to queue packets until they poll.
The Android phone might be doing so. I don't think the laptop has it enabled, however. It reports large numbers of excessive retransmissions.

What if you ping the wireless AP from one of the devices on the wireless side? On 3 September 2013 20:14, Jason White <jason@jasonjgw.net> wrote:
Noah O'Donoghue <noah.odonoghue@gmail.com> wrote:
Is it possible the devices you are pinging are sleeping using wireless power management?
http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions
This will cause devices to deliberately turn off the radio and ask the AP to queue packets until they poll.
The Android phone might be doing so. I don't think the laptop has it enabled, however. It reports large numbers of excessive retransmissions.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
participants (3)
-
Jason White
-
Noah O'Donoghue
-
trentbuck@gmail.com