Any specific params you want for iperf BTW? I ran some basic tests against a VM after all: it might have lost a few %, but wireless is so slow that it's not going to make any meaningful difference.
[ ID] Interval Transfer Bandwidth Reads Dist(bin=16.0K) [ 4] 0.0000-11.4354 sec 45.8 MBytes 33.6 Mbits/sec 22348 22341:6:0:1:0:0:0:0 [ 4] local 192.168.1.34 port 5001 connected with 192.168.1.33 port 45314 [ 4] 0.0000-10.3068 sec 68.6 MBytes 55.9 Mbits/sec 35906 35901:2:3:0:0:0:0:0 [ 4] local 192.168.1.34 port 5001 connected with 192.168.1.33 port 45316 [ 4] 0.0000-10.3491 sec 71.6 MBytes 58.1 Mbits/sec 35522 35512:2:4:4:0:0:0:0 [ 4] local 192.168.1.34 port 5001 connected with 192.168.1.33 port 45324 [ 4] 0.0000-10.3927 sec 75.1 MBytes 60.6 Mbits/sec 35410 35397:7:3:2:1:0:0:0 [ 4] local 192.168.1.34 port 5001 connected with 192.168.1.33 port 45326 [ 4] 0.0000-10.3910 sec 59.8 MBytes 48.2 Mbits/sec 30683 30675:3:4:1:0:0:0:0 The first run may well have had the wifi at low power: the client had just been woken up a couple of minutes earlier, but it tends to dial that back quite quickly. I left it in for completeness. An rsync right after the last run was 6,906,424.15 bytes/sec, so ~58.65 Mb/s. I think that's a good indicator of being able to trust the historical data from it. I may have the machine in here at some point in the next few days, and will test that too if so. For 1795116, the performance in that scenario (~6' and LOS) was fine: it wasn't that the driver was broken across the board, it just wasn't managing power properly so it fell apart if conditions weren't perfect. (Not saying this is the same bug, just reminding myself what a result like that means). I still need to boot into 16.04 / etc to try and find a working kernel. AFAICT 16.04.6 shipped with one that has the post-1795116 fix in it, so it should be okay off a USB. If not though I'll have to get creative, as there isn't a spare partition on that machine to install to. My notes show 4.15.0-55 as the first version with the old bug fixed. It would be helpful if there was a reasonable way for me to just install that, since there are multiple dist-upgrade's worth of other changes since then. While that specific kernel would be ideal from a testing standpoint, isn't there somewhere I can just grab the current Bionic kernel from, as a dpkg, and just install the damn thing without having to jump through any hoops? Surely there must be a better system in place already than randomly guessing at versions or doing builds on a system that is totally unsuitable for such tasks. :( -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel Status in linux package in Ubuntu: Confirmed Bug description: Probably relevant: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116 Card is an RTL8723BE. On 16.04 with the HWE stack, after 1795116 was fixed performance was a stable 75-80Mb/s. Linux 4.15.0-55-generic #60~16.04.2-Ubuntu SMP Thu Jul 4 09:03:09 UTC 2019 x86_64 Fri 26-Jul-19 12:28 sent 459,277,171 bytes received 35 bytes 9,278,327.39 bytes/sec Linux 4.15.0-55-generic #60~16.04.2-Ubuntu SMP Thu Jul 4 09:03:09 UTC 2019 x86_64 Sat 27-Jul-19 01:23 sent 459,277,171 bytes received 35 bytes 10,320,836.09 bytes/sec On 18.04, performance was still a stable 75-80Mb/s. After updating to 19.10, performance is typically ~50Mb/s, or about a 37% regression. $ iwconfig wlan0 wlan0 IEEE 802.11 ESSID:"**" Mode:Managed Frequency:2.442 GHz Access Point: 4C:60:DE:FB:A8:AB Bit Rate=150 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:on Link Quality=59/70 Signal level=-51 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:315 Missed beacon:0 $ ./wifibench.sh Linux 5.3.0-13-generic #14-Ubuntu SMP Tue Sep 24 02:46:08 UTC 2019 x86_64 Sat 12-Oct-19 20:30 sent 459,277,171 bytes received 35 bytes 5,566,996.44 bytes/sec $ iwconfig wlan0 wlan0 IEEE 802.11 ESSID:"**" Mode:Managed Frequency:2.442 GHz Access Point: 4C:60:DE:FB:A8:AB Bit Rate=150 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:on Link Quality=68/70 Signal level=-42 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:315 Missed beacon:0 So no corrupted packets or etc during that transfer. $ ifconfig wlan0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.33 netmask 255.255.255.0 broadcast 192.168.1.255 ether dc:85:de:e4:17:a3 txqueuelen 1000 (Ethernet) RX packets 56608204 bytes 79066485957 (79.0 GB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 21634510 bytes 8726094217 (8.7 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 No issues of any kind in the week that it's been up. Just terrible performance. I'm painfully aware of all the module's parameters etc, and have tried them all, with no change in the results outside of typical wifi variance. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
