On 2018-10-05 09:44, Stanislaw Gruszka wrote: > (adding back removed CCs) > > On Fri, Oct 05, 2018 at 01:51:42AM +0200, Tomislav Požega wrote: >> Hi > > Hi. > >> As suspected this changeset causes throughput regression. > > You seems to have prejudice against my work :-) > >> Below screenshots show iperf test from MS150N (RF5370) device connected to RT3070 adapter running AP mode: >> >> This is with standard openwrt build without any rt2x00 changes: >> >> [url=https://postimg.cc/BtYQLf6r][img]https://i.postimg.cc/BtYQLf6r/shot-2018-10-04_17-23-56.jpg[/img][/url] >> >> And this printscreen show iperf test with your changes: >> >> [url=https://postimg.cc/D8Sf1p48][img]https://i.postimg.cc/D8Sf1p48/shot-2018-10-04_17-42-09.jpg[/img][/url] > > My experience is that performance between two rt2800 devices vary with > no apparent reason. There are two problems I know that maigh affect > performance at random (and I think there are also some other low level > problems that I'm not aware of that cause performance fluctuations). > > First problem is that HW aggregate RATE_PROBE frames with other frames > at different rate, so we can not do rate probing properly for rate > control algorithm. I believe this is fixable. On MT76x2, I was able to use the QSEL field in the DMA descriptor to force the hw to send it out as a single frame. It is normally set to 2, you can set it to 0 for frames with IEEE80211_TX_CTL_RATE_CTRL_PROBE set. Theoretically, the same should also work on RT2800 devices. > Second problem: we send BAR when we fail to send a frame and this might > have positive and negative effect, depend what remote hardware do when it > gets BAR. This seems to be problem when two rt2800 devices are connected > and not a problem if rt2800 is connected with ath or iwl devices. On the receiver side, BAR is typically processed in software. mac80211 handles that, so I don't think there is a lot of room for chipset specific behavior here. - Felix