On Saturday 22 September 2012 02:05:23 Derrick Edwards wrote:
> Thanks again for looking into this.
> My main concern was the range of network performance that I was getting
> when the laptop was right in front of the access point. As you can see
> bandwith varied greatly.
I don't know if it
I assume you've tweaked the ack, slot, rtsctstimeout?
The 11n rate control code is a little more jumpy. I've fixed that in
recent checkins. It's not optimal but now it's not as jumpy as before.
Update to -HEAD, then use 'athratestats' on the peer MAC address. It's
quite useful to see what's actua
I'm still using a utility from Sam.
athctrl -d 8000
Setup IFS parameters on interface ath0 for 8000 meter p-2-p link
dev.ath.0.slottime=36
dev.ath.0.acktimeout=75
dev.ath.0.ctstimeout=75
Are these settings still good ?
Are there any way do detect these automatically ?
Johann
On Saturday 22 Sep
Ah. athctrl.sh ?
adrian
On 22 September 2012 02:04, Johann Hugo wrote:
> I'm still using a utility from Sam.
>
>
>
> athctrl -d 8000
>
> Setup IFS parameters on interface ath0 for 8000 meter p-2-p link
>
> dev.ath.0.slottime=36
>
> dev.ath.0.acktimeout=75
>
> dev.ath.0.ctstimeout=75
>
>
>
> A
.. and yes, what I'd really like to do is find someone who wants to
look after "long distance links" with atheros hardware (and has the
kit to do so!) and help me fix up the coverage class code to work in a
more generic fashion, for all chips.
I can tell people what to do if they'd like to hack on
All,
I am in the process of upgrading my NanoBSD-ALIX kit from 802.11g to
802.11n. First step is to move from 9.1-PRERELEASE (100% stable) to
10-CURRENT with current hardware (AR2413). And alas, I am experiencing
stalling wifi on all my clients: after about 30-60 seconds of being
online, the clien
