Since we started the discussion about ath5k and proprietary features i
started a new thread to continue.
So this is what we have...
a) X.R.: eXtended Range is a set of proprietary rates and some extra
techniques (various hw tweaks etc) to enable long distance, low
bandwidth links. This feature was never really supported on MadWiFi
(some code for sta mode is there but i don't think anyone used it) and
it's ugly (sends beacons on both 1Mbit and 250Kbit, has some sort of
polling mechanism etc). We should remove XR stuff since we all agree
that we won't support it + even if we want we don't have anything to
work with anyway, 5/10MHz channels should be enough for long distance
links. Just leave XR rate code definitions there for reference (in
case we get any of these from the card -normally we shouldn't but it's
good to know all hw rate code values).
b) OFDM-only g settings for AR5211: AR5211 chips have support for
draft-g (eg. no dynamic CCK/OFDM modulation, only OFDM). I don't know
if we want to support it or not, removing the settings will save us
some space and since it's a draft g implementation i don't think there
are many compatible APs out there. Is there any possibility to support
draft-g on mac80211/cfg80211 ? If not we can just drop it else it's
just some extra data, no big deal.
c) Half/quarter rate channels (10/5MHz width) and turbo mode (double
rate - 40MHz width): Hw can transmit with different channel width
allowing us to operate on half, quarter or double rate (also called
turbo mode). Half and quarter rates are straight forward (just
re-program pll/clock and tweak various phy/rf settings) and most chips
support it, turbo mode on the other hand has some extra parameters and
is supported only on super ag enabled (non-lite) chips
(5212,2414,5414,5424 etc). First we want to use it only on "middle"
channels so that we don't get outside band boundaries when changing
channel width, so we have to limit the available channels we can use
(check out super ag white paper), second we have the opportunity to
support both 20MHz and 40MHz at the same time by using "dynamic turbo"
feature on hw so if we are an AP we can deal both with turbo-enabled
clients and normal clients. I was thinking if we are going to have an
API to set channel width to 10 and 5 MHz for half and quarter rate
channels, we can use the same API to set channel width to 40MHz width
for double rate channels on cards that support it and when we are on
AP mode use the "dynamic turbo" stuff. We don't even have to call it
turbo mode, it's just double rate + some tweaks.
Most code is there for half/quarter and (static) turbo operation, we
just have to deal with pll programming, clock settings etc. Question
is how do we use it, NL80211_CMD_TESTMODE is an option i guess and in
case no one else thinks that we could use a channel width API (or
extend what we have) for setting 5/10/40MHz width through cfg80211, we
can just stick to NL80211_CMD_TESTMODE.
d) Fast frames: Hw can tx/rx jumbo frames of 3kbytes+ so fast frame
aggregation is a way to make use of that hw feature by sending 2
frames together (for more infos check out super ag white paper). On
FreeBSD fast frames aggregation is implemented on the protocol stack
(net80211) so that any hw that can tx/rx such jumbo frames can use
fast frame aggregation
(http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net80211/ieee80211_superg.c?rev=1.7;content-type=text%2Fx-cvsweb-markup;sortby=rev)
but it still maintains atheros's format to be compatible with
commercial Atheros APs. We have talked about this and it seems no one
is willing to support fast frames aggregation so on ath5k we only use
single tx/rx descriptors and there is no related code for handling
multiple descriptors.
e) Compression: Hw can do on-chip compression/decompression using
standard Lempel Ziv algorithm per tx queue, MadWiFi implements this
and uses a vendor IE to let others know that it supports this feature
(same IE is used for all capabilities, fast frames, XR etc). I guess
this can also work for other cards by doing compression/decompression
on software since it's a standard algorithm (and i think kernel
already has code for it) but it's way outside cfg80211/mac80211's
scope. I think we can just use NL80211_CMD_TESTMODE to enable/disable
this on all data queues and skip the IE stuff (user will have to
enable it on both sides to make it work). There is no related code on
ath5k for compression/decompression at the moment.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
2009/8/29 Benoit PAPILLAULT <[email protected]>:
>
> I have been working on XR (in madwifi) for some time with no result. I
> would appreciate to be able to test it in ath5k.
All XR related stuff is missing from both Legacy and Sam's HAL + it's
nasty IMHO. We need to define new rates, send beacons on both 0.25 and
1Mbits, use that polling mechanism, introduce a new IE etc. It 'll
need lots of changes and the code will get even more complex + if we
want to do it right at least the polling mechanism has to go to
mac80211 and i don't think anyone wants that, imagine if every vendor
started putting proprietary stuff like that on mac80211 (and there are
way more nasty vendor specific stuff). I don't want to see
ath5k/mac80211 become like MadWiFi. If we can find a way to support XR
on ath5k without touching mac80211 then we can talk about it but right
now we don't even know how to make it work.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Sat, Aug 29, 2009 at 8:47 AM, Nick Kossifidis<[email protected]> wrote:
> 2009/8/29 Benoit PAPILLAULT <[email protected]>:
>>
>> I have been working on XR (in madwifi) for some time with no result. I
>> would appreciate to be able to test it in ath5k.
>
> All XR related stuff is missing from both Legacy and Sam's HAL + it's
> nasty IMHO.
Agreed.
Luis
Hi All,
I am VERY interested in XR.
John
On Sat, Aug 29, 2009 at 07:51:29AM +0300, Nick Kossifidis wrote:
> Most code is there for half/quarter and (static) turbo operation, we
> just have to deal with pll programming, clock settings etc. Question
> is how do we use it, NL80211_CMD_TESTMODE is an option i guess and in
> case no one else thinks that we could use a channel width API (or
> extend what we have) for setting 5/10/40MHz width through cfg80211, we
> can just stick to NL80211_CMD_TESTMODE.
Well, we will have a channel width API, I think; several people
have expresed an interest in doing so.
Your summary is useful, and I really don't have any qualms about
keeping the non-standard stuff as long as someone has plans to
write the code to support it. I personally have no interest
in using those features, but of course I only speak for me.
If we do remove turbo code for now, we can leave the initvals, as
they are such a pain to verify. But I'm not sure half a page of
text is worth the churn.
--
Bob Copeland %% http://www.bobcopeland.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nick Kossifidis a ?crit :
> Since we started the discussion about ath5k and proprietary
> features i started a new thread to continue.
>
> So this is what we have...
>
> a) X.R.: eXtended Range is a set of proprietary rates and some
> extra techniques (various hw tweaks etc) to enable long distance,
> low bandwidth links. This feature was never really supported on
> MadWiFi (some code for sta mode is there but i don't think anyone
> used it) and it's ugly (sends beacons on both 1Mbit and 250Kbit,
> has some sort of polling mechanism etc). We should remove XR stuff
> since we all agree that we won't support it + even if we want we
> don't have anything to work with anyway, 5/10MHz channels should be
> enough for long distance links. Just leave XR rate code definitions
> there for reference (in case we get any of these from the card
> -normally we shouldn't but it's good to know all hw rate code
> values).
I have been working on XR (in madwifi) for some time with no result. I
would appreciate to be able to test it in ath5k.
>
> b) OFDM-only g settings for AR5211: AR5211 chips have support for
> draft-g (eg. no dynamic CCK/OFDM modulation, only OFDM). I don't
> know if we want to support it or not, removing the settings will
> save us some space and since it's a draft g implementation i don't
> think there are many compatible APs out there. Is there any
> possibility to support draft-g on mac80211/cfg80211 ? If not we can
> just drop it else it's just some extra data, no big deal.
>
> c) Half/quarter rate channels (10/5MHz width) and turbo mode
> (double rate - 40MHz width): Hw can transmit with different channel
> width allowing us to operate on half, quarter or double rate (also
> called turbo mode). Half and quarter rates are straight forward
> (just re-program pll/clock and tweak various phy/rf settings) and
> most chips support it, turbo mode on the other hand has some extra
> parameters and is supported only on super ag enabled (non-lite)
> chips (5212,2414,5414,5424 etc). First we want to use it only on
> "middle" channels so that we don't get outside band boundaries when
> changing channel width, so we have to limit the available channels
> we can use (check out super ag white paper), second we have the
> opportunity to support both 20MHz and 40MHz at the same time by
> using "dynamic turbo" feature on hw so if we are an AP we can deal
> both with turbo-enabled clients and normal clients. I was thinking
> if we are going to have an API to set channel width to 10 and 5 MHz
> for half and quarter rate channels, we can use the same API to set
> channel width to 40MHz width for double rate channels on cards that
> support it and when we are on AP mode use the "dynamic turbo"
> stuff. We don't even have to call it turbo mode, it's just double
> rate + some tweaks.
>
> Most code is there for half/quarter and (static) turbo operation,
> we just have to deal with pll programming, clock settings etc.
> Question is how do we use it, NL80211_CMD_TESTMODE is an option i
> guess and in case no one else thinks that we could use a channel
> width API (or extend what we have) for setting 5/10/40MHz width
> through cfg80211, we can just stick to NL80211_CMD_TESTMODE.
5/10 MHz channels are defined in 802.11-2007, so it must be part of
mac80211 and supported by ath5k if the HW support it. For 40 MHz, as
far as the mac80211 API is concerned, we could treat it like HT40,
even it's clearly a proprietary extension.
>
> d) Fast frames: Hw can tx/rx jumbo frames of 3kbytes+ so fast frame
> aggregation is a way to make use of that hw feature by sending 2
> frames together (for more infos check out super ag white paper). On
> FreeBSD fast frames aggregation is implemented on the protocol
> stack (net80211) so that any hw that can tx/rx such jumbo frames
> can use fast frame aggregation
> (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net80211/ieee80211_superg.c?rev=1.7;content-type=text%2Fx-cvsweb-markup;sortby=rev)
> but it still maintains atheros's format to be compatible with
> commercial Atheros APs. We have talked about this and it seems no
> one is willing to support fast frames aggregation so on ath5k we
> only use single tx/rx descriptors and there is no related code for
> handling multiple descriptors.
>
> e) Compression: Hw can do on-chip compression/decompression using
> standard Lempel Ziv algorithm per tx queue, MadWiFi implements this
> and uses a vendor IE to let others know that it supports this
> feature (same IE is used for all capabilities, fast frames, XR
> etc). I guess this can also work for other cards by doing
> compression/decompression on software since it's a standard
> algorithm (and i think kernel already has code for it) but it's way
> outside cfg80211/mac80211's scope. I think we can just use
> NL80211_CMD_TESTMODE to enable/disable this on all data queues and
> skip the IE stuff (user will have to enable it on both sides to
> make it work). There is no related code on ath5k for
> compression/decompression at the moment.
>
>
>
My whole feeling is that an operating system, be it GNU/Linux,
Windows(tm), *bsd or whatever is here to bring all the HW features to
the user. So if users are interested by any of the above features, be
it proprietary or not, we need to find a way to allow their
implementation in ath5k. Some of those implementations would need
mac80211 changes, so we need to decide if we want a proper mac80211
support for all those features (proprietary or not) or if mac80211
only wants to support standard features (which seems fair) and find
another way to support proprietary features.
Regards,
Benoit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqY1lYACgkQOR6EySwP7oJTZACfUO8m4OXls+5yVLMbnn/oax0E
vTcAoO9NJ5Wdtr3gNEALF0sPk4RxNj7c
=5Srl
-----END PGP SIGNATURE-----
Hi,
I am working on a research project which needs to change the channel
width to 5,10 and 40MHz. Ive been looking through the mailing lists and
there seems to be some interest in having an API built for this.
Would it be possible for someone to please outline the steps needed to
enable 5,10,40 MHz channels? I am not looking for a clean implemented
API, just whatever hack is required to change the PLL clock, modify
PHY/RF settings (as mentioned in the thread below) in order to get this
to work.
Thanks very much for your help
regards,
Aditya Bhave
Pavel Roskin wrote:
> On Sat, 2009-08-29 at 07:51 +0300, Nick Kossifidis wrote:
>
>
>> a) X.R.: eXtended Range is a set of proprietary rates and some extra
>> techniques (various hw tweaks etc) to enable long distance, low
>> bandwidth links.
>>
>
> I'm not interested because it's ugly and we don't have a good reference
> implementation. Besides, there must be a reason why it's not in the
> FreeBSD HAL. Either it's patented or Atheros was ashamed to expose that
> code.
>
>
>> b) OFDM-only g settings for AR5211: AR5211 chips have support for
>> draft-g (eg. no dynamic CCK/OFDM modulation, only OFDM). I don't know
>> if we want to support it or not, removing the settings will save us
>> some space and since it's a draft g implementation i don't think there
>> are many compatible APs out there. Is there any possibility to support
>> draft-g on mac80211/cfg80211 ? If not we can just drop it else it's
>> just some extra data, no big deal.
>>
>
> If there is a simple way to support it, let's do it. I think having
> "pure G" may be a good idea in some situations, regardless of the
> hardware limitations. But that's something that should be done in
> mac80211.
>
> I would keep the initialization code for now.
>
> That said, AR5210 and AR5211 are so rare, that we might consider
> splitting them into separate drivers that would not be actively
> maintained.
>
>
>> c) Half/quarter rate channels (10/5MHz width) and turbo mode (double
>> rate - 40MHz width): Hw can transmit with different channel width
>> allowing us to operate on half, quarter or double rate (also called
>> turbo mode).
>>
>
> It would be nice to be able to receive on wide and narrow channels, at
> least in the monitor mode. Generally, "be liberal in what you accept,
> and conservative in what you send".
>
> We'll need some API to set the bandwidth and radiotap flags to
> communicate the bandwidth to the recipient.
>
>
>> d) Fast frames: Hw can tx/rx jumbo frames of 3kbytes+ so fast frame
>> aggregation is a way to make use of that hw feature by sending 2
>> frames together (for more infos check out super ag white paper).
>>
>
> Likewise, it would be nice to receive them.
>
>
>> e) Compression: Hw can do on-chip compression/decompression using
>> standard Lempel Ziv algorithm per tx queue, MadWiFi implements this
>> and uses a vendor IE to let others know that it supports this feature
>> (same IE is used for all capabilities, fast frames, XR etc).
>>
>
> Same thing here, as long as we can reuse the existing kernel code for
> decompression.
>
>
On Sat, 2009-08-29 at 07:51 +0300, Nick Kossifidis wrote:
> a) X.R.: eXtended Range is a set of proprietary rates and some extra
> techniques (various hw tweaks etc) to enable long distance, low
> bandwidth links.
I'm not interested because it's ugly and we don't have a good reference
implementation. Besides, there must be a reason why it's not in the
FreeBSD HAL. Either it's patented or Atheros was ashamed to expose that
code.
> b) OFDM-only g settings for AR5211: AR5211 chips have support for
> draft-g (eg. no dynamic CCK/OFDM modulation, only OFDM). I don't know
> if we want to support it or not, removing the settings will save us
> some space and since it's a draft g implementation i don't think there
> are many compatible APs out there. Is there any possibility to support
> draft-g on mac80211/cfg80211 ? If not we can just drop it else it's
> just some extra data, no big deal.
If there is a simple way to support it, let's do it. I think having
"pure G" may be a good idea in some situations, regardless of the
hardware limitations. But that's something that should be done in
mac80211.
I would keep the initialization code for now.
That said, AR5210 and AR5211 are so rare, that we might consider
splitting them into separate drivers that would not be actively
maintained.
> c) Half/quarter rate channels (10/5MHz width) and turbo mode (double
> rate - 40MHz width): Hw can transmit with different channel width
> allowing us to operate on half, quarter or double rate (also called
> turbo mode).
It would be nice to be able to receive on wide and narrow channels, at
least in the monitor mode. Generally, "be liberal in what you accept,
and conservative in what you send".
We'll need some API to set the bandwidth and radiotap flags to
communicate the bandwidth to the recipient.
> d) Fast frames: Hw can tx/rx jumbo frames of 3kbytes+ so fast frame
> aggregation is a way to make use of that hw feature by sending 2
> frames together (for more infos check out super ag white paper).
Likewise, it would be nice to receive them.
> e) Compression: Hw can do on-chip compression/decompression using
> standard Lempel Ziv algorithm per tx queue, MadWiFi implements this
> and uses a vendor IE to let others know that it supports this feature
> (same IE is used for all capabilities, fast frames, XR etc).
Same thing here, as long as we can reuse the existing kernel code for
decompression.
--
Regards,
Pavel Roskin
On Sat, Aug 29, 2009 at 07:51:29AM +0300, Nick Kossifidis wrote:
> Since we started the discussion about ath5k and proprietary features i
> started a new thread to continue.
> a) X.R.: eXtended Range is a set of proprietary rates and some extra
> techniques (various hw tweaks etc) to enable long distance, low
> bandwidth links. This feature was never really supported on MadWiFi
> (some code for sta mode is there but i don't think anyone used it) and
> it's ugly (sends beacons on both 1Mbit and 250Kbit, has some sort of
> polling mechanism etc). We should remove XR stuff since we all agree
> that we won't support it + even if we want we don't have anything to
> work with anyway, 5/10MHz channels should be enough for long distance
> links. Just leave XR rate code definitions there for reference (in
> case we get any of these from the card -normally we shouldn't but it's
> good to know all hw rate code values).
Agreed, I see no place for this in neither ath5k (or ath9k for that
matter) nor mac80211 (please note that it does require changes that
would fit into the mac80211/hostapd areas in our design and neither of
those are going to accept these changes even if the driver were.. ;-).
> b) OFDM-only g settings for AR5211: AR5211 chips have support for
> draft-g (eg. no dynamic CCK/OFDM modulation, only OFDM). I don't know
> if we want to support it or not, removing the settings will save us
> some space and since it's a draft g implementation i don't think there
> are many compatible APs out there. Is there any possibility to support
> draft-g on mac80211/cfg80211 ? If not we can just drop it else it's
> just some extra data, no big deal.
I don't see why we would want to support this at this point. I don't
really think there is much use for this and I see no point in making
mac80211/cfg80211 more complex for such a corner case.
> c) Half/quarter rate channels (10/5MHz width) and turbo mode (double
> rate - 40MHz width): Hw can transmit with different channel width
> allowing us to operate on half, quarter or double rate (also called
> turbo mode). Half and quarter rates are straight forward (just
> re-program pll/clock and tweak various phy/rf settings) and most chips
> support it, turbo mode on the other hand has some extra parameters and
> is supported only on super ag enabled (non-lite) chips
> (5212,2414,5414,5424 etc). First we want to use it only on "middle"
> channels so that we don't get outside band boundaries when changing
> channel width, so we have to limit the available channels we can use
> (check out super ag white paper), second we have the opportunity to
> support both 20MHz and 40MHz at the same time by using "dynamic turbo"
> feature on hw so if we are an AP we can deal both with turbo-enabled
> clients and normal clients. I was thinking if we are going to have an
> API to set channel width to 10 and 5 MHz for half and quarter rate
> channels, we can use the same API to set channel width to 40MHz width
> for double rate channels on cards that support it and when we are on
> AP mode use the "dynamic turbo" stuff. We don't even have to call it
> turbo mode, it's just double rate + some tweaks.
I consider this c item to be three different cases:
(1) standard-defined 5/10 MHz width channels
(2) proprietary channel binding (static 40 MHz turbo)
(3) proprietary dynamic 20/40 MHz turbo
As far as (1) is concerned, I see some value in supporting it. However,
at this point I would probably not enable those channels by default
(i.e., I do not want to see them making scan take any more time than it
already does).
(3) is on a not-going-to-happen list as far as I'm concerned since it
requires changes both in mac80211 and hostapd, too, and good luck trying
to get this in there.. ;-)
(2) is somewhat of a corner case. It would probably be possible to
somehow support it as a driver specific hack. While I would personally
prefer not to see this, I would probably be fine with it being there as
long as these channels are not enabled by default (the same comment as
for 5/10 MHz channels and scan).
> d) Fast frames: Hw can tx/rx jumbo frames of 3kbytes+ so fast frame
> aggregation is a way to make use of that hw feature by sending 2
> frames together (for more infos check out super ag white paper). On
> FreeBSD fast frames aggregation is implemented on the protocol stack
> (net80211) so that any hw that can tx/rx such jumbo frames can use
> fast frame aggregation
> (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net80211/ieee80211_superg.c?rev=1.7;content-type=text%2Fx-cvsweb-markup;sortby=rev)
> but it still maintains atheros's format to be compatible with
> commercial Atheros APs. We have talked about this and it seems no one
> is willing to support fast frames aggregation so on ath5k we only use
> single tx/rx descriptors and there is no related code for handling
> multiple descriptors.
I don't see how this would get added to mac80211. If someone really
wants to spend time on this type of feature, I would suggest adding
support for A-MSDU aggregation (the TX side of it) into mac80211 and
making it usable with non-HT cases, too. That should result in something
quite similar to fast frames, but with a format that is actually defined
by IEEE. Sure, this would not be compatible with legacy Super A/G APs,
but could be used between two mac80211-based devices.
> e) Compression: Hw can do on-chip compression/decompression using
> standard Lempel Ziv algorithm per tx queue, MadWiFi implements this
> and uses a vendor IE to let others know that it supports this feature
> (same IE is used for all capabilities, fast frames, XR etc). I guess
> this can also work for other cards by doing compression/decompression
> on software since it's a standard algorithm (and i think kernel
> already has code for it) but it's way outside cfg80211/mac80211's
> scope. I think we can just use NL80211_CMD_TESTMODE to enable/disable
> this on all data queues and skip the IE stuff (user will have to
> enable it on both sides to make it work). There is no related code on
> ath5k for compression/decompression at the moment.
Even compression needs some negotiation support (i.e., mac80211/hostapd
are actually in scope) and there are some ugly corner cases showing up
issues with it.. I don't see much point in supporting this either.
--
Jouni Malinen PGP id EFC895FA
On Fri, Aug 28, 2009 at 9:51 PM, Nick Kossifidis<[email protected]> wrote:
FWIW I plan on ignoring all bug reports for all of these vendor
extensions. The only thing I may consider looking at is 10 / 5 MHz
channel bandwidth usage and when its allowed by the standard.
Luis