CPU overload for minisatip using DVB-C, workaround by adding CPU load !

[Set3]

Hi guys, I Love Armbian mainline as docker host, no problems yet apart from below one.

 

I am Running
Orange Pi Zero (first generation), latest Ubuntu mainline, upgraded, latest docker + latest minisatip image
1 USB DVB-C TV stick T230 + latest V4L firmware

 

CPU shoots to 100-ish % for all 4 cores when I try to tune, no picture.

Then I found this out by accident : while upgrading the kernel and tuning at the same time : It helps to have more CPU load, so :
I made a bash script to load one core 100%, avoiding I/O (htop confirms 100%)

And now tuning works : 2 FTA HD channels ( 30Mbps ) looks pretty good.
Temp is no problem, CPU only 50C after 30 mins in open air and with a very small heat-sink.

( So that is with tuning 2 channels AND running the 100% CPU bash at the same time)

Also tried and I see the same overload problems in below, and some combinations of that :
minisatip without docker
Orange Pi One vs Zero ( If needed I could try also on OPiP-2E, but that is a lot of work as those are built in in my 2 NAS boxes as docker hosts and all USB ports used )
SATPI vs minisatip vs TvHeadEnd
Debian vs Ubuntu

USB DVB-S2 vs USB DVB-C

running CPU load bash with "nice -n 10"

 

Both minisatip and its docker image ( image same as above ) works fine on a Raspberry Pi 2

 

So could it be the mainline kernel in combination with USB DVB ?

I know no support, so no big problems if we cant solve this, still want to signal this, perhaps we can make the mainline kernel better ?
 
Only message I found, only very little bit in this direction : CPU 100% when using 2 uarts, something with interrupt overload  ?
https://github.com/armbian/build/pull/847
 

[chrisf]

What cpufreq governor do you have?

does it help if you set the CPU affinity of the minisatip processes manually?

[Set3]

Ah, I think I understand where you are going, good thinking.

I guess you think about power saving and cpu scale down. Ok

 

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

says : ondemand

That is the default

 

Google-d a bit and found more on governor.

So I tried : echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Should I try other than performance also ?

 

Tested and : Wow, really ?

It is like an on/off switch for this problem.

Great man, thanks.

 

So what is the explanation for the problem you just solved :-) ?

I have a read up here https://linux-sunxi.org/Cpufreq

 

 

Looks like you were spot on, great man !

 

I will have a look at CPU temp and report back

 

Edit : Interesting : CPU temp is now 39C so "performance" is no problem and surely beats having 1 core at 100% and 50C :-)

 

 

Set

 

[chrisf]

I can only assume the load is not enough to keep ondemand at a high enough frequency, so it keeps scaling up and down. Maybe the CPU needs to wait between interrupts and that's causing the scaling. Maybe the process that's doing the work is low priority.

While the frequency changes, the CPU can do no work. You lose tens of microseconds each time it happens.

You might be able to keep using ondemand if you tweak its settings, but if performance fixes your problems and works well, probably no need to change it.

[Set3]

O, thanks for the best guess explanation :-)  Chrisf.

 

Running for 24 hours under load now, no problem seen anymore. Definitively fixed.

 

Yes I could play around a bit more with frequencies/governors, I understand that now from your text indeed.

But that wont make a huge difference, as the CPU remains already pretty cool ( < 40C) so that means that it is low power already.

 

For now, I am not changing anything.

Don't fix it if it ain't broke.

 

Next problem is to fix minisatip DVB card standby problem, but that is for another support site.

That will save a lot more power anyway.

 

( I dont see a solved button, so in text ) Solved !

And I found the Like button.