From owner-freebsd-wireless@FreeBSD.ORG Sat May 9 20:26:31 2015 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4274842A for ; Sat, 9 May 2015 20:26:31 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A13B1F36 for ; Sat, 9 May 2015 20:26:31 +0000 (UTC) Received: by iecmd7 with SMTP id md7so7552033iec.3 for ; Sat, 09 May 2015 13:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=HO5NXpfEifuY8mqLbi2QV9hiFPAnbx9lnEPheNihF+M=; b=KyQWex+U3/xCn5OVDTBq57CGmYtf2vDopycvqiZQqzZiXFcilMz7Ex2O/n0FTrp02q TLnSf+0aKWa5CRc10Oh4VNvOlU1z6wo8Q+Dcnd4KQGiBxtSOoGZaJCmhGpdxhGawCpRx TpRzZGF5Nx7T9R8bZE18Nhu5ON5cMeoWFA+fRgg3mDgOzK5hhwfOvzGBQARODvJlxVmU RsYlPYOwLMCWGitfnnflyZJ3Je2nlYgEGn1slFb7LYlKOIf7iaEuiz/BUxKHY85PPy+l c+a0Faq/+Uu3WVMRfZDjA3kU+04Xkr/ZFol/lOlKABySpw3eA0r+Qpew2yGGYflPKyIf ZyuQ== MIME-Version: 1.0 X-Received: by 10.43.163.129 with SMTP id mo1mr4048482icc.61.1431203190432; Sat, 09 May 2015 13:26:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Sat, 9 May 2015 13:26:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 May 2015 13:26:30 -0700 X-Google-Sender-Auth: Kk1jwbnC-mWpUP_d1-9NyPlUbcg Message-ID: Subject: Re: Seeking help for Atheros Wi-Fi driver implementation From: Adrian Chadd To: Yi-Hung Wei , "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 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: Sat, 09 May 2015 20:26:31 -0000 Hi! So yes, it's likely noise floor calibration / other initial calibrations and ANI. The initial calibrations do take a while to run. The TSF timer accuracy shouldn't drift 60uS. I have a feeling there's a bug that is leading to the AR9300 running slightly off than it should. I recall reading about it in the commit logs from the QCA drivers I have access to. Erk, here it is. God, I remember finding something similar when doing chip bringup there. What's the contents of registers 0x8244 and 0x824c? Is it drifting in 20MHz /and/ 40MHz mode? I saw a bug that was fixed a long time ago where the derived rtc clock value was off by 56uS, which is suspiciously close to you. -adrian On 9 May 2015 at 13:14, Yi-Hung Wei wrote: > Hi Adrian, > > Thanks for your prompt reply. Now it makes a lot of sense to me. I set > 'clear destination mask' and all the TXFILT errors go away. Thank you so > much. I might never get away this bug without your help. > > BTW, I found that if I restart my AP, the packet loss rate is higher in the > first few seconds. It is because of ANI? > > Also, I found that the accuracy of TSF timers are not consistent among > different chips. I have two AR9300 chips and two AR9280 chips. The TSF > timers seem to be relatively accurate between the same chips. However, for > every beacon internal (100TU), I observe roughly 60 micro-sec time drift > between an AR9300 and an AR9280 chip. Is it possible to manipulate the TSF > clock for better synchronization? > > Thanks and hope you have a great weekend! > > Best, > > -Yi-Hung > > On Fri, May 8, 2015 at 5:57 PM, Adrian Chadd wrote: >> >> Hi, >> >> The MAC does this on TX: >> >> * it has a "tx filt" bit in the keycache entry for each MAC you're >> speaking to; >> * if the TX header bit "clear TX filt" is set, it clears the TX filter >> bit for that MAC address; >> * if the TX filter bit in the keycache entry is set, it fails the TX >> immediately - with reason TXFILT; >> * it tries TX'ing; if it fails it sets the appropriate error, and sets >> the TX filter bit in the keycache. >> >> The idea is that if you fail to transmit a frame, you fail subsequent >> frames to the same destination and let software retransmit them. This >> is important for software retransmission of non-aggregate traffic - >> sequence numbers can't be out of order, so you have to fail all the >> packets so you can retransmit them all in sequence. You can't fail one >> in the middle of a sequence and then complete subsequent frames, then >> you'd be transmitting out of order. >> >> >> >> -adrian > >