| Message ID | 1537957497-7790-1-git-send-email-sgruszka@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | rt2800mmio txdone/interrupts/flush rework | expand |
Hi As suspected this changeset causes throughput regression. 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] Atheros card connected to RT3070 iperf test difference was negligible (1Mbps or less) on bodhi system, but it started to throw out reorder messages on my standard ubuntu after your changes: [url=https://postimg.cc/SjJbP2SP][img]https://i.postimg.cc/SjJbP2SP/Screenshot.png[/img][/url] My advice: stop sending low-quality patches and do some testing before submission.
(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. 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. > Atheros card connected to RT3070 iperf test difference was negligible (1Mbps or less) on bodhi system, but > it started to throw out reorder messages on my standard ubuntu after your changes: > > [url=https://postimg.cc/SjJbP2SP][img]https://i.postimg.cc/SjJbP2SP/Screenshot.png[/img][/url] Ok, thats seems not right, I will try to reproduce this. > My advice: stop sending low-quality patches and do some testing before submission. My advice: stop being arrogant if you want to work with others. Patches were tested on USB devices. At first I thought they broke rt2800usb support: https://bugzilla.kernel.org/show_bug.cgi?id=82751#c17 but then when I wanted to debug that, they start to work; https://bugzilla.kernel.org/show_bug.cgi?id=82751#c33 I assumed that previous breakage was caused by some different change not related with those patches. Anyway I would appreciate any additional testing of my rt2x00 patches as well as code review, if anyone would like to do this. Thanks Stanislaw
On Fri, Oct 05, 2018 at 09:44:23AM +0200, Stanislaw Gruszka wrote: > > 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. > > 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. I have such results without patches: [root@dhcp-27-155 ~]# iperf3 -c 192.168.9.1 Connecting to host 192.168.9.1, port 5201 [ 4] local 192.168.9.11 port 60040 connected to 192.168.9.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 1.67 MBytes 14.0 Mbits/sec 0 72.1 KBytes [ 4] 1.00-2.00 sec 1.43 MBytes 12.0 Mbits/sec 0 123 KBytes [ 4] 2.00-3.00 sec 1.93 MBytes 16.2 Mbits/sec 0 194 KBytes [ 4] 3.00-4.00 sec 4.47 MBytes 37.5 Mbits/sec 0 328 KBytes [ 4] 4.00-5.00 sec 3.23 MBytes 27.1 Mbits/sec 0 402 KBytes [ 4] 5.00-6.00 sec 3.73 MBytes 31.3 Mbits/sec 0 464 KBytes [ 4] 6.00-7.00 sec 4.72 MBytes 39.6 Mbits/sec 0 489 KBytes [ 4] 7.00-8.00 sec 4.16 MBytes 34.9 Mbits/sec 0 516 KBytes [ 4] 8.00-9.00 sec 3.91 MBytes 32.8 Mbits/sec 0 570 KBytes [ 4] 9.00-10.00 sec 3.85 MBytes 32.3 Mbits/sec 0 570 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 33.1 MBytes 27.8 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 31.8 MBytes 26.7 Mbits/sec receiver iperf Done. [root@dhcp-27-155 ~]# iperf3 -c 192.168.9.1 Connecting to host 192.168.9.1, port 5201 [ 4] local 192.168.9.11 port 60044 connected to 192.168.9.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 1.63 MBytes 13.7 Mbits/sec 0 69.3 KBytes [ 4] 1.00-2.00 sec 1.49 MBytes 12.5 Mbits/sec 0 129 KBytes [ 4] 2.00-3.00 sec 2.11 MBytes 17.7 Mbits/sec 0 208 KBytes [ 4] 3.00-4.00 sec 4.41 MBytes 37.0 Mbits/sec 0 361 KBytes [ 4] 4.00-5.00 sec 3.85 MBytes 32.3 Mbits/sec 0 478 KBytes [ 4] 5.00-6.00 sec 4.41 MBytes 37.0 Mbits/sec 0 478 KBytes [ 4] 6.00-7.00 sec 3.17 MBytes 26.6 Mbits/sec 0 502 KBytes [ 4] 7.00-8.00 sec 3.73 MBytes 31.3 Mbits/sec 0 527 KBytes [ 4] 8.00-9.00 sec 3.04 MBytes 25.5 Mbits/sec 0 551 KBytes [ 4] 9.00-10.00 sec 4.10 MBytes 34.4 Mbits/sec 0 551 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 32.0 MBytes 26.8 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 31.0 MBytes 26.0 Mbits/sec receiver iperf Done. [root@dhcp-27-155 ~]# iperf3 -c 192.168.9.1 Connecting to host 192.168.9.1, port 5201 [ 4] local 192.168.9.11 port 60048 connected to 192.168.9.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 1.44 MBytes 12.0 Mbits/sec 0 60.8 KBytes [ 4] 1.00-2.00 sec 1.43 MBytes 12.0 Mbits/sec 0 113 KBytes [ 4] 2.00-3.00 sec 2.61 MBytes 21.9 Mbits/sec 0 212 KBytes [ 4] 3.00-4.00 sec 3.91 MBytes 32.8 Mbits/sec 0 349 KBytes [ 4] 4.00-5.00 sec 4.04 MBytes 33.9 Mbits/sec 0 436 KBytes [ 4] 5.00-6.00 sec 3.73 MBytes 31.3 Mbits/sec 0 494 KBytes [ 4] 6.00-7.00 sec 3.73 MBytes 31.3 Mbits/sec 0 519 KBytes [ 4] 7.00-8.00 sec 3.85 MBytes 32.3 Mbits/sec 0 560 KBytes [ 4] 8.00-9.00 sec 4.16 MBytes 34.9 Mbits/sec 0 594 KBytes [ 4] 9.00-10.00 sec 4.04 MBytes 33.9 Mbits/sec 0 600 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 32.9 MBytes 27.6 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 31.7 MBytes 26.6 Mbits/sec receiver iperf Done. And with patches: [stasiu@dhcp-27-155 ~]$ iperf3 -c 192.168.9.1 Connecting to host 192.168.9.1, port 5201 [ 4] local 192.168.9.11 port 59810 connected to 192.168.9.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 1.58 MBytes 13.3 Mbits/sec 0 72.1 KBytes [ 4] 1.00-2.00 sec 1.68 MBytes 14.1 Mbits/sec 0 130 KBytes [ 4] 2.00-3.00 sec 3.67 MBytes 30.8 Mbits/sec 0 279 KBytes [ 4] 3.00-4.00 sec 6.21 MBytes 52.1 Mbits/sec 0 423 KBytes [ 4] 4.00-5.00 sec 6.28 MBytes 52.6 Mbits/sec 0 495 KBytes [ 4] 5.00-6.00 sec 6.28 MBytes 52.6 Mbits/sec 0 547 KBytes [ 4] 6.00-7.00 sec 6.34 MBytes 53.2 Mbits/sec 0 547 KBytes [ 4] 7.00-8.00 sec 6.34 MBytes 53.2 Mbits/sec 0 573 KBytes [ 4] 8.00-9.00 sec 5.97 MBytes 50.0 Mbits/sec 0 604 KBytes [ 4] 9.00-10.00 sec 5.90 MBytes 49.5 Mbits/sec 0 604 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 50.2 MBytes 42.1 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 49.1 MBytes 41.2 Mbits/sec receiver iperf Done. [stasiu@dhcp-27-155 ~]$ iperf3 -c 192.168.9.1 Connecting to host 192.168.9.1, port 5201 [ 4] local 192.168.9.11 port 59814 connected to 192.168.9.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 3.73 MBytes 31.3 Mbits/sec 0 192 KBytes [ 4] 1.00-2.00 sec 6.34 MBytes 53.2 Mbits/sec 0 379 KBytes [ 4] 2.00-3.00 sec 7.02 MBytes 58.9 Mbits/sec 0 458 KBytes [ 4] 3.00-4.00 sec 5.97 MBytes 50.0 Mbits/sec 0 501 KBytes [ 4] 4.00-5.00 sec 5.90 MBytes 49.5 Mbits/sec 0 523 KBytes [ 4] 5.00-6.00 sec 6.09 MBytes 51.1 Mbits/sec 0 550 KBytes [ 4] 6.00-7.00 sec 6.28 MBytes 52.6 Mbits/sec 0 588 KBytes [ 4] 7.00-8.00 sec 5.90 MBytes 49.5 Mbits/sec 0 588 KBytes [ 4] 8.00-9.00 sec 6.28 MBytes 52.7 Mbits/sec 0 588 KBytes [ 4] 9.00-10.00 sec 6.46 MBytes 54.2 Mbits/sec 0 617 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 60.0 MBytes 50.3 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 58.6 MBytes 49.2 Mbits/sec receiver iperf Done. [stasiu@dhcp-27-155 ~]$ iperf3 -c 192.168.9.1 Connecting to host 192.168.9.1, port 5201 [ 4] local 192.168.9.11 port 59818 connected to 192.168.9.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 2.29 MBytes 19.2 Mbits/sec 0 107 KBytes [ 4] 1.00-2.00 sec 3.11 MBytes 26.1 Mbits/sec 0 238 KBytes [ 4] 2.00-3.00 sec 6.71 MBytes 56.3 Mbits/sec 0 447 KBytes [ 4] 3.00-4.00 sec 6.59 MBytes 55.3 Mbits/sec 0 484 KBytes [ 4] 4.00-5.00 sec 6.28 MBytes 52.6 Mbits/sec 0 533 KBytes [ 4] 5.00-6.00 sec 6.46 MBytes 54.2 Mbits/sec 0 559 KBytes [ 4] 6.00-7.00 sec 4.72 MBytes 39.6 Mbits/sec 0 559 KBytes [ 4] 7.00-8.00 sec 3.98 MBytes 33.4 Mbits/sec 0 587 KBytes [ 4] 8.00-9.00 sec 3.36 MBytes 28.1 Mbits/sec 0 587 KBytes [ 4] 9.00-10.00 sec 4.04 MBytes 33.9 Mbits/sec 0 587 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 47.5 MBytes 39.9 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 46.1 MBytes 38.7 Mbits/sec receiver iperf Done. when connecting two rt2800usb devices one in AP mode second in STA mode. Results with patches are somewhat better, but this is by accident. Basically performance randomly vary on those testing. Only 'flush' was chagned for USB, otherwise the code was just moved to rt2800lib. So probability of regression there is low. Much more changes were done for MMIO by those patches, so I would be more worry about that. But this was tested by me and various other users. Thanks Stanislaw
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
On Fri, Oct 05, 2018 at 12:05:56PM +0200, Felix Fietkau wrote: > On 2018-10-05 09:44, Stanislaw Gruszka wrote: > > 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. I created a patch that do this https://github.com/sgruszka/wireless-drivers-next/commit/846d205edd8c36d1b7828fee54bf4cf40bf8cb1a but coused problems on some devices and I did not observed correct behaviour - probe frames were still aggregated. Perhaps patch has some bug (i.e. some registers have to be initialized to make QSEL work) or maybe this will only work on some chipsets i.e. MT7620 and QSEL should be used only conditionally on those chips. > > 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. This is not what I observed. For me looks like BA is send by FW/HW for both AMPDU frames and for BAR. And behaviour differs. I have one older device that send completely bogus SSN (seq num) in solicit BA frame not correpond to BAR SSN or frames in AMPDU at all. Some devices send solicit BA SSN and then send BA with older SSNs, for frames which should already be flushed. And some devices send several BA with solicit SSN until catch up to ack frame that has bigger sequence number than solicit SSN. Regards Stanislaw
On 05/11/2018, Craig Matsuura <cmatsuura@vivint.com> wrote: > Tom, > > > I see my name and email in some urls but could not see what you are > referring too? > > > Craig > > > Craig Matsuura • Technical Director, Embedded Software Architecture > > cmatsuura@vivint.com<mailto:cmatsuura@vivint.com> • P: 801.229.6005 > > > > simply smarter • vivint.com > > 3401 N Ashton Blvd. Lehi, UT 84043 > > > > [1497369905956_vivint-logo-orange.png] > > ________________________________ > From: linux-wireless-owner@vger.kernel.org > <linux-wireless-owner@vger.kernel.org> on behalf of Tomislav Požega > <pozega.tomislav@gmail.com> > Sent: Thursday, October 4, 2018 5:51:42 PM > To: sgruszka@redhat.com > Cc: linux-wireless@vger.kernel.org > Subject: Re: [PATCH 0/5] rt2800mmio txdone/interrupts/flush rework > > Hi > > As suspected this changeset causes throughput regression. > > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.postimg.cc%2FBtYQLf6r%2Fshot-2018-10-04_17-23-56.jpg%5B%2Fimg%5D%5B%2Furl&data=01%7C01%7Ccmatsuura%40vivint.com%7C4b957a380bc24ebda1f708d62a546496%7C54cc98ca024a470185483741e3b8d59d%7C0&sdata=Fsq5PtjbTx3vuXrNyicoVMVyk59dlXin0SecZTKCcOY%3D&reserved=0] > > And this printscreen show iperf test with your changes: > > [url=https://postimg.cc/D8Sf1p48][img]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.postimg.cc%2FD8Sf1p48%2Fshot-2018-10-04_17-42-09.jpg%5B%2Fimg%5D%5B%2Furl&data=01%7C01%7Ccmatsuura%40vivint.com%7C4b957a380bc24ebda1f708d62a546496%7C54cc98ca024a470185483741e3b8d59d%7C0&sdata=w9eslvFB%2F13VBHGG7n48C2KH4ceyk1Acb5G3wEoPdEc%3D&reserved=0] > > Atheros card connected to RT3070 iperf test difference was negligible (1Mbps > or less) on bodhi system, but > it started to throw out reorder messages on my standard ubuntu after your > changes: > > [url=https://postimg.cc/SjJbP2SP][img]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.postimg.cc%2FSjJbP2SP%2FScreenshot.png%5B%2Fimg%5D%5B%2Furl&data=01%7C01%7Ccmatsuura%40vivint.com%7C4b957a380bc24ebda1f708d62a546496%7C54cc98ca024a470185483741e3b8d59d%7C0&sdata=7AfQGKReywwEYrVZzYOxpLqbmg8kBdCbNE6Mj0%2BmGRM%3D&reserved=0] > > My advice: stop sending low-quality patches and do some testing before > submission. > Hi No idea where did you got that message from, some safelink protection seem to be added somewhere in the mailing process. You can check my original mail here: https://www.mail-archive.com/linux-wireless@vger.kernel.org/msg49652.html . If interested in links you should open them manually as the URL formating seems inappropriate.