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.
