[ath9k-devel] Stable Version for ath9k_htc in AP Mode?

[Oleksij Rempel <linux@rempel-privat.de>]

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 <linux@rempel-privat.de
> <mailto:linux@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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140530/abe167c4/attachment.pgp