Date: Mon, 25 Aug 2014 07:16:45 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 192950] [iwn] Centrino Advanced-N 6205 slow on 11n, better on 11g Message-ID: <bug-192950-21060-iWbm3sskvS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-192950-21060@https.bugs.freebsd.org/bugzilla/> References: <bug-192950-21060@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192950 --- Comment #15 from Adrian Chadd <adrian@freebsd.org> --- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-192950-21060-iWbm3sskvS>