Re: [ath5k-devel] Ath5k and proprietary extensions
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. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Ath5k and proprietary extensions
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
Re: [ath5k-devel] Ath5k and proprietary extensions
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 ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Ath5k and proprietary extensions
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 %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Ath5k and proprietary extensions
On Sat, Aug 29, 2009 at 8:47 AM, Nick Kossifidismickfl...@gmail.com wrote: 2009/8/29 Benoit PAPILLAULT benoit.papilla...@free.fr: 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 ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
