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

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

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).

Well, i would expected this behaviour. If usb bandwidth is lover then
WiFi speed, then all packets will stall in the queue of
ath9k_htc_firmware. You can try to reduce usb traffic by increesing
beacon interval in hostapd.conf "beacon_int=1000" and reduce bandwidth
by using TC or limit available rates to "supported_rates=10 20 55".

I would prefer TC variant, but may be in your case limiting rates will
work better. Field testing will show.

> I didn't run this test personally before, so I'm not sure if this is
> new behavior.
> 
> # Hostapd.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=100
> dtim_period=2
> 
> max_num_sta=7
> rts_threshold=2347
> fragm_threshold=2346
> 
> macaddr_acl=0
> eapol_version=1
> eapol_key_index_workaround=0
> 
> 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
> 
> 
> On Thu, May 1, 2014 at 11:27 PM, Aaron Hamilton
> <aaron@logicdatasystems.net> wrote:
>> Looks like "nohwcrypt=1" is a no-go. When this is configured, speed
>> tests initially show 2.2Mbps for about two seconds until the entire
>> device locks up and reboots. Without "nohwcrypt=1", I get 5 to 5.5Mbps
>> consistently.
>>
>> The wifi module is the only thing on the USB bus. But I'm happy with
>> 5Mbps if it's stable.
>>
>> On Thu, May 1, 2014 at 3:41 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>> Am 02.05.2014 00:00, schrieb Aaron Hamilton:
>>>> Considering the wifi card is attached to an at91rm9200
>>>> (http://www.atmel.com/Images/1768s.pdf) that only has a 12 Mbps USB
>>>> port, does it matter if I enable 802.11n?
>>>
>>> Theoretically it will work at same speed as before, but transaction will
>>> take less air time.
>>>
>>> 12 MBps ...  ufff.. i never tested FS mode. This device has huge
>>> difference on HS and SS hosts. There are different speed and stability
>>> issues. I won't be surprised if it is part of the problem.
>>> Interrupt traffic may reserve big part of your available usb bandwidth.
>>> How many devices do you have on same root hub?
>>>
>>> Did you tried to increase beacon interval to reduce usb traffic?
>>>
>>>
>>>> On Wed, Apr 30, 2014 at 10:37 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>> Am 01.05.2014 01:03, schrieb Aaron Hamilton:
>>>>>> I believe CONFIG_ATH_DEBUG is enabled, but I'll double check again.
>>>>>> Attached is the hostapd.conf we're using. Right now the only logs we
>>>>>> see are what's in syslog or dmesg, but I'd be more than happy to
>>>>>> enable whatever I can. Just need to know what to configure.
>>>>>
>>>>> First mistake what i see in hostapd.conf is:
>>>>> max_num_sta=255
>>>>> it should be 8
>>>>>
>>>>> second, max_num_sta=255 is not enabled:
>>>>> ieee80211n=1
>>>>> ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40][RX-STBC1]
>>>>> channel=11
>>>>> ieee80211d=1
>>>>> country_code=DE
>>>>>
>>>>> then you may try module parameter "nohwcrypt=1", just to make sure.
>>>>>
>>>>>> Thus far everytime we've had an issue with clients unable to connect,
>>>>>> a restart of hostapd fixed it. Strangely, the clients were able to see
>>>>>> the SSID broadcast, but failed immediately upon a connection attempt.
>>>>>> The problem also seems to be all or none. Once one client looses
>>>>>> connection, they all do until hostapd is restarted or the device is
>>>>>> power cycled.
>>>>>
>>>>> Did you tried to reproduce this problem with more then one STA?
>>>>> It look for me more like "max_num_sta=255" problem.
>>>>>
>>>>>>
>>>>>> On Wed, Apr 30, 2014 at 1:40 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>>>>>> Am 30.04.2014 22:16, schrieb Oleksij Rempel:
>>>>>>>> Am 30.04.2014 20:59, schrieb Aaron Hamilton:
>>>>>>>>> Unfortunately our units are in another state, so we're unable to make
>>>>>>>>> the electrical connections. If the UART is RS-232, we might be able to
>>>>>>>>> modify some locally - but it'll be a rather difficult challenge.
>>>>>>>>
>>>>>>>> It is TTL level, 3,3 Volt.
>>>>>>>>
>>>>>>>>> Not
>>>>>>>>> to mention, we see a great deal of issues in the field, but can't
>>>>>>>>> duplicate them here.
>>>>>>>>
>>>>>>>> Did you tried to grab hostpad  log to so what kind of connections do you
>>>>>>>> have? What is your hostapd config?
>>>>>>>>
>>>>>>>>> On the firmware, I'm pulling down io_clean-2014.04.29 right now. I'm
>>>>>>>>> assuming this is what I should be using?
>>>>>>>>
>>>>>>>> You can use it, but these changes should make sense only if you can get
>>>>>>>> oops log from firmware. Or at least FW panic report from dmesg.
>>>>>>>>
>>>>>>>> Theoretically this change set should not affect stability.
>>>>>>>>
>>>>>>>>> Are there any other options for debugging aside from the UART? We're
>>>>>>>>> really in a bind and feel like the only work around is to setup a task
>>>>>>>>> to restart hostapd every hour.
>>>>>>>>
>>>>>>>> Hmm.. restarting hostpad should not affect firmware. Is it really
>>>>>>>> working for you?
>>>>>>>
>>>>>>> Make sure you have CONFIG_ATH_DEBUG enabled. May be we can get some
>>>>>>> interesting information. For example WMI timeouts are printed with
>>>>>>> ath_dbg which is disable without CONFIG_ATH_DEBUG.
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Oleksij
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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/20140503/3ad59395/attachment.pgp