Hi, are you running these devices through a powered hub? If not, can you test that?
I've read the above emails and the first email still rings worrysome. You don't want to be under-powering the NIC in any way or things may get extremely pissed off. Are you using an AR9170, or an actual ath9k_htc part? Can you post a dmesg? -a On 10 May 2014 23:40, Aaron Hamilton <aa...@logicdatasystems.net> wrote: > I'll give the patches/config a try and see if it helps anything. Also, > the line "supported_rates=10 20 55" doesn't seem to be working. When I > do a station dump, the tx rate is reported as 6.5 Mbit/s. > > On the device that is currently locked up and not accepting > connections, what are some options for obtaining useful data on the > current state of the device (i.e. queue status, etc)? I know I can > restart hostapd to fix it, but that doesn't help me find the root > cause (and thus how to fix it). > > I've gone through an incredible amount of iterations of kernel > configurations, hostapd changes, etc and I'm pulling my hair out not > getting any closer to finding the problem. I really appreciate all the > help thus far, but it would be awesome to be able to see the state of > the queues and see if/where anything is locked up or pending. > > On Sat, May 10, 2014 at 2:26 AM, Oleksij Rempel <li...@rempel-privat.de> > wrote: >> 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 <li...@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 <li...@rempel-privat.de >>>>> <mailto:li...@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 >>>>> <li...@rempel-privat.de <mailto:li...@rempel-privat.de> >>>>> > <mailto:li...@rempel-privat.de <mailto:li...@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 >> > _______________________________________________ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
