From owner-freebsd-wireless@FreeBSD.ORG Mon Aug 25 07:16:45 2014 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A487461E for ; Mon, 25 Aug 2014 07:16:45 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B9963877 for ; Mon, 25 Aug 2014 07:16:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s7P7GjJV053829 for ; Mon, 25 Aug 2014 07:16:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 192950] [iwn] Centrino Advanced-N 6205 slow on 11n, better on 11g Date: Mon, 25 Aug 2014 07:16:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 25 Aug 2014 07:16:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192950 --- Comment #15 from Adrian Chadd --- The problem seems to be a lack of correct feedback to the AMRR rate control code. It doesn't get informed of the correct number of transmissions, failures and retries, leading to it believing the correct thing to do is continue bumping up the rate. If you enable IEEE80211_DEBUG in your kernel config, rebuild, then enable debugging via 'wlandebug +rate', you'll likely see the MCS rate continue climbing towards MCS7 or MCS15. This only works in a very clean environment - definitely not with 2GHz. If you compile with IWN_DEBUG, then sysctl dev.iwn.0.debug=0x1, you'll see information about transmissions and transmit completions. You'll likely see the TX PLCP climb to MCS rate 0xf (MCS15) - with the retry and duration counts will be very high. I'm not sure if there's a quick fix. I think I'm going to have to add some 11n awareness to the ratectl API (ie, so we can tell it how many retries, how many successes, how many failures, the transmit duration) and then ensure it really is being called upon completion of each sent frame - aggregate or otherwise. As for the driver - there seems to be multiple places where frame transmisson completes and the rate control code gets called. I'll have to audit these to ensure it's, well, "right". -- You are receiving this mail because: You are the assignee for the bug.