Forum

Today I finally linked the one problem with a second one.
Last week I realized that a sudo apt-get upgrade was terribly slow, sometimes 10kb/sec or nothing at all. I blamed the server for that and hey, it's free, so don't complain.
However, an add-on uitzendinggemist.nl which downloads Dutch TV from the public media didn't work either. the log file is spammed with buffer issues etc. So I copy/pasted that log in the github of the developer.

Today I figured, what if the download speed is so bad, that the plugin, which streams from the internet, can't load the stream properly? I downloaded speedtest-cli and indeed: download 0.5Mb/sec and upload 90Mb/sec.
I have 2 RPI's and the other one, running raspbian has 70Mb/sec down and 90Mb/sec up.
I switched network cables and plugged the one from my pc in. No difference
I put the SD-card + USB with OS into my previous RPI2, instead of the current RPI3: no difference.
In the system panel I found the download limiter. It was set to none, and I put it to the max value, by clicking on the up button: no difference
(I rebooted the RPI between several trials and even rebooted the router once)
The slow speed goes with the OS, change of hardware (device/network cable) make no difference. What on earth can have triggered this?

EDIT
One more thing to try:
Unfortunately this didn't help.
I guess I will put a 1 month old image back and see if that brings back the expected speed.

Using a month old image solved the issue. No clue what the root cause was, but this was an evening not well spent ;( However, I'm glad that it all runs well again.

I'm glad with the auto-image options, they help to prevent a lot of re-installs after all!

Hmmm, again a strange issue. It would have been very interesting to find out what the reason was, but (un)fortunately the issue has been gone be restoring an older backup.

Quote:I'm glad with the auto-image options, they help to prevent a lot of re-installs after all!

That's right. Most user are too lazy using it though

Yes indeed. I didn't think that I tinkered too much with my setup. However, with the power issues that I had with those 3 USB devices together, I might have introduced file corruption somewhere along the line.

Something new with this rpi3, is that I have seen quite a few alerts with the thermometer on the screen. With open box the cpu is still 65 degrees during idle, while my other setup is below 50. I added a heat sink and that lowered it with 5 degrees, but with a closed cover, I am back to 65 again.
It is one of those red/white raspberry boxes without any ventilation openings. Not the best design. Cpu load with 'top' is during idle around 1.5 percent, not to bad, I'd say!
Maybe I will take my Dremel and create some air flow already from the bottom side.

EDIT: it turns out they for the last 24hr, there is a root process that takes 8 to 10 percent cpu continuously. From the PID number I was able to trace it back to a kworker process name. Kworker seems to stand for kernel worker.

(31st May, 2019 07:53 AM)jakenl Wrote: [ -> ]Yes indeed. I didn't think that I tinkered too much with my setup. However, with the power issues that I had with those 3 USB devices together, I might have introduced file corruption somewhere along the line.

Something new with this rpi3, is that I have seen quite a few alerts with the thermometer on the screen. With open box the cpu is still 65 degrees during idle, while my other setup is below 50. I added a heat sink and that lowered it with 5 degrees, but with a closed cover, I am back to 65 again.
It is one of those red/white raspberry boxes without any ventilation openings. Not the best design. Cpu load with 'top' is during idle around 1.5 percent, not to bad, I'd say!
Maybe I will take my Dremel and create some air flow already from the bottom side.

EDIT: it turns out they for the last 24hr, there is a root process that takes 8 to 10 percent cpu continuously. From the PID number I was able to trace it back to a kworker process name. Kworker seems to stand for kernel worker.

Which kernel version are you running?

Yeah, that's one of the brilliant ideas the kernel guys had, to name process kworker. Very hard (I do not know how) to identify what the kworkers doing ad why they are running.

Btw, Kodi team has copied this, they're calling them JobWorker

I had/have similar problem on my Cubieboard2, starting with kernel 4.14 I've seen 2 kworker's consuming about 60% CPU of one core when system is idle. Was very hard to find the reason for that behavior, only by chance I found a workaround for that issue

(31st May, 2019 07:53 AM)jakenl Wrote: [ -> ]EDIT: it turns out they for the last 24hr, there is a root process that takes 8 to 10 percent cpu continuously. From the PID number I was able to trace it back to a kworker process name. Kworker seems to stand for kernel worker.

Ah, oooh

I think I have solution for your problem, please read this issue

Adding


to /boot/config.txt should solve this issue for you

(31st May, 2019 10:14 PM)Nachteule Wrote: [ -> ]

(31st May, 2019 07:53 AM)jakenl Wrote: [ -> ]EDIT: it turns out they for the last 24hr, there is a root process that takes 8 to 10 percent cpu continuously. From the PID number I was able to trace it back to a kworker process name. Kworker seems to stand for kernel worker.

Ah, oooh

I think I have solution for your problem, please read this issue

Adding

Code:

dtoverlay=sdtweak,poll_once

to /boot/config.txt should solve this issue for you

I read your comments in the shade in a little play area in a nearby town. It made me curious to see if this was the solution for me. So I logged in with my phone, updated and rebooted: bingo, no more 10 percent load waste!
You're a wizard!

He really is a wizard.

Thanks for the flowers

2 years have passed, and I can confirm, you ARE a wizard, I had the same issue, and solved it with your hotfix. Thanks Nachteule!