On Thu, Jul 21, 2016 at 08:25:11PM +0200, Andreas Bartelt wrote:
> sorry, my response was not precise - the "fatal" error is gone now but the
> observed performance problems are still there.
I've already been told about iwm performance regressions compared to 5.9,
so I'd like to make a statement (not just directed at you, Andreas, but
at everyone).
Recently, I've been focusing on improving wireless stability after many
reports of lag, dropped links, and similar problems ever since 11n support
was introduced. This effort is still on-going, since I am still unable to
reproduce some of the reported issues. If such fixes end up decreasing
performance in some use cases then I'm entirely fine with that.
One possibility is that perceived performance drops are a side effect of
frame protection we've enabled. This may show up as a performance drop for
users which are alone with their AP and never see interference (so frame
protection doesn't buy them anything, it just adds overhead).
Many users are not alone with their AP but share a channel with a dozen
other APs or so and frame protection _really_ helps them. In the most
extreme cases (which I've reproduced with help from phessler@) these
users cannot use wifi at all without frame protection (TCP stalls).
To get an idea about the overhead added by RTS/CTS, see
http://www.testequipmentdepot.com/flukenetworks/pdf/802.11n-compatibility.pdf
(When reading this, keep in mind we send at MCS 7 max, without aggregation.)
In the best iwm performance regression report I've received so far, the
reporter tracked the regression down to a particular commit (r1.86 if_iwm.c).
Backing out that commit restores performance to 5.9 levels for this user.
But this commit fixed an unrelated problem, which was that IPv6 autoconf and
ARP briefly stopped working in -current after we upgraded iwm's firmware.
I don't understand how this relates. It may involve invisible details handled
within the magic firmware, or it may be a driver bug, or prior performance
levels may have been a side effect of a real stability problem. In any case,
I won't back out this commit to restore performance for one user if backing
out that commit means that other known bugs will come back.
More generally speaking, given that our 11n implementation is still in its
infancy, and doesn't yet use any of the new features which are supposed to
vastly increase throughput, it is premature to complain about performance.
For now, stability gets priority.
