On 08/08/2017 03:25 PM, James Feeney wrote:
Hey Dan
...
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
question asked.
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
moment?
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
NIC statistics:
rx_packets: 3321
rx_bytes: 338788
rx_duplicates: 0
rx_fragments: 1671
rx_dropped: 0
tx_packets: 15
tx_bytes: 484
tx_filtered: 0
tx_retry_failed: 2
tx_retries: 0
sta_state: 4
txrate: 13000000
rxrate: 0
signal: 201
channel: 5180
noise: 150
ch_time: 56
ch_time_busy: 3
ch_time_ext_busy: 18446744073709551615
ch_time_rx: 18446744073709551615
ch_time_tx: 18446744073709551615
tx_hw_reaped: 1836
tx_pkts_nic: 157
tx_bytes_nic: 17639
tx_bytes_to_fw: 24626
rx_pkts_nic: 211
rx_bytes_nic: 17346681
d_noise_floor: 18446744073709551510
d_cycle_count: 4138309451
d_tx_cycle_count: 63796069
d_rx_cycle_count: 3941659360
d_busy_count: 4061048026
d_flags: 0
d_phy_error: 0
d_rts_bad: 0
d_rts_good: 4
d_tx_power: 46
d_rx_crc_err: 1518
d_no_beacon: 0
d_tx_mpdus_queued: 489
d_tx_msdu_queued: 494
d_tx_msdu_dropped: 0
d_local_enqued: 46
d_local_freed: 46
d_tx_ppdu_hw_queued: 1836
d_tx_ppdu_reaped: 1836
d_tx_fifo_underrun: 4
d_tx_ppdu_abort: 0
d_tx_mpdu_requed: 1587
d_tx_excessive_retries: 1575
d_tx_hw_rate: 192
d_tx_dropped_sw_retries: 51
d_tx_noack: 0
d_tx_noack_bytes: 0
d_tx_discard: 240
d_tx_discard_bytes: 5763
d_tx_illegal_rate: 0
d_tx_continuous_xretries: 0
d_tx_timeout: 0
d_tx_mpdu_txop_limit: 0
d_pdev_resets: 25
d_rx_mid_ppdu_route_change: 0
d_rx_status: 0
d_rx_extra_frags_ring0: 84453
d_rx_extra_frags_ring1: 0
d_rx_extra_frags_ring2: 0
d_rx_extra_frags_ring3: 0
d_rx_msdu_htt: 211
d_rx_mpdu_htt: 211
d_rx_msdu_stack: 84242
d_rx_mpdu_stack: 84242
d_rx_phy_err: 0
d_rx_phy_err_drops: 0
d_rx_mpdu_errors: 0
d_fw_crash_count: 0
d_fw_warm_reset_count: 0
d_fw_cold_reset_count: 8
d_fw_powerup_failed: 0
d_short_tx_retries: 4
d_long_tx_retries: 1571
d_fw_adc_temp: 3081417395
[root@lf0350-7220 lanforge]#
Thanks,
Ben
Thanks
James
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
