From owner-freebsd-wireless@FreeBSD.ORG Wed Feb 29 17:48:55 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12304106566B for ; Wed, 29 Feb 2012 17:48:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 90F3D8FC0A for ; Wed, 29 Feb 2012 17:48:54 +0000 (UTC) Received: by werl4 with SMTP id l4so2800443wer.13 for ; Wed, 29 Feb 2012 09:48:53 -0800 (PST) Received-SPF: pass (google.com: domain of adrian.chadd@gmail.com designates 10.216.134.136 as permitted sender) client-ip=10.216.134.136; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adrian.chadd@gmail.com designates 10.216.134.136 as permitted sender) smtp.mail=adrian.chadd@gmail.com; dkim=pass header.i=adrian.chadd@gmail.com Received: from mr.google.com ([10.216.134.136]) by 10.216.134.136 with SMTP id s8mr776459wei.6.1330537733679 (num_hops = 1); Wed, 29 Feb 2012 09:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dmq+leSebbUuC1hG1LlVFVoOf3EJF1gERuIVSNJ/bwk=; b=hMFQbojNormJYOaVRD6VNp0Hwdt7LyrPlFiC3H0L5Ff9MLt2c6ZEo5k2BIZmPLVAys HsyHuHKbHYuGyFVhtzxpAdnbAYJfZSM+qbLulyzloNCoYsuUi8bbKPq/5h/7gKDFsB1Q BxzJwRiJfKUmu5ok1L6IaK0gOxK2auBaGR64w= MIME-Version: 1.0 Received: by 10.216.134.136 with SMTP id s8mr623709wei.6.1330537733596; Wed, 29 Feb 2012 09:48:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.198.81 with HTTP; Wed, 29 Feb 2012 09:48:53 -0800 (PST) In-Reply-To: <201202291151.10365.jhugo@meraka.csir.co.za> References: <201202281639.05140.jhugo@meraka.csir.co.za> <201202291151.10365.jhugo@meraka.csir.co.za> Date: Wed, 29 Feb 2012 09:48:53 -0800 X-Google-Sender-Auth: y5aaORzxxLdncBhducpg-w-aQU8 Message-ID: From: Adrian Chadd To: Johann Hugo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: performance in adhoc mode X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 17:48:55 -0000 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 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 > >