On 08/08/2017 03:25 PM, James Feeney wrote:
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.
Yes, thanks, but, while all of that is true, it has nothing to do with the
The question is, regardless that the wireless speed may be constantly changing,
why is it that the kernel ethtool returns an error on get_settings(), instead of
returning the current wireless speed, whatever that link speed might be at the
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.
Since, as Ben mentions,
Well, wifi acts half-duplex in that only one side can transmit at once.
then the wireless drivers would be expected to simply report "half-duplex".
Again, the issue is not that wireless is half-duplex or full-duplex, but rather,
why does the kernel ethtool return an error on get_settings()?
And, why is it that it seems get_settings() returns an error with multiple
wireless drivers? Is there some assumption, or convention, that causes the
kernel ethtool to fail with *all* the wireless drivers?
I see that, on bugzilla, Florian is suggesting that wireless network devices
*cannot* report a speed/duplex, simply because the wireless speed changes on a
per-packet basis, but that does not seem to me to be a persuasive argument. A
wireless connection *does* always have a current speed, even if that speed
changes frequently. The kernel ethtool get_settings() should simply report that
speed, not throw an error, yes?
Some time back, I added some support to ath10k to report some ethtool info.
At least most of this is upstream. I do report rx and rx link rate, and yes,
it changes, but it does contain some useful info, at least when modest amounts
of packets are being transmitted and received (so that rate-ctrl logic
is working). I think the stuff not prepended with d_ will show up for any
mac80211 driver. Someone could improve ethtool to report these through more
normal API than just getting the stats if they wanted...
[root@lf0350-7220 lanforge]# ethtool -S wlan0
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com