2009/9/15 Tomas Dulik <du...@fai.utb.cz>: > Dear All, > > I address you - the developers of the ath5k driver - on behalf of all the > members of the Research & Development workgroup found by NFX (Neutral czFree > eXchange, the association of Czech non-commercial non-government free > networks). The purpose of this long announcement is to explain our > motivation for starting a long term contribution to the ath5k development > and to declare our areas of interests, so you can react somehow before we > start the development (possibly duplicating somebody else's work or doing > something which would never make it into the Linux kernel). > > After the ath5k project presentation made by Jiri Slaby at our > seminar/workshop in June, we finaly decided to support the ath5k development > by providing one full-time developer dedicated solely to the ath5k > development.
Wow great news! > Our primary motivation for this commitment are the external wireless > networks that the NFX member organizations operate - currently, they have > about 30 000 users and we guess that at least 50% of them are connected to > their networks by an Atheros-based HW. > > Therefore, we need the Atheros drivers to be as stable and as functional as > possible. But this year, we have got the impression that we have been > waiting too long too passively and that we should start doing something more > active to achieve our goals. > > So what are our goals, or better said: where we want to contribute? > > In short term (e.g., until Christmas): > > Most of all, we need the AP (master) mode to be absolutely stable. APs > operated by NFX members are running 24/7/365 in very difficult environment > (noise, high traffic, incorrect implementations of the connected stations..) > and therefore, their stability is crucial. AP stability work is greatly appreciated. > We need to get the TX power logic working. We have done some measurements of > ath5k & Madwifi on various miniPCI cards using a borrowed R&S spectral > analyzer with the K91 WLAN plugin and we found that both ath5k and Madwifi > does not behave correctly here (Jiri Slaby can confirm because he was > present when we were demonstrating these measurements on a workshop last > week). The improper TX power settings for given bitrate/modulation increases > the EVM (error vector magnitude) right at the transmitter output which > results in packet errors and consequent fallbacks to lower bitrates. Thanks for reviewing this. I am curious, is there any driver you did use that *did* give you proper results? > We need to support and very thoroughly validate the behaviour of the Atheros > ANI feature. We suspect that the improper driver control of this feature is > probably causing complete transmission failures of some Atheros cards e.g. > under commercial Mikrotik drivers when there are high noise levels present > (caused by high traffic in adjacent channels). In the latest versions of > Madwifi, there was a patch for this, but with this patch, we started to see > the "Stucked beacon" errors causing disconnects of the connected stations, > which is not acceptable behaviour ANI is completely lacking on ath5k. > In long term: > > We need to implement the Automation of testing project. But the Orbit > testbed mentioned in this project specification is not sufficient for us, > because we need to have a testbed aimed at external wifi networks. Just FYI, Orbit actually as set of external nodes as well. > So > instead of using anntenas, we are connecting our test nodes by coax cables, > fixed & programmable attenuators, couplers and RF switches. Orbit has this arrangement but for sandboxes, which is what you typically would use prior to a large experiment on the large grid. > For our testbed, > we also need to implement cheaper signal generators and analyzers (e.g., > using the USRP2) which would allow simulating all the various effects > present in external wifi networks - e.g., local noise, multipath > propagation, long distance links etc. Neat :) > We have a lot of ideas for improving the behaviour of WiFi in Linux. Some of > these ideas were already implemented as prototypes - e. g. the flow > controller which is scheduling the WiFi packets according to their > transmition time. Is there a link to this you can provide? You may want to submit it for review to linux-wireless. > This scheduler greatly improves the performace of the WiFi > APs in cases when there are stations with bad signal and low bit rates. But > we would like to see these improvements as stable part of Linux kernel... > > Finally, here is a management summary of what we offer: > > long term, highly motivated contribution > one full time programmer - Lukas Turek, who already hacked the Madwifi to > implement the TX-time-based flow controller as his MSc. thesis. > access to nicely equiped university labs. Me and Lukas are working on our > PhDs at TBU university in Zlin and have access to nice toys like R&S > spectral analyzers up to 40GHz. Currently we are searching the possibilities > for buying a WiFi generator (e.g., R&S SMBV100A) which would allow us to > test also the RX parts of various WiFi cards/devices in very consistent and > deterministic conditions. > > I am looking forward your feedback and also for us becoming a part of the > Linux Wireless developers community! This is great news! Hope to see some patches soon! Luis _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
