Sorry Kai - I got swamped by real-life issues.
I finally got the time to look into this a few days ago, and when I went
to check on it then in case a kernel update had fixed things already, it
looks like it has (or at least, mostly so) - peaks are back to 80+, so
that's within wifi variance again.
Thanks Kai.
Yes, I really want to use Ubuntu kernel to bisect: or at least, I need
the option to be able to - because if the problem is coming from the
Ubuntu patchset, I could spend weeks bisecting mainline and never find
it, whereas if I bisect the Ubuntu tree I'm guaranteed to find it and
that
Had the affected machine in here (i.e. "where the router is") for other
reasons, so I was able to check those conditions too. As expected, it's
a power / antenna / etc issue:
Linux 5.3.0-19-generic #20-Ubuntu SMP Fri Oct 18 09:04:39 UTC 2019 x86_64
Fri 08-Nov-19 03:29
sent 459,277,171 bytes recei
Okay - the 18.04.3 release I tested in September, which was fine, has
5.0.0-23.
-29 is broken, as mentioned above. That's a pretty narrow window to work with.
I'd prefer it if someone from Canonical took it from here.
(Heck, there are probably few enough commits to that driver in that timeframe
t
16.04.6 turned out to have 4.15.0-45, which is one of the known-broken
releases. Unsurprisingly, it delivered the same poor results as 5.3.
I'm running low on sensible options here.
I no longer have the bootable 18.04 stick I used before, but I can
create a new one easily enough (as long as I rem
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] IntervalTransferBandwidth Reads Dist(bin=16.0K)
[ 4] 0.-11.4354
I expect so. I don't usually have a machine available to run as a server
though, hence the preference for rsync.
If you're concerned that the NAS might be the bottleneck, don't be.
That's a sensible point to raise, but it's GbE and saturates it wired.
(To say nothing of the months during which the
The dist-upgrades have wiped out all the previous kernels, of course.
The only one left on the machine at all was the 5.0 from 19.04, and that's no
good either. :(
Linux 5.0.0-29-generic #31-Ubuntu SMP Thu Sep 12 13:05:32 UTC 2019 x86_64
Wed 23-Oct-19 04:47
sent 459,277,171 bytes received 35 by
That machine doesn't have access to launchpad, so until someone fixes
the bugs (referenced out in the other thread) so that "ubuntu-bug -c"
works, I can't provide that info.
Kai - this is a low-power HTPC, with very little disk space. Assuming it
can even clone the kernel, it will likely take week
** 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/1847892
Title:
large performance regression (~30-40%) in wifi with 19.
Public bug reported:
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
That bad run was an outlier. No idea what caused it, but cron'd tests
over the past couple of days have all shown results similar to the
pre-33 breakage.
So it looks like this is finally fixed, thanks. It's a shame testing
didn't catch it, but understandable. It's a bit more worrying that the
regr
Hooray, it seems that it has - but possibly only partially.
Peak and Avg throughput were both a few % down compared to -32, but well
within the sort of variance wifi suffers from. High-70s for download is
certainly good enough to use.
What's less encouraging, to the point of being an outright con
Thanks, but that seems unlikely: I'm aware of the ant_sel issue on HP
laptops etc, but this machine isn't one and has never benefitted from
it. If it was using the wrong one of two antennae, it wouldn't hit 70/70
at 20ft away through walls, nor would the throughput be almost half of
what it was wit
Although, I see what appears to be an unrelated (to ant_sel)
+ if (rtlpriv->cfg->ops->get_btc_status())
+ rtlpriv->btcoexist.btc_ops->btc_power_on_setting(rtlpriv);
added in that commit as well. I can't go digging into the source right now to
see what that's doing, but since
Still hopelessly broken. :(
Throughput with the latest kernel was down to about 45Mb/s when I tested it a
few days ago.
--
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:
la
given the link quality observations in #11 and the behavior in #12, it's
pretty clear that the problem is with the radio power management.
since it isn't improved at all via any of the PM settings, that suggests
it's simply broken rather than overly-aggressive.
for reference, the head for the las
the machine is usually ~20 feet away from the router, through multiple
walls and a floor. i moved it last night so it was 6 feet away with LOS,
and the results from that are very interesting:
Linux brix 4.15.0-36-generic #39~16.04.1-Ubuntu SMP Tue Sep 25 08:59:23 UTC
2018 x86_64 x86_64 x86_64 GNU
> prior to the transfer [on the buggy versions] the link quality is
62-64 and the signal similarly weaker because of power saving, but once
packets are in flight it looks perfect
-32 doesn't seem to have that problem: it's been 70/70 every time i've
looked, even with the link speed showing as 15Mb
> on channel 8(+4), 4.19 typically performed on par with -32 and older.
apparently only because of some fluke. the router switched to 4(+8) some
time in the past couple of days, and the newer kernels are certainly
sucking hard on that too:
---
Linux brix 4.15.0-32-generic #35~16.04.1-Ubuntu SMP
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
ok - it's a failure in the doc, since the kernel image can't be
installed without them.
also note that the headers package can't be installed on 16.04 because
of a change in the ?libssl? dependency. (from memory: might be the wrong
dependency).
that aside, the results with 4.19 are ... odd, so fa
sure, i'll try.
sidenote, https://wiki.ubuntu.com/KernelMainlineBuilds is missing any
reference to kernel modules, which seem like they might be kind of
important for bugs like this. is that a failure in the doc, or is the
goal here just to test e.g. the tcp changes in -33 rather than any
changes
marked as confirmed per #3 and #4.
i have the apport file stashed away and can upload it as an attachment
upon request if anyone's interested.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages,
unfortunately, the instructions on
https://help.ubuntu.com/community/ReportingBugs don't seem to work:
>>
If this is to be added to an existing bug report, also use the -u option:
ubuntu-bug -c FILENAME.apport -u BUGNUMBER
<<
$ ubuntu-bug -c /mnt/nas/wifi.apport -u 1795116
Usage: ubuntu-bug [op
obviously i've tested this with 32/33/34 a dozen or so times, but the
performance regression shows up in all of them, so i've only copied that
particular one. the best (i.e. "least bad for the bugged kernel") result
so far was "only" -18%, and most runs are down by 25-30%.
** Package changed: ubun
26 matches
Mail list logo
