so, the methodology is, reboot, wait for things to settle (i.e. for the
initial "performance" cpu period ubuntu uses to pass), run a simple
script that dumps out some diags and rsyncs that 400MB iso.
--
Linux brix 4.19.0-041900rc6-generic #201809301631 SMP Sun Sep 30 16:32:51 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Current Frequency:2.452 GHz (Channel 9)
Link Quality=62/70 Signal level=-48 dBm
Wed 03-Oct-18 01:35
429,840,384 100% 6.80MB/s 0:01:00 (xfr#1, to-chk=0/1)
sent 429,945,420 bytes received 35 bytes 7,106,536.45 bytes/sec
---
Linux brix 4.15.0-34-generic #37~16.04.1-Ubuntu SMP Tue Aug 28 10:44:06 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Current Frequency:2.452 GHz (Channel 9)
Link Quality=62/70 Signal level=-48 dBm
Wed 03-Oct-18 01:40
429,840,384 100% 6.38MB/s 0:01:04 (xfr#1, to-chk=0/1)
sent 429,945,420 bytes received 35 bytes 6,665,821.01 bytes/sec
---
Linux brix 4.15.0-32-generic #35~16.04.1-Ubuntu SMP Fri Aug 10 21:54:34 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Current Frequency:2.452 GHz (Channel 9)
Link Quality=70/70 Signal level=-32 dBm
Wed 03-Oct-18 01:43
429,840,384 100% 8.14MB/s 0:00:50 (xfr#1, to-chk=0/1)
sent 429,945,420 bytes received 35 bytes 8,348,455.44 bytes/sec
--
that was the best run 4.19 had, at -18%, out of about a dozen. as with
4.15.0-33 and later most were down by 25-30%. so, "still exists" it is.
here's where things get weird though...
---
Linux brix 4.19.0-041900rc6-generic #201809301631 SMP Sun Sep 30 16:32:51 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Current Frequency:2.447 GHz (Channel 8)
Link Quality=66/70 Signal level=-44 dBm
Wed 03-Oct-18 01:12
429,840,384 100% 8.07MB/s 0:00:50 (xfr#1, to-chk=0/1)
sent 429,945,420 bytes received 35 bytes 8,348,455.44 bytes/sec
---
on channel 8(+4), 4.19 typically performed on par with -32 and older.
on channel 9(+5) though it consistently showed the same regression as -33.
again, this is over about a dozen runs (and multiple reboots switching between
kernels), not a onetime event.
-32 though consistently performed at 70+Mb/s averages regardless of channel.
i'm way out of my depth at this point, but that seemed a remarkable
weirdness and worth pointing out. :)
** Tags added: kernel-bug-exists-upstream
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
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/1795116
Title:
large performance regression (~20-40%) in wifi with 4.15.0-33 and
later
Status in linux package in Ubuntu:
Confirmed
Bug description:
16.04 install using the HWE stack. after several weeks of uptime on
-32, an update to -34 showed a major drop in wifi throughput,
dependent solely on the kernel chosen:
$ uname -a && ./wifibench.sh
Linux brix 4.15.0-32-generic #35~16.04.1-Ubuntu SMP Fri Aug 10 21:54:34 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Tue 25-Sep-18 06:07
PlatformSDK-SVR2003R2.iso
429,840,384 100% 8.41MB/s 0:00:48 (xfr#1, to-chk=0/1)
sent 429,945,420 bytes received 35 bytes 8,685,766.77 bytes/sec
$ uname -a && ./wifibench.sh
Linux brix 4.15.0-34-generic #37~16.04.1-Ubuntu SMP Tue Aug 28 10:44:06 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Tue 25-Sep-18 06:14
PlatformSDK-SVR2003R2.iso
429,840,384 100% 4.83MB/s 0:01:24 (xfr#1, to-chk=0/1)
sent 429,945,420 bytes received 35 bytes 5,028,601.81 bytes/sec
(the script is a simple rsync from a NAS. nothing in the NAS, or the
router, or the physical positions of the devices or etc etc has
changed, let alone in those 7 minutes).
there is no interference, no other devices connected, etc.
prior to the transfer, the link quality is 62-64 and the signal similarly
weaker because of power saving, but once packets are in flight it looks perfect:
$ iwconfig
wlan0 IEEE 802.11 ESSID:"****"
Mode:Managed Frequency:2.452 GHz Access Point: ****
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=70/70 Signal level=10 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:15 Missed beacon:0
the client is a J1900-based (baytrail) machine with a RTL8723BE wifi module.
average performance while on -32 was consistently 70-80 Mb/s, over a period of
several weeks. with -33 and later, it's generally 50-65.
(that machine has no access to launchpad. i'll try apport-cli over the
weekend).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+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
