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