Date: Fri, 9 Sep 2011 19:06:03 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Lev Serebryakov <lev@serebryakov.spb.ru> Cc: freebsd-wireless@freebsd.org Subject: Re: AP performance (again): txpower regulation Message-ID: <CAJ-VmokAvtKTUGo5zBS3ry0nRH=P%2B1TNB2n-9dKK%2BSWn6FdJ2A@mail.gmail.com> In-Reply-To: <1853154884.20110909145338@serebryakov.spb.ru> References: <663133681.20110907193747@serebryakov.spb.ru> <CAJ-Vmonai4LzwanLw7i5d-NyjN2b6GqfttjkdcROvOuEcuzEAw@mail.gmail.com> <437702009.20110907235248@serebryakov.spb.ru> <CAJ-Vmo=R-a%2BqhDLWj1n%2BBj70Pmg4WSL6bVZ6jwCUmNq=v7EBBw@mail.gmail.com> <426917282.20110908125907@serebryakov.spb.ru> <CAAUsrB5Qtokpcz-koUfYWCHrsnUUErQSAYHrXrW2F0Uvp3RzSA@mail.gmail.com> <4610390305.20110908154130@serebryakov.spb.ru> <CAAUsrB6LJ%2BmuTvaqHCySh6e9dMjzshohYFE4PQ3KTezZMZS2JA@mail.gmail.com> <1705262661.20110908180850@serebryakov.spb.ru> <CAAUsrB7CFu096x%2BKKWa=8O_VeSHOK10LuwJ2rWq6r8EidUrL=Q@mail.gmail.com> <CAJ-VmokvXfUAZpxDgv5gLrRdLYn3YwTXAOb7QiTyUg8K5yKLHg@mail.gmail.com> <458771414.20110908183656@serebryakov.spb.ru> <CAJ-Vmom_ZHKbqt%2BQgmdq_oPU-SugbrJ3LNS=g-cpcQ7KExusUw@mail.gmail.com> <4910491962.20110908185213@serebryakov.spb.ru> <CAJ-Vmo==J_9ZhnSciVKNaEaMhM4oeM9fr4yjzPev_MW3g9DALg@mail.gmail.com> <1273865639.20110908191303@serebryakov.spb.ru> <1607911768.20110909113824@serebryakov.spb.ru> <CAJ-VmonfU0iJUiC%2BhT32XvH3t9qwKy98o9GdxMZxqebcSPL04Q@mail.gmail.com> <1853154884.20110909145338@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Right, but this is where you now do some more digging. :) (This is how I started hacking on atheros/net80211 stuff about 18 months ago. I was in the same situation you were, only with the Ubiquiti 11n and SR-2 NICs.) I'd suggest looking at the output of athstats whilst you're doing traffic: $ athstats 1 And look at the output of the sample rate control algorithm: # sysctl dev.ath.0.sample_stats=1 (then check dmesg) Let's split it into two halves: TX and RX. For TX errors, you'll see things like ackbad, long/short retries. For RX errors, you'll see lots of CRC errors. You'll also see OFDM/CCK errors if your environment is noisy (and you've got ANI enabled.) Forcing the tx/rx antenna will likely fix the stability of the ACKs seen. As for the throughput, look at the output of TX/RX, look at the per-rate retry and error rates being seen, and start to figure out what's going on. You can use iperf UDP tests in each direction to test out one-way traffic - TCP stresses both directions; UDP stresses data in one and 802.11 ACKs in the other. Finally, I bet yes - running the NIC at half its rated TX power is likely going to make things easier to deal with. It won't be using the full TX power at higher rates anyway- ie, although the NIC is rated at 600mW, that'll be at the lowest TX rates (1MBit), I bet at 54MBit it's only transmitting at 100mW. Since you want to get higher throughput, why run the NIC at a higher TX power than what the 54mbit rate will TX at? :) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokAvtKTUGo5zBS3ry0nRH=P%2B1TNB2n-9dKK%2BSWn6FdJ2A>