[ath9k-devel] Stable Version for ath9k_htc in AP Mode?

[Oleksij Rempel <linux@rempel-privat.de>]

Am 09.05.2014 00:57, schrieb Aaron Hamilton:
> Did further testing and we still seem to have issues with clients
> connecting. Here's our scenario:
> 
> ** Problem 1 - Extreme Latency **
> 
> 1) Connect a Panasonic Toughbook laptop to the WiFi AP. Connection
> appears to come up without any issues. We initiate ongoing pings to
> the computer from the AP with consistent 3ms to 10ms responses.
> 
> 2) Connect an embedded device to the AP (dnsmasq reports vendor class
> udhcp 1.18.5). When we initiate pings from the AP to the device,
> responses take between 500ms and 1000ms.
> 
> We then powered down both client devices and reconnected only the
> embedded client. This time the pings started at 32ms and increased in
> latency for every subsequent ping. The following is a capture from the
> AP. It appears as though each subsequent ping is further delayed by
> approximately 20ms. During this time, only the one client is
> connected. Also, the only traffic coming across the interface are
> pings, which leads me to believe this is not a bandwidth problem.

I'm 100% sure, it is about bandwidth.
Right now i did test with one AP (ath9k_htc) + 2 STAs.
AR9271 adapter is connected to USB 2.0 in high speed mode.

Ping test:
- both STAs provide stable PING with ~2ms if they are in one room.
- After one STA was moved behind two walls it got less stable ping which
was variating 2-100ms.

Bench test:
- Each STA run two stream netperf. AP is in HT20 since there is another
AP with HT40 in same room.
- The STA behind two walls had almost no chance. It got some 100KB/s
- The closest STA had about 4MB/s

Well, for this kind of device it is acceptable:
https://wikidevi.com/wiki/ThinkPenguin_TPE-N150USB

> # ping 192.168.2.192
> PING 192.168.2.192 (192.168.2.192): 56 data bytes
> 64 bytes from 192.168.2.192: seq=32 ttl=64 time=32.043 ms
> 64 bytes from 192.168.2.192: seq=33 ttl=64 time=155.090 ms
> 64 bytes from 192.168.2.192: seq=34 ttl=64 time=1013.031 ms
> 64 bytes from 192.168.2.192: seq=35 ttl=64 time=21.302 ms
> 64 bytes from 192.168.2.192: seq=36 ttl=64 time=6.622 ms
> 64 bytes from 192.168.2.192: seq=37 ttl=64 time=8.240 ms
> 64 bytes from 192.168.2.192: seq=38 ttl=64 time=79.743 ms
> 64 bytes from 192.168.2.192: seq=39 ttl=64 time=103.089 ms
> 64 bytes from 192.168.2.192: seq=40 ttl=64 time=121.613 ms
> 64 bytes from 192.168.2.192: seq=41 ttl=64 time=143.677 ms
> 64 bytes from 192.168.2.192: seq=42 ttl=64 time=167.053 ms
> 64 bytes from 192.168.2.192: seq=43 ttl=64 time=190.735 ms
> 64 bytes from 192.168.2.192: seq=44 ttl=64 time=215.027 ms
> 64 bytes from 192.168.2.192: seq=45 ttl=64 time=236.206 ms
> 64 bytes from 192.168.2.192: seq=46 ttl=64 time=259.461 ms
> 64 bytes from 192.168.2.192: seq=47 ttl=64 time=283.142 ms
> 64 bytes from 192.168.2.192: seq=48 ttl=64 time=302.704 ms
> 64 bytes from 192.168.2.192: seq=49 ttl=64 time=325.379 ms
> 64 bytes from 192.168.2.192: seq=50 ttl=64 time=364.105 ms
> 64 bytes from 192.168.2.192: seq=51 ttl=64 time=372.955 ms
> 64 bytes from 192.168.2.192: seq=52 ttl=64 time=394.073 ms
> 64 bytes from 192.168.2.192: seq=53 ttl=64 time=433.075 ms
> 64 bytes from 192.168.2.192: seq=54 ttl=64 time=436.615 ms
> 64 bytes from 192.168.2.192: seq=55 ttl=64 time=462.372 ms
> 64 bytes from 192.168.2.192: seq=56 ttl=64 time=484.283 ms
> 64 bytes from 192.168.2.192: seq=57 ttl=64 time=510.132 ms
> 64 bytes from 192.168.2.192: seq=58 ttl=64 time=534.637 ms
> 64 bytes from 192.168.2.192: seq=59 ttl=64 time=552.154 ms
> 64 bytes from 192.168.2.192: seq=60 ttl=64 time=571.411 ms
> 64 bytes from 192.168.2.192: seq=61 ttl=64 time=594.605 ms
> 64 bytes from 192.168.2.192: seq=62 ttl=64 time=616.638 ms
> 64 bytes from 192.168.2.192: seq=63 ttl=64 time=535.492 ms
> 64 bytes from 192.168.2.192: seq=64 ttl=64 time=661.377 ms
> 64 bytes from 192.168.2.192: seq=65 ttl=64 time=685.821 ms
> 64 bytes from 192.168.2.192: seq=66 ttl=64 time=708.862 ms
> ^C
> --- 192.168.2.192 ping statistics ---
> 68 packets transmitted, 35 packets received, 48% packet loss
> round-trip min/avg/max = 6.622/359.507/1013.031 ms
> #

I would expect this kind of behaviour with high packet loss.

> ** Problem 2 - Total Loss of Connectivity **
> 
> Another issue we have is that WiFi clients loose their ability to
> connect to the AP after a period of time. I have remote access into an
> AP currently exhibiting this behavior. Here's what we're seeing:
> 
> 1) WiFi beacon is being broadcast and is visible to clients
> 
> 2) Client connection attempt fails and nothing appears in log
> indicating an attempt is made. Typically we would at least see
> association/authentication messages in the syslog.
>
> 3) Nothing unusual is reported by dmesg
> 
> 4) If hostapd is restarted, connections will come back up
>
> Any ideas?  Is there anything I can gather from debugfs or other means?

Firmware is defiantly not oopsed.
In some cases i noticed that firmware was not able to provide
notification about send or field TX packets because
 event queue was full. With slow usb i would assume that this queue will
often make some problems. But kernel driver was able to recover
connection even in this case. So, i don't think it will stall forever.

You can try to add "disassoc_low_ack=1" to hostapd.conf which may be
will refresh some stalled connections.

Other idea is to disbale ani. Try this workaround:

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index f46cd02..e89f85c 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -744,6 +744,8 @@ void ath9k_htc_start_ani(struct ath9k_htc_priv *priv)
        struct ath_common *common = ath9k_hw_common(priv->ah);
        unsigned long timestamp = jiffies_to_msecs(jiffies);

+       return;
+
        common->ani.longcal_timer = timestamp;
        common->ani.shortcal_timer = timestamp;
        common->ani.checkani_timer = timestamp;




> On Tue, May 6, 2014 at 12:21 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>
>> Am 06.05.2014 03:57, schrieb Aaron Hamilton:
>>> Oh ok. Is this not already handled by hostapd or the wifi drivers?
>>
>> No. hostapd suggest which rutaes should be used and driver, btw.
>> mac80211 should fallow this suggestion. ip layer is not touched.
>>
>>>
>>> Also, I reverted back to backports-3.12.8-1 and now trying to see if
>>> there's a difference when using sch_codel.ko and sch_fq_codel.ko
>>> (previously these two modules were not used as I was trying to minimize
>>> the number of moving parts). Which by the way, am I gaining or loosing
>>> anything with these? I'm not quiet sure what their purpose is.
>>
>> Scheduling is good for many reasons. For example, if you know what
>> bandwidth you have (in your case you know it) it is possible to use
>> priority for critical applications. DNS and ICMP traffic will have
>> higher priority then HTTP, and so on. Read more about QoS.
>> I would suggest to set scheduler to bandwidth lover then your USB
>> bandwidth. It should reduces usage of ath9k_htc_fw buffer. If you
>> configure scheduler, please try remove "supported_rates=10 20 55" from
>> you config.
>>
>> Don't forget. It is not enough to add scheduler module. You will need
>> configure it.
>>
>>> I'm also using the attached hostapd.conf file. Previously, when two
>>> devices were on the WiFi, one would always have ping latency of several
>>> hundred milliseconds despite minimal traffic on either host. Now latency
>>> only seems to spike when a large continuous file is moved across the
>>> WiFi. Streaming of music for example doesn't seem to have much effect on
>>> the other WiFi clients.
>>
>> How about filed tests? Do you still have stability issues?
>>
>>> # Begin hosatpd.conf
>>> interface=wlan0
>>> driver=nl80211
>>>
>>> hw_mode=g
>>>
>>> dump_file=/tmp/hostapd.dump
>>> ctrl_interface=/var/run/hostapd
>>> ctrl_interface_group=0
>>>
>>> logger_syslog=-1
>>> logger_syslog_level=2
>>> beacon_int=500
>>> dtim_period=2
>>>
>>> supported_rates=10 20 55
>>>
>>> max_num_sta=5
>>> rts_threshold=2347
>>> fragm_threshold=2346
>>>
>>> macaddr_acl=0
>>> eapol_version=1
>>> eapol_key_index_workaround=0
>>>
>>> # Attempting max time-outs for increased reliability
>>> wpa_group_rekey=0
>>> wpa_gmk_rekey=86400
>>> # wmm_enabled=1
>>> ieee80211n=1
>>> ieee80211d=1
>>> country_code=DE
>>> ht_capab=[HT40+][RX-STBC1][DSSS_CCK-40][SHORT-GI-40]
>>> ignore_broadcast_ssid=0
>>> channel=1
>>> ssid=TestSSID
>>>
>>> auth_algs=1
>>> wpa=2
>>> wpa_key_mgmt=WPA-PSK
>>>
>>> wpa_pairwise=CCMP
>>> rsn_pairwise=CCMP
>>>
>>> wpa_passphrase=fixmeplease
>>> # end hostapd.conf
>>>
>>>
>>> On Mon, May 5, 2014 at 12:32 PM, Oleksij Rempel <linux@rempel-privat.de
>>> <mailto:linux@rempel-privat.de>> wrote:
>>>
>>>     Am 05.05.2014 20:09, schrieb Aaron Hamilton:
>>>     > I'm sorry, what's TC?
>>>
>>>     http://linux.die.net/man/8/tc
>>>
>>>     > On Sat, May 3, 2014 at 2:07 AM, Oleksij Rempel
>>>     <linux at rempel-privat.de <mailto:linux@rempel-privat.de>
>>>     > <mailto:linux at rempel-privat.de <mailto:linux@rempel-privat.de>>>
>>>     wrote:
>>>     >
>>>     >     Am 02.05.2014 12:11, schrieb Aaron Hamilton:
>>>     >     > Ok, I updated the drivers to backports 3.14-1 and configured the
>>>     >     > following hostapd settings. I connected an iPad and a
>>>     Windows PC, then
>>>     >     > ran continuous pings. For the first couple seconds
>>>     everything was
>>>     >     > returning in a few milliseconds. Within 30 seconds, the
>>>     pings started
>>>     >     > getting into the several hundred ms range (or timing out)
>>>     and remained
>>>     >     > there (for both the iPad and PC).
>>>     >     >
>>>     >     > After I disconnected the PC from the WiFi, the iPad's pings
>>>     dropped to
>>>     >     > an average of 15ms (about 30s to a minute after the PC was
>>>     moved to
>>>     >     > another AP).
>>>
>>>     --
>>>     Regards,
>>>     Oleksij
>>>
>>>
>>
>>
>> --
>> Regards,
>> Oleksij
>>


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140510/8af4cba8/attachment.pgp