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
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
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
This should be fixed in latest bionic kernel, LP: #1788997.
--
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 an
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
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
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,
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.19 kernel[0].
If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.
If the mainline kernel does not fix t
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
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
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
> 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
> 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
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
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
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
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
17 matches
Mail list logo
