In mac80211, the SIOC{S,G}IWRATE commands are not implemented. Is there another way to find out what
transmission rate is being used?
Larry
Michael Wu wrote:
> On Wednesday 25 April 2007 13:55, Larry Finger wrote:
>> In mac80211, the SIOC{S,G}IWRATE commands are not implemented. Is there
>> another way to find out what transmission rate is being used?
>>
> If mac80211 is configured to be verbose enough, it will periodically print the
> average rate used since the last time the message was printed out.
>
> #ifdef CONFIG_MAC80211_VERBOSE_DEBUG
> printk(KERN_DEBUG "%s: STA " MAC_FMT " Average rate: "
> "%d (%d/%d)\n",
> dev->name, MAC_ARG(sta->addr),
> srctrl->tx_avg_rate_sum /
> srctrl->tx_avg_rate_num,
> srctrl->tx_avg_rate_sum,
> srctrl->tx_avg_rate_num);
> #endif /* CONFIG_MAC80211_VERBOSE_DEBUG */
The problem with that level of debug, the logs are flooded with many lines each scan cycle, which
happens every 1 minute with NetworkManager. In addidtion, I was hoping for something I could look at
without having to peruse my way through the complete log.
Larry
On Thursday 26 April 2007 00:16, Larry Finger wrote:
> The problem with that level of debug, the logs are flooded with many lines
> each scan cycle, which happens every 1 minute with NetworkManager. In
> addidtion, I was hoping for something I could look at without having to
> peruse my way through the complete log.
>
Patches welcome. The rate control API currently has no easy way to obtain the
current rate which is part of why SIOCGIWRATE hasn't been implemented yet.
-Michael Wu
On Fri, 2007-04-27 at 15:38 -0500, Larry Finger wrote:
> No, the simple rate algorithm is fine. Once I make the connection, it is changing the rates up and
> down as I would have expected. The main problem was that I never got on, and without communication
> there was no basis on which to adjust the rate.
Hah, I had the same problem and always thought the dhcp server was
somehow a bit buggy because re-doing dhcp fixed it (it sends a bunch of
packets and then the rate gets adjusted down). Of course, I don't have
any problems to associate since my university still runs 40-bit WEP.
johannes
On Fri, 27 Apr 2007 15:21:37 -0500, Larry Finger wrote:
> Thanks for the info. I'm using txrate in the sta_info struct, which is an index into the rates
> array. That turned out to be very useful as I discovered that rc80211_simple was setting the initial
> rate to 54 Mbs. I have some doubt if that rate is best under any circumstance, but it certainly is
> not for bcm43xx as the current issues with TX power do not allow transmission at that rate. By
> setting the initial rate to 1 Mbs, I was able to connect for the first time with my BCM4311.
Rate control modules can be switched on-the-fly with mac80211. You can
write your own rc module that uses 1 mbps all times :-) Actually, I
wrote that module but haven't kept it up to date so it doesn't even
compile now...
Jiri
--
Jiri Benc
SUSE Labs
On Wed, 25 Apr 2007 12:55:35 -0500, Larry Finger wrote:
> In mac80211, the SIOC{S,G}IWRATE commands are not implemented. Is there another way to find out what
> transmission rate is being used?
If you have debugfs compiled in, you can look into
<debugfs_mount_point>/ieee80211/phy0/stations/*/rc_simple_tx_avg_rate_[ns]um.
But that's just average.
Jiri
--
Jiri Benc
SUSE Labs
On Wednesday 25 April 2007 13:55, Larry Finger wrote:
> In mac80211, the SIOC{S,G}IWRATE commands are not implemented. Is there
> another way to find out what transmission rate is being used?
>
If mac80211 is configured to be verbose enough, it will periodically print the
average rate used since the last time the message was printed out.
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
printk(KERN_DEBUG "%s: STA " MAC_FMT " Average rate: "
"%d (%d/%d)\n",
dev->name, MAC_ARG(sta->addr),
srctrl->tx_avg_rate_sum /
srctrl->tx_avg_rate_num,
srctrl->tx_avg_rate_sum,
srctrl->tx_avg_rate_num);
#endif /* CONFIG_MAC80211_VERBOSE_DEBUG */
-Michael Wu
Michael Wu wrote:
> On Thursday 26 April 2007 00:16, Larry Finger wrote:
>
> Patches welcome. The rate control API currently has no easy way to obtain the
> current rate which is part of why SIOCGIWRATE hasn't been implemented yet.
What is in txrate in struct sta_info? Isn't it the rate to be used for the next transmission?
Larry
Jiri Benc wrote:
>
> Rate control modules can be switched on-the-fly with mac80211. You can
> write your own rc module that uses 1 mbps all times :-) Actually, I
> wrote that module but haven't kept it up to date so it doesn't even
> compile now...
No, the simple rate algorithm is fine. Once I make the connection, it is changing the rates up and
down as I would have expected. The main problem was that I never got on, and without communication
there was no basis on which to adjust the rate. Now it connects reliably, which makes it a lot
easier to try fixes for the power problem. It is really hard to debug a power problem when nothing
works.
Larry
Jiri Benc wrote:
>
> If you have debugfs compiled in, you can look into
> <debugfs_mount_point>/ieee80211/phy0/stations/*/rc_simple_tx_avg_rate_[ns]um.
> But that's just average.
Jiri,
Thanks for the info. I'm using txrate in the sta_info struct, which is an index into the rates
array. That turned out to be very useful as I discovered that rc80211_simple was setting the initial
rate to 54 Mbs. I have some doubt if that rate is best under any circumstance, but it certainly is
not for bcm43xx as the current issues with TX power do not allow transmission at that rate. By
setting the initial rate to 1 Mbs, I was able to connect for the first time with my BCM4311.
Larry
On Thursday 26 April 2007 01:15, Larry Finger wrote:
> What is in txrate in struct sta_info? Isn't it the rate to be used for the
> next transmission?
>
It is an index to the rate that could be used for the next transmission to
that sta. I was referring to the rate_control_ops not having a callback that
would return the current rate, but looking into sta_info should be fine.
Guess I overlooked that when I was looking to implement SIOCGIWRATE. Not sure
if doing this will be valid for other rate control algorithms in the future,
but that can be dealt with later.
-Michael Wu