Rate control over multiple devices
Hi folks -
Just seemed a little strange, maybe it is perfectly fine.
iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
PM: Adding info for No Bus:phy0
PM: Adding info for No Bus:wmaster0
wmaster0: Selected rate control algorithm 'iwl-3945-rs'
...but then we add an rt73usb...
PM: Adding info for No Bus:phy1
PM: Adding info for No Bus:wmaster1
wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
PM: Adding info for No Bus:wlan1
usbcore: registered new interface driver rt73usb
-Andy
Quoted 9 lines · Andy Green
Hi folks -
Just seemed a little strange, maybe it is perfectly fine.
iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
PM: Adding info for No Bus:phy0
PM: Adding info for No Bus:wmaster0
wmaster0: Selected rate control algorithm 'iwl-3945-rs'
Quoted 7 lines
...but then we add an rt73usb...
PM: Adding info for No Bus:phy1
PM: Adding info for No Bus:wmaster1
wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
PM: Adding info for No Bus:wlan1
usbcore: registered new interface driver rt73usb
This looks like the reverse of a dust-up we had a couple of months ago:
http://marc.info/?l=linux-wireless&m=117875332512693&w=2
It is possible to change the rate control algorithm now via debugfs. In the past someone proposed letting drivers request their default rate scaling algorithm, and I think that makes a lot of sense. Any thoughts?
John
Signature · 2 lines
John W. Linville [email protected]
Quoted 7 lines · John W. Linville
Quoted 7 lines
Just seemed a little strange, maybe it is perfectly fine.
iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
PM: Adding info for No Bus:phy0
PM: Adding info for No Bus:wmaster0
wmaster0: Selected rate control algorithm 'iwl-3945-rs'
Quoted 7 lines
Quoted 7 lines
...but then we add an rt73usb...
PM: Adding info for No Bus:phy1
PM: Adding info for No Bus:wmaster1
wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
PM: Adding info for No Bus:wlan1
usbcore: registered new interface driver rt73usb
Weird. But I guess that's because iwl-3945-rs is loaded and available so it's chosen first or something.
Quoted 8 lines
This looks like the reverse of a dust-up we had a couple of months ago:
http://marc.info/?l=linux-wireless&m=117875332512693&w=2It is possible to change the rate control algorithm now via debugfs. In the past someone proposed letting drivers request their default rate scaling algorithm, and I think that makes a lot of sense. Any thoughts?
Apply the patch already? IIRC James made a pretty good one around that time to let the driver choose a default name as part of the hw structure it registers and it can be NULL for the default.
Of course, in a perfect world we'd have a 'default' rate control setting somewhere and apply that for drivers that have rate_control==NULL, while default would default to 'simple' to avoid the issue above.
johannes
Quoted 11 lines · Johannes Berg
Quoted 9 lines · John W. Linville
Quoted 9 lines
Just seemed a little strange, maybe it is perfectly fine.
iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
PM: Adding info for No Bus:phy0
PM: Adding info for No Bus:wmaster0
wmaster0: Selected rate control algorithm 'iwl-3945-rs'...but then we add an rt73usb...
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
PM: Adding info for No Bus:phy1
PM: Adding info for No Bus:wmaster1
wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
PM: Adding info for No Bus:wlan1
usbcore: registered new interface driver rt73usbWeird. But I guess that's because iwl-3945-rs is loaded and available so it's chosen first or something.
Exactly. This is one of things that should be solved in the patch mentioned below.
Quoted 8 lines
Quoted 8 lines
This looks like the reverse of a dust-up we had a couple of months ago:
http://marc.info/?l=linux-wireless&m=117875332512693&w=2It is possible to change the rate control algorithm now via debugfs. In the past someone proposed letting drivers request their default rate scaling algorithm, and I think that makes a lot of sense. Any thoughts?
Still waiting for a patch from Intel.
Quoted 7 lines
Apply the patch already? IIRC James made a pretty good one around that time to let the driver choose a default name as part of the hw structure it registers and it can be NULL for the default.
Of course, in a perfect world we'd have a 'default' rate control setting somewhere and apply that for drivers that have rate_control==NULL, while default would default to 'simple' to avoid the issue above.
I'd really like to see that in the patch. Seems to be a real issue.
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Quoted 2 lines · Jiri Benc
Exactly. This is one of things that should be solved in the patch mentioned below.
I suppose you mean this patch
http://article.gmane.org/gmane.linux.kernel.wireless.general/2303
Quoted 9 lines
Quoted 7 lines
Apply the patch already? IIRC James made a pretty good one around that time to let the driver choose a default name as part of the hw structure it registers and it can be NULL for the default.
Of course, in a perfect world we'd have a 'default' rate control setting somewhere and apply that for drivers that have rate_control==NULL, while default would default to 'simple' to avoid the issue above.
I'd really like to see that in the patch. Seems to be a real issue.
Except that we have no API for that (should be in cfg80211.)
johannes
Quoted 2 lines · Johannes Berg
I suppose you mean this patch
http://article.gmane.org/gmane.linux.kernel.wireless.general/2303
Yes. But I'd like to see a solution to the problem reported by Andy in the patch. One of the possible solutions could be adding a "this is a special rate control alg which shouldn't be selected automatically" flag to rate control algs and not selecting such algorithms in ieee80211_try_rate_control_ops_get when 'name' is NULL. Should be easy to implement.
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Of course, in a perfect world we'd have a 'default' rate control setting somewhere and apply that for drivers that have rate_control==NULL, while default would default to 'simple' to avoid the issue above.
That's a possible solution too, though not an ideal one. Currently, you can use module alias to change default rate control algorithm - at least for simple setups. This would break it.
Quoted 3 lines
Quoted 1 line
I'd really like to see that in the patch. Seems to be a real issue.
Except that we have no API for that (should be in cfg80211.)
We will need an API for changing of rate control alg from the user space, sure - but that's not an issue here, this patch is purely mac80211 thing.
Thanks,
Jiri
Signature · 2 lines
Jiri Benc SUSE Labs
Quoted 6 lines · Jiri Benc
Yes. But I'd like to see a solution to the problem reported by Andy in the patch. One of the possible solutions could be adding a "this is a special rate control alg which shouldn't be selected automatically" flag to rate control algs and not selecting such algorithms in
ieee80211_try_rate_control_ops_getwhen 'name' is NULL. Should be easy to implement.
Maybe go all the way then and somehow tie it to specific information it requires from the hardware that most hardware doesn't give it?
johannes