From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Hamilton Date: Tue, 27 May 2014 22:36:11 -0700 Subject: [ath9k-devel] Stable Version for ath9k_htc in AP Mode? In-Reply-To: <5370DF02.2070808@rempel-privat.de> References: <5367E75D.1070601@rempel-privat.de> <53688D75.9040006@rempel-privat.de> <536DF0AF.1030306@rempel-privat.de> <53707FE6.3030204@rempel-privat.de> <20140512131119.30298.qmail@stuge.se> <5370DF02.2070808@rempel-privat.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org If one device has 7ms pings while the other consistently has 200 to 1500ms pings, then wouldn't this rule out an interrupt issue? I'd assume if the latency was caused by delays in interrupt processing, that both devices would have similar latency problems? The only difference I can see between the PC (no latency) and the embedded device (high latency) is that the PC is also sending other traffic over the interface while the embedded device is simply responding to pings. If it helps, this is a station dump for the two devices: Station 10:0b:a9:a5:46:e4 (on wlan0) <--- low latency PC inactive time: 35 ms rx bytes: 345250 rx packets: 2488 tx bytes: 4568941 tx packets: 3258 tx retries: 0 tx failed: 0 signal: -55 dBm signal avg: -54 dBm tx bitrate: 2.0 MBit/s Station 00:22:52:02:20:b1 (on wlan0) <--- high latency embedded device inactive time: 20136 ms rx bytes: 40968 rx packets: 364 tx bytes: 18713 tx packets: 127 tx retries: 0 tx failed: 0 signal: -52 dBm signal avg: -52 dBm tx bitrate: 2.0 MBit/s I've also attached packet captures using tcpdump on the AP. On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel wrote: > Am 12.05.2014 15:11, schrieb Peter Stuge: > > Oleksij Rempel wrote: > >> From dmesg i see that, to one USB 1.1 root-hub attached two device, > >> ath9k_htc and GobiNet. GobiNet was recognised as eth1 + 3 x ttyUSB. > >> IMO, it is a lot for one USB 1.1. > > > > True as that may be, if there is a bandwidth requirement for the > > interface to function correctly and the USB protocol being used does > > not guarantee that bandwidth (only control+interrupt transfers could > > do it in a meaningful way, and they are rather low bandwidth) then > > the USB stack would have to allow the driver to reserve bus time, and > > the driver would have to make a reservation to successfully handle > > worst-case load. > > > > That's not neccessarily a small change. :\ > > I tested ath9k-htc on many different usb host controllers (not usb 1.1), > and noticed that most USB 2.0 controllers need some *msecs* to transfer > one Interrupt package to the adapter or at least to get ACK signal. USB > 3.0 was transferring same package in some *usecs*. The results should be > similar for both controller, but it is not the case. Even different USB > 2.0 controller was performing differently. > > This big difference is responsible for extremely long scan time on > ath9k_htc on USB 2.0. Since Interrupt Endpoints are heavily used on this > devices, reducing bandwidth and/or increasing transfer time for > Interrupt traffic will be critical. > > Best indicator for this issue would be, disabling LED subsystem to get > better stability. What, according to Aaron, is the case. > > -- > Regards, > Oleksij > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140527/f5335401/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: defib_and_pc.pcap Type: application/octet-stream Size: 3697007 bytes Desc: not available Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140527/f5335401/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: defib_only.pcap Type: application/octet-stream Size: 12228 bytes Desc: not available Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140527/f5335401/attachment-0003.obj