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. >
Great news, check out our TODO list here and add any new stuff you are working on ;-) http://wireless.kernel.org/en/users/Drivers/ath5k#ath5k_TODO > 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 mode is mostly working with hostapd, we need some work on wme support (register more tx queues on protocol stack etc), buffered frames, multi bssid handling (masks etc) and power saving. > 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. If you read the TODO page you'll see that it "works but experiments show that the card transmits only on some standard power levels instead of a power range as expected". I also have a R&S spectrum analyzer on the lab i work but it doesn't have a vector analyzer (i can't see the QAM constellation etc) but you can also see that behaviour with just another atheros card and a few attenuators. I don't think it's a software problem, i think that vendors don't care to calibrate their cards propertly.+ some of them don't even follow the atheros reference design. > 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 I have a patch for ANI support but it needs work and i'm out of time right now, you can find it on this list. This is still work in progress. > 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. So > instead of using anntenas, we are connecting our test nodes by coax cables, > fixed & programmable attenuators, couplers and RF switches. 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. We use a very similar testbed on our lab + an outdoor wireless network, all atheros-based. > 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. 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. Cool, welcome guys ;-) -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
