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

Reply via email to