Hi Thomas (and all), I have access to an Agilent VSA and VSG, but I don't have any basis for comparing them with any other manufacturer's equipment. If you have particular questions, I'll do my best to answer them, but that's about all I can really offer.
-Eric Thus spake Tomas Dulik (du...@fai.utb.cz): > Thanks for reviewing this. I am curious, is there any driver you did > use that *did* give you proper results? > > Unfortunatelly, we've had the R&S FSV analyzer (equipped with all the > mobile protocol options including the 802.11a/b/g/n) borrowed only for 2 > weeks, together with the R&S SMBV100A generator, which was also equipped > with all the SW options. > > The purpose of the borrow was to test the analyzer and compare it to our > older FSP one, and also to learn what the generator can do. So we have > spent most of the time by playing with these two wonderful toys and > therefore we have done only few measurements with real WiFi devices. > > Now we are filling an application for grant which would give us the budget > for buying these machines here for permanent use, because being able to > e.g. inject exact (=guaranteed by regular calibration) power levels of > useful traffic or noise or adjacent channel traffic would be a big help > when testing & debugging things like ANI... > > BTW, has anybody from linux-wireless access to such specific measurement & > test machines? I mean vector signal analyzers/generators equipped with > WLAN options, produced by R&S, Agilent or NI ? > I would be grateful for some tips and comparisons - the prices for R&S and > Agilent and quite comparable, but I haven't seen the Agilent WLAN SW so am > not sure what are the differences. > > Just FYI, Orbit actually as set of external nodes as well. > > I could not find anything about the external nodes [1]on the Orbit web so > I have already sent them a question asking if there is chance to support > this kind of setup. > > Is there a link to this you can provide? You may want to submit it for > review to linux-wireless. > > > Lukas Turek's freshly finished MSc. project is written in Czech, but we > will extract the essence of it into a conference paper format in English > and we will sent this to the linux-wireless for a feedback. > > Tomas > > Luis R. Rodriguez napsal(a): > > 2009/9/15 Tomas Dulik [2]<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 > [3]ath5k-de...@lists.ath5k.org > [4]https://lists.ath5k.org/mailman/listinfo/ath5k-devel > > > ___ Information from ESET Mail Security, ver. 4432 (20090917) ___ > The message was checked by ESET Mail Security. [5]www.eset.com > > References > > Visible links > 1. http://www.orbit-lab.org/wiki/SandboxMap > 2. mailto:du...@fai.utb.cz > 3. mailto:ath5k-devel@lists.ath5k.org > 4. https://lists.ath5k.org/mailman/listinfo/ath5k-devel > 5. http://www.eset.com/ > _______________________________________________ > ath5k-devel mailing list > ath5k-devel@lists.ath5k.org > https://lists.ath5k.org/mailman/listinfo/ath5k-devel -- Eric W. Anderson University of Colorado eric.ander...@colorado.edu Dept. of Computer Science phone: +1-720-984-8864 Systems Research Lab - ECCR 1B54 PGP key fingerprints: personal: 1BD4 CFCE 8B59 8D6E EA3E EBD5 4DC9 3E61 656C 462B academic: D3C5 D6FF EDED 9F1F C36D 53A3 74B7 53A6 3C74 5F12
signature.asc
Description: Digital signature
_______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
