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 > <aa...@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 <li...@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 <li...@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 <li...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
