Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?
From: Mathias Kresin <hidden>
Date: 2018-03-23 07:54:05
07.03.2018 13:29, Stanislaw Gruszka:
I forgot to attach the patches, do it now. On Wed, Mar 07, 2018 at 01:27:01PM +0100, Stanislaw Gruszka wrote:quoted
On Thu, Mar 01, 2018 at 04:30:10PM +0100, Daniel Golle wrote:quoted
[forwarding to all other involved players] On Thu, Mar 01, 2018 at 05:50:51PM +0300, Jamie Stuart wrote:quoted
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 pathquoted
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 ?quoted
quoted
[ 7794.230376] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x010c, type=4This 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.
Hey Stansilaw,
sorry for the delayed testing. I had to create a new test setup first,
fought with buggy hardware and was busy with other stuff.
The two attached patches are causing a performance regression for me again:
OpenWrt head (forced HT40, 100Mbit wired interface)
wireless (iperf client) to wired (iperf server)
Interval Transfer Bitrate Retr
0.00-60.00 sec 584 MBytes 81.6 Mbits/sec 666 sender
0.00-60.00 sec 584 MBytes 81.6 Mbits/sec receiver
wired (iperf client) to wireless (iperf server)
Interval Transfer Bitrate Retr
0.00-60.00 sec 620 MBytes 86.7 Mbits/sec 33 sender
0.00-60.00 sec 617 MBytes 86.2 Mbits/sec receiver
OpenWrt head (forced HT40, 100Mbit wired interface)
+ rt2800_change_rx_ampdu_factor.patch
+ rt2800_change_ba_size.patch
wireless (iperf client) to wired (iperf server)
Interval Transfer Bitrate Retr
0.00-60.00 sec 356 MBytes 49.8 Mbits/sec 6 sender
0.00-60.00 sec 356 MBytes 49.7 Mbits/sec receiver
wired (iperf client) to wireless (iperf server)
Interval Transfer Bitrate Retr
0.00-60.00 sec 627 MBytes 87.7 Mbits/sec 5 sender
0.00-60.00 sec 626 MBytes 87.5 Mbits/sec receiver
Due to the regression I haven't tested your ampdu_density patch so far.
Let me hear if you want to see more tests done.
Mathias