From: wim torfs <wtorfs@gmail.com>
To: Oleksij Rempel <linux@rempel-privat.de>
Cc: rolf.anderegg@weiss.ch,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: ath9k_htc: virtual interfaces, AP connection drop & kernel warning
Date: Thu, 23 Jul 2015 10:08:01 +0200 [thread overview]
Message-ID: <55B0A0E1.9090300@gmail.com> (raw)
In-Reply-To: <55AFCFDE.7060902@rempel-privat.de>
On 07/22/2015 07:16 PM, Oleksij Rempel wrote:
> Am 22.07.2015 um 18:37 schrieb Rolf Anderegg:
>>
>> On 16/07/15 13:54, Oleksij Rempel wrote:
>>> Am 13.07.2015 um 13:52 schrieb Rolf Anderegg:
>>>>
>>>> I suspect that there are bandwidth/speed issues when dealing with USB
>>>> adapters, but that does not inherently mean that the connection is prone
>>>> to drop, right? Doesn't that mean that I am leaking packages somewhere
>>>> along the way? What else could I be looking for?
>>>
>>> The packages can drop if you will do channel scan. STA mode need some
>>> seconds to complete channel scan. It means AP will be all the time
>>> unavailable.
>>
>> Ok, that may be. Then again why am I not experiencing the same
>> connection drop on my ath5k setup? Because the channel scan is more
>> likely to be completed in due time?
>
> Yes, channel scantime on usb device is match longer then on pci.
>
May I ask for the reason it takes a longer time to complete the scanning
on a USB device compared to a PCI device? I assume the internals of an
ath9k PCI device is similar as that of an ath9k_htc USB device, so is it
purely the bus speed that affects this time? Or is the USB device a
smaller version of the chipset on the PCI device and therefore with a
lower speed due to power concerns?
If it is due to the bus speed, would it be possible to decouple the
scanning process from the bus, that is, I assume that the hardware
performs all the necessary channel switching and channel sensing, so why
not allow the hardware to gather such information and transfer the
results in a single burst to the host over the USB bus? Or is the
channel switching controlled by the host and it takes a lot of time due
to the duration of transmitting the channel switching commands to the
USB device?
Thanks,
Wim.
next prev parent reply other threads:[~2015-07-23 8:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 15:28 ath9k_htc: virtual interfaces, AP connection drop & kernel warning Rolf Anderegg
2015-07-10 10:14 ` Oleksij Rempel
2015-07-13 11:52 ` Rolf Anderegg
2015-07-16 11:04 ` Oleksij Rempel
2015-07-16 11:54 ` Oleksij Rempel
2015-07-22 16:37 ` Rolf Anderegg
2015-07-22 17:16 ` Oleksij Rempel
2015-07-23 8:08 ` wim torfs [this message]
2015-07-23 21:06 ` Oleksij Rempel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B0A0E1.9090300@gmail.com \
--to=wtorfs@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linux@rempel-privat.de \
--cc=rolf.anderegg@weiss.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.