Date: Wed, 29 Feb 2012 09:48:53 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Johann Hugo <jhugo@meraka.csir.co.za> Cc: freebsd-wireless@freebsd.org Subject: Re: performance in adhoc mode Message-ID: <CAJ-VmonR9P_d%2Bm=Mmf41vH%2BGr5BNrovo8t0hC5c9pspprPaadA@mail.gmail.com> In-Reply-To: <201202291151.10365.jhugo@meraka.csir.co.za> References: <201202281639.05140.jhugo@meraka.csir.co.za> <CAJ-Vmo=5-jwHGa7wRVFU6dgdGdG6Fu3K12WC82Y-yHfP1=3iDA@mail.gmail.com> <201202291151.10365.jhugo@meraka.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, long_retry means that the hardware had to try more times to get the frame out. Either it's picking too high a rate, or the ACKs can't be heard. I wonder what changes in the MAC and driver when we flip on adhoc mode. I know it changes how the beacon queue is handled, I didn't think anything else changed.. Can you try forcing a lower rate on both ends (ifconfig wlanX ucastrate Y) and do your tests? Please file a PR with this. :) Thanks! Adrian On 29 February 2012 01:51, Johann Hugo <jhugo@meraka.csir.co.za> wrote: > On Tuesday 28 February 2012 17:50:39 Adrian Chadd wrote: > >> I've not looked into adhoc _at all_. > > > > please_do > > > >> > >> I'd start by looking at the behaviour of the rate control code - do > >> 'sysctl dev.ath.X sample_stats=1' after you've done some traffic and > >> check dmesg. > >> > >> Just ensure that the same rates are being used and the error rate is low. > >> > > > > The rates differ a bit and also some of the dev.ath.0 sysctl's. > dev.ath.0.stats.ast_tx_longretry is more than double in adhoc mode. > > > > Johann > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonR9P_d%2Bm=Mmf41vH%2BGr5BNrovo8t0hC5c9pspprPaadA>