Am 28.05.2014 07:36, schrieb Aaron Hamilton: > 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.
IP level capture is not interesting. More interesting is radio level capture - should be made in monitore mode with radiotap enabled. And probably more important usb traffic capture - usbmonitore module should be enabled. > On Mon, May 12, 2014 at 7:47 AM, Oleksij Rempel <li...@rempel-privat.de > <mailto:li...@rempel-privat.de>> 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 > > > > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -- 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
