Hi Stanis, Our environment has the following wireless config (MT7620A): config wifi-device 'radio0' option type 'mac80211' option channel 'auto' option hwmode '11g' option path 'platform/10180000.wmac' option txpower '20' option country 'GB' option htmode 'HT40' option noscan '1' config wifi-iface 'default_radio0' option device 'radio0' option network 'lan' option mode 'ap' option encryption 'psk2+aes' option key ‘KEY' option maxassoc '96' option ssid ’SSID' option disassoc_low_ack ‘0' The 30 clients are all Apple iPads (a mixture of iPad mini and mini 2, running iOS 9-11). During this testing period, all clients were simultaneously downloading files from the devices’ sdcard (served via nginx running on the device). Although this is not a typical use-case, it was useful in stress-testing the wireless setup. We’ll try your patches Stanis. Daniel - forgive the stupid question, but how do we apply Stanis’ patches atop your staging tree (or both yours and Stanis’ atop trunk?) > On 7 Mar 2018, at 14:27, Stanislaw Gruszka <sgruszka@xxxxxxxxxx> wrote: > > On Thu, Mar 01, 2018 at 04:30:10PM +0100, Daniel Golle wrote: >> [forwarding to all other involved players] >> >> On Thu, Mar 01, 2018 at 05:50:51PM +0300, Jamie Stuart wrote: >>> Hi Daniel, >>> The driver seems much improved after this fix. >> >> it's about those two >> [PATCH 1/2] rt2x00: pause almost full queue early >> [PATCH 2/2] rt2x00: do not pause queue unconditionally on error path >> >>> Under very heavy load (30 clients downloading multi-GB files from SD card on the server concurrently), wifi dies with errors: > > This is some testbed? Could you share how did you setup such > environment and what are client devices ? > >>> [ 7794.230376] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x010c, type=4 > > This is indicator that HW/FW has a problem. There could be various > reasons for that. One possible I can also observe in my setup,is strange > mishmash of seq on frames which were not acked in BlockACK and > had to be resent. This can happen when many frames are wrongly decoded > (i.e. when there is bad radio condition or we have not correct low level > RF/BBP setup for a Ralink device). To mitigate that problem we can > limit length of agreggeted AMPDU frame. > > I attached two patches which do that. One for RX side second for TX side. > Please check if they make a diffrent. You can also hardcode ba_size = 0 > for those 30 clients setup. > > Note the patches can cause (possibly small) perfromance degradation on > good setups. > > Mathias, could you check them as well and see if they do not cause > performance regression on your device ? Lastly when I changed ba_size > setting, it was a problem on your setup. > >>> Thu Mar 1 16:36:47 2018 kern.err kernel: [ 8702.146403] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2 >>> Thu Mar 1 16:36:47 2018 kern.err kernel: [ 8702.146403] Please file bug report to http://rt2x00.serialmonkey.com >>> Thu Mar 1 16:36:48 2018 kern.err kernel: [ 8702.288149] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2 >>> Thu Mar 1 16:36:48 2018 kern.err kernel: [ 8702.288149] Please file bug report to http://rt2x00.serialmonkey.com >>> Thu Mar 1 16:36:48 2018 kern.err kernel: [ 8702.380761] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2 >>> Thu Mar 1 16:36:48 2018 kern.err kernel: [ 8702.380761] Please file bug report to http://rt2x00.serialmonkey.com > > For those errors I recommend to remove > > 600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch > > patch. Whould be good if OpenWRT developers could apply this patch only > on target where it is really needed, not for all rt2800 devices. > > Thanks > Stanislaw
