All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: james@nurealm.net, linux-wireless@vger.kernel.org
Subject: Re: wireless drivers fail to report link speed?
Date: Tue, 08 Aug 2017 16:42:27 -0500	[thread overview]
Message-ID: <1502228547.24881.5.camel@redhat.com> (raw)
In-Reply-To: <9645388a-2350-8fa0-ca34-e2289743888b@nurealm.net>

On Tue, 2017-08-08 at 13:07 -0600, James Feeney wrote:
> Hello All
> 
> Would you please look at kernel bug report "Since 4.12 - bonding
> module not
> working with wireless drivers", and tell me if you know why the
> kernel ethtool
> does not receive a speed report from the wireless drivers?
> 
>  https://bugzilla.kernel.org/show_bug.cgi?id=196547
> 
> It seems that Mahesh Bandewar became annoyed that some network
> drivers do not
> report speed and duplex to the bonding module properly, so that it
> becomes
> impossible to make "best connection" decisions.  A patch was applied
> to the
> bonding module in linux 4.12 which now disables any network interface
> that does
> not successfully report its speed and duplex.  In practice, this
> seems to
> include every wireless network driver I've tried, the ath5k, ath9k,
> the
> rtl8192ce and RTL8188CUS.  Of course, this new behavior breaks
> wireless bonding!
> 
> Do you know if there is some general reason why the wireless drivers
> do not work
> with the kernel ethtool?  Is this something that can be fixed?  Can
> you tell if
> this reporting failure would be the fault of the kernel ethtool?  Or
> the
> wireless driver?  Or the bonding module?

Because the "speed" (whatever that means) can and sometimes does change
with every packet.  The driver dynamically adjusts the link rate based
on all kinds of things.  But mainly the current radio environment; how
many other APs are around, how much interference there is, how many
other clients are trying to talk, that kind of thing.

So one second the wifi might be the "best" link and then when somebody
turns on a microwave oven or a baby monitor, it may be the "worst"
until the microwave's duty cycle completes a few seconds later then
it'll become the "best" again for a couple seconds then "worst" again,
repeat until your Easy Mac is nice and warm and creamy.

Furthermore, for some drivers IIRC when there isn't any traffic, they
might drop the link rate very low because there's no reason keep
powering blocks when you're not transmitting/receiving any data.  IIRC
the Intel drivers used to do that a couple years ago.

Also, "duplex" doesn't mean anything in wireless land.  So no clue what
bonding is expecting them to say here.  I would say the modifications
to the bonding core made assumptions that simply aren't applicable to
mediums other than wired ones.

Dan

  reply	other threads:[~2017-08-08 21:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-08 19:07 wireless drivers fail to report link speed? James Feeney
2017-08-08 21:42 ` Dan Williams [this message]
2017-08-08 21:58   ` Ben Greear
2017-08-08 22:25     ` James Feeney
2017-08-08 22:49       ` Ben Greear
2017-08-09  0:36         ` James Feeney
2017-08-09  9:30           ` Arend van Spriel
2017-08-09 17:01             ` James Feeney
2017-08-09 18:25               ` Dan Williams
2017-08-10  1:20                 ` James Feeney
2017-08-11 18:43                 ` Andy Gospodarek
2017-08-10  5:25               ` Kalle Valo
2017-08-09 13:43           ` Dan Williams
2017-08-08 23:43       ` Dan Williams
2017-08-09 12:24 ` Kalle Valo

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=1502228547.24881.5.camel@redhat.com \
    --to=dcbw@redhat.com \
    --cc=james@nurealm.net \
    --cc=linux-wireless@vger.kernel.org \
    /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.