Just tried it with an rt73 module and the behavior is the same. Appears the outbound traffic is getting queued up, then flushed at the beacon interval.
If I initiate pings from the client to the AP (while still pinging from AP to client), the client receives responses back consistently in 15ms. Also, the ping latency from the AP to the client starts dropping and continues down until it reaches 7ms or so. Looks like a transmit queue somewhere is not getting processed without either the beacon, or rx traffic? I'll work on getting a cleaner capture with more info. In the mean time, is there a high level overview of the interaction between the USB, mac80211, and network systems somewhere? Or if someone knows the relevant code segments I should look at, then hopefully I could start narrowing things down further. Thanks Oleksij and others for the assistance thus far. Feel like I'm much closer to putting this thing to rest. On Fri, Jun 6, 2014 at 12:52 AM, Oleksij Rempel <li...@rempel-privat.de> wrote: > Am 06.06.2014 04:12, schrieb Aaron Hamilton: >> I tried running ping tests again while capturing USB traffic, and in >> doing so I set the hostapd beacon interval to roughly 5 seconds. While >> doing this, I noticed the ping latency somehow correlates with the >> beacon interval. Here's an example: >> >> Ping from AP to client device with beacon interval ~5 seconds: >> >> # ping 192.168.2.194 >> PING 192.168.2.194 (192.168.2.194): 56 data bytes >> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=21549.225 ms >> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=20535.767 ms >> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=19535.339 ms >> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=18528.473 ms >> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=17517.608 ms >> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=16510.559 ms >> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=15508.789 ms >> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=14502.075 ms >> 64 bytes from 192.168.2.194: seq=20 ttl=64 time=1377.839 ms >> 64 bytes from 192.168.2.194: seq=21 ttl=64 time=370.208 ms >> 64 bytes from 192.168.2.194: seq=22 ttl=64 time=189.728 ms >> ^C >> --- 192.168.2.194 ping statistics --- >> 52 packets transmitted, 33 packets received, 36% packet loss >> round-trip min/avg/max = 189.728/11757.569/21574.890 ms >> # >> >> Here are pings from the AP to the client with the beacon interval ~100ms: >> # ping 192.168.2.194 >> PING 192.168.2.194 (192.168.2.194): 56 data bytes >> 64 bytes from 192.168.2.194: seq=0 ttl=64 time=347.351 ms >> 64 bytes from 192.168.2.194: seq=1 ttl=64 time=366.669 ms >> 64 bytes from 192.168.2.194: seq=2 ttl=64 time=380.005 ms >> 64 bytes from 192.168.2.194: seq=3 ttl=64 time=393.005 ms >> 64 bytes from 192.168.2.194: seq=4 ttl=64 time=221.405 ms >> 64 bytes from 192.168.2.194: seq=5 ttl=64 time=429.749 ms >> 64 bytes from 192.168.2.194: seq=6 ttl=64 time=453.522 ms >> 64 bytes from 192.168.2.194: seq=7 ttl=64 time=264.465 ms >> 64 bytes from 192.168.2.194: seq=8 ttl=64 time=72.845 ms >> ^C >> --- 192.168.2.194 ping statistics --- >> 22 packets transmitted, 21 packets received, 4% packet loss >> round-trip min/avg/max = 72.845/252.105/453.522 ms >> # >> >> When I ping from the client to the AP, the pings are consistently 10 >> to 15ms. Any idea why latency would be low in one direction, but not >> the other? > > In this case latency = packet loss. > > May be TTL time of AP is less then on Station? This is why all request > initiated from AP haw big packed loss. I mean dropped because of TTL. > >> And why it would correlate with the beacon interval? > > I have no idea. > >> If it helps, I've attached the USB capture from the first ping test. > > I was not able to identify ping packets from usb traffic. Please use > "pint -p aa IPADDR", it will provide easy searchable patter. To make > live easier, please provide captures of USB, network and WIFI (in > monitore mode) captures which was made at same time. Makes sure that the > time on all machines is synced. With this caps we should be able to > compare packages to see where are most packed dropped. > > I noticed one issue in your usblog.pcap. There is a flood of incoming > usb packets. I forgot that WiFi interface is set to monitore mode to > provide AP functionality. It means, every thing what happens on that > channel is send over USB. In this case, USB1.1 with other concurrent > devices. > >> On Wed, Jun 4, 2014 at 11:06 AM, Aaron Hamilton >> <aa...@logicdatasystems.net> wrote: >>> >>> I'll see if I can do some monitoring on the USB port. One thing I noticed: >>> If pinging from just the AP to the client device, the latency is high. But >>> as soon as pings are made from the client device to the AP, the latency >>> drops. >>> >>> In case this is a kernel configuration issue, can someone point me to an >>> ARM kernel config they've used successfully with the ath9k_htc? >>> >>> On Thu, May 29, 2014 at 9:21 PM, Oleksij Rempel <li...@rempel-privat.de> >>> wrote: >>>> >>>> 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 >>>> >>> > > > -- > Regards, > Oleksij > _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
