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
