From: Simon Wunderlich <[email protected]>
This patchset adds support for 5 and 10 MHz in nl80211/cfg80211/mac80211
and enables support in ath5k and ath9k, which already support this feature
on the driver side. 5 and 10 MHz wide channels might be useful for:
* long shot links, as the transmissions are more robust
* future support for 802.11y which allows some 5 and 10 MHz channels in
3.6 GHz range
* future support for 802.11p which uses 10 MHz in 5.9 GHz range
* ... and more "special" applications.
Note that the transmissions are only defined for the OFDM PHY in the
standard and are therefore limited to 5 GHz, no HT or MIMO here. However,
at least my AR5K and AR9K based chips seem to support this mode on 2.4 GHz
as well. Datarates are halfed or quartered, leaving up to 27 Mbit/s or
13.5 Mbit/s gross rates respectively.
Some benchmark results (IBSS, iperf, ath9k on AR9220, ath5k on AR5213A):
* ath5k -> ath5k:
5.23 Mbit/s @ 5 MHz
10.8 Mbit/s @ 10 MHz
19.1 Mbit/s @ 20 MHz (NOHT mode)
* ath9k -> ath9k:
5.24 Mbit/s @ 5 MHz
10.9 Mbit/s @ 10 MHz
16.4 Mbit/s @ 20 MHz (NOHT mode, appears to be a little bit low though)
Comments:
* Is there any special requirement for handling beacons? For example,
rates are halfed or quartered, but some rates could not be represented
in the rate IEs. For example, 2.25 mbit/s can not be represented as
multiple of 500 kbps.
* therefore, all rates are handled like the corresponding 20 MHz rates
internally, which makes a lot of things easier (no changes required
for rc-algos, beacon creation, etc...). We might consider adjusting the
output of rates for nl80211 or radiotap, though.
As always, any comments are appreciated!
Cheers,
Simon
Simon Wunderlich (8):
nl80211/cfg80211: add 5 and 10 MHz defines and wiphy flag
mac80211: fix various components for the new 5 and 10 MHz widths
mac80211: change IBSS channel state to chandef
mac80211: fix timing for 5 MHz and 10 MHz channels
nl80211: allow 5 and 10 MHz channels for IBSS
ath9k: convert to chandef, enable support for 5/10 MHz channels
ath9k: announce that ath9k supports 5/10 MHz
ath5k: enable support for 5 MHz and 10 MHz channels
drivers/net/wireless/ath/ath5k/ath5k.h | 1 +
drivers/net/wireless/ath/ath5k/base.c | 25 +++++++--
drivers/net/wireless/ath/ath5k/base.h | 2 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
drivers/net/wireless/ath/ath9k/common.c | 67 +++++++++++++++----------
drivers/net/wireless/ath/ath9k/common.h | 3 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 5 +-
drivers/net/wireless/ath/ath9k/init.c | 5 +-
drivers/net/wireless/ath/ath9k/main.c | 8 ++-
drivers/net/wireless/ath/ath9k/rc.c | 4 +-
include/net/cfg80211.h | 2 +
include/uapi/linux/nl80211.h | 4 ++
net/mac80211/ibss.c | 24 +++++----
net/mac80211/ieee80211_i.h | 45 +++++++++++++++--
net/mac80211/mesh.c | 4 +-
net/mac80211/mesh_plink.c | 8 ++-
net/mac80211/mlme.c | 12 +++++
net/mac80211/rate.c | 8 ++-
net/mac80211/rc80211_minstrel.c | 14 ++++--
net/mac80211/rc80211_minstrel_ht.c | 8 +--
net/mac80211/tx.c | 10 ++--
net/mac80211/util.c | 43 +++++++++++-----
net/wireless/chan.c | 29 +++++++++++
net/wireless/nl80211.c | 23 +++++++--
24 files changed, 266 insertions(+), 90 deletions(-)
--
1.7.10.4
Hey,
On Fri, May 10, 2013 at 02:12:00AM -0700, Adrian Chadd wrote:
> On 10 May 2013 00:26, Johannes Berg <[email protected]> wrote:
> > On Thu, 2013-05-09 at 20:10 +0200, a@pandem0nium wrote:
> >
> >> Comments:
> >> * Is there any special requirement for handling beacons? For example,
> >> rates are halfed or quartered, but some rates could not be represented
> >> in the rate IEs. For example, 2.25 mbit/s can not be represented as
> >> multiple of 500 kbps.
> >> * therefore, all rates are handled like the corresponding 20 MHz
> >> rates
> >> internally, which makes a lot of things easier (no changes required
> >> for rc-algos, beacon creation, etc...). We might consider adjusting
> >> the
> >> output of rates for nl80211 or radiotap, though.
> >
> > This seems completely wrong, since Clause 18 says:
> >
> > The OFDM system also provides a “half-clocked” operation using
> > 10 MHz channel spacings with data communications capabilities of
> > 3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s. The support of
> > transmitting and receiving at data rates of 3, 6, and 12 Mb/s is
> > mandatory when using 10 MHz channel spacing. The half-clocked
> > operation doubles symbol times and clear channel assessment
> > (CCA) times when using 10 MHz channel spacing. The regulatory
> > requirements and information regarding use of this OFDM PHY are
> > in Annex D and Annex E.
> >
> > IOW, it treats the rates as actually the rate they should be. Besides,
> > what's so hard about rounding up? (8.4.2.4)
> >
> > and bits 6 to 0 are set to the data rate, if necessary rounded
> > up to the next 500kb/s, in units of 500 kb/s.
> >
> >
> > I also think you really need to handle this. If you just want a hack for
> > 5/10 MHz, you can put it into drivers' debugfs, if not, then it should
> > be done properly :-)
>
> I think net80211 from FreeBSD and madwifi do this. Ie, they advertise
> the half and quarter rate speeds as their real speeds at half/quarter
> rate.
Ah, OK.
>
> If anything, interoperability would be nice.
Yes interoperability would be nice of course - I'll re-work the patchset
to use the according half and quarter rates. Meanwhile, what do you guys think
about enabling HT too?
Cheers,
Simon
>
>
>
>
> Adrian
On Thu, 2013-05-09 at 20:10 +0200, a@pandem0nium wrote:
> Comments:
> * Is there any special requirement for handling beacons? For example,
> rates are halfed or quartered, but some rates could not be represented
> in the rate IEs. For example, 2.25 mbit/s can not be represented as
> multiple of 500 kbps.
> * therefore, all rates are handled like the corresponding 20 MHz
> rates
> internally, which makes a lot of things easier (no changes required
> for rc-algos, beacon creation, etc...). We might consider adjusting
> the
> output of rates for nl80211 or radiotap, though.
This seems completely wrong, since Clause 18 says:
The OFDM system also provides a “half-clocked” operation using
10 MHz channel spacings with data communications capabilities of
3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s. The support of
transmitting and receiving at data rates of 3, 6, and 12 Mb/s is
mandatory when using 10 MHz channel spacing. The half-clocked
operation doubles symbol times and clear channel assessment
(CCA) times when using 10 MHz channel spacing. The regulatory
requirements and information regarding use of this OFDM PHY are
in Annex D and Annex E.
IOW, it treats the rates as actually the rate they should be. Besides,
what's so hard about rounding up? (8.4.2.4)
and bits 6 to 0 are set to the data rate, if necessary rounded
up to the next 500kb/s, in units of 500 kb/s.
I also think you really need to handle this. If you just want a hack for
5/10 MHz, you can put it into drivers' debugfs, if not, then it should
be done properly :-)
johannes
On Fri, 2013-05-10 at 11:32 +0200, Simon Wunderlich wrote:
> Yes interoperability would be nice of course - I'll re-work the patchset
> to use the according half and quarter rates. Meanwhile, what do you guys think
> about enabling HT too?
I'd like to stick to the standard first. Enabling HT is nice for us, but
I'd like to see it done in a way that doesn't clash with a possible
future amendment doing it officially.
johannes
On 10 May 2013 00:26, Johannes Berg <[email protected]> wrote:
> On Thu, 2013-05-09 at 20:10 +0200, a@pandem0nium wrote:
>
>> Comments:
>> * Is there any special requirement for handling beacons? For example,
>> rates are halfed or quartered, but some rates could not be represented
>> in the rate IEs. For example, 2.25 mbit/s can not be represented as
>> multiple of 500 kbps.
>> * therefore, all rates are handled like the corresponding 20 MHz
>> rates
>> internally, which makes a lot of things easier (no changes required
>> for rc-algos, beacon creation, etc...). We might consider adjusting
>> the
>> output of rates for nl80211 or radiotap, though.
>
> This seems completely wrong, since Clause 18 says:
>
> The OFDM system also provides a ?half-clocked? operation using
> 10 MHz channel spacings with data communications capabilities of
> 3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s. The support of
> transmitting and receiving at data rates of 3, 6, and 12 Mb/s is
> mandatory when using 10 MHz channel spacing. The half-clocked
> operation doubles symbol times and clear channel assessment
> (CCA) times when using 10 MHz channel spacing. The regulatory
> requirements and information regarding use of this OFDM PHY are
> in Annex D and Annex E.
>
> IOW, it treats the rates as actually the rate they should be. Besides,
> what's so hard about rounding up? (8.4.2.4)
>
> and bits 6 to 0 are set to the data rate, if necessary rounded
> up to the next 500kb/s, in units of 500 kb/s.
>
>
> I also think you really need to handle this. If you just want a hack for
> 5/10 MHz, you can put it into drivers' debugfs, if not, then it should
> be done properly :-)
I think net80211 from FreeBSD and madwifi do this. Ie, they advertise
the half and quarter rate speeds as their real speeds at half/quarter
rate.
If anything, interoperability would be nice.
Adrian
On Thu, May 09, 2013 at 08:10:28PM +0200, a@pandem0nium wrote:
> [...]
I wonder if I'll ever learn to use send git send-email properly ... please
consider this as sent "From: Simon Wunderlich <[email protected]>"
and sorry for the confusion.
Thanks!
Simon