Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Version 5 - CPU over 200%, slow interface
#11
Can confirm CPU usage gets wonky once Automatic display is enabled. Wonky in the sense that it starts jumping up and down on my player, sometimes as high as Rob reports. Oddly, the usage continues to be wonky if I then disable it. (This on stock moOde r5.2 with Chromium 72.0.3626.121).

I don't know the mechanics of Chromium. There are six Chromium processes running; it seems mostly only two start consuming CPU heavily.

Installing the rpi-chromium-mods package doesn't seem to help---and it starts a flashplayer process too  Angry

We've got a tiger by the tail here.

Regards,
Kent
Reply
#12
Below are some stats showing some of the peaks. Seem pretty normal to me and there don't appear to be any adverse effects. UI is responsive during playback of 24/192 FLAC tracks and there are no audio glitches. Note that this is with the on-board Pi audio device so there is additional CPU load due to auto-downsampling to 16/48K which is max rate for the on-board device.

I'm still not seeing an issue.

Animated backdrop

Code:
pi@rp5:~ $ moodeutl -m
CPU: 1.2 GHz | LOAD: 54% | TEMP: 62°C | RAM_USED: 34% | DISK_USED: 78% | FPM_POOL: 5 workers 

pi@rp5:~ $ top
ctrl-1

top - 07:52:33 up 13:11,  1 user,  load average: 1.30, 1.33, 1.44
Tasks: 137 total,   3 running,  84 sleeping,   0 stopped,   0 zombie
%Cpu0  : 48.1 us,  2.0 sy,  0.0 ni, 49.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 19.8 us,  2.7 sy,  0.0 ni, 77.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 85.8 us,  3.0 sy,  0.0 ni, 11.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 42.7 us,  4.7 sy,  0.0 ni, 52.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   948304 total,   282404 free,   179720 used,   486180 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   637772 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                              
 2280 pi        20   0  445372 145948  88664 R 196.1 15.4 967:04.38 chromium-browse

And here is with Pure Black for the backdrop while playing 24/192 FLAC

Code:
pi@rp5:~ $ moodeutl -m
CPU: 1.2 GHz | LOAD: 14% | TEMP: 58°C | RAM_USED: 51% | DISK_USED: 78% | FPM_POOL: 5 workers

pi@rp5:~ $ top
ctrl-1

top - 08:38:12 up 13:56,  1 user,  load average: 0.60, 1.14, 1.42
Tasks: 146 total,   1 running,  91 sleeping,   0 stopped,   0 zombie
%Cpu0  : 11.9 us,  1.7 sy,  0.0 ni, 85.4 id,  1.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 11.6 us,  1.7 sy,  0.0 ni, 86.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  6.1 us,  0.3 sy,  0.0 ni, 93.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 10.4 us,  1.6 sy,  0.0 ni, 87.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   948304 total,   171572 free,   180428 used,   596304 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   475884 avail Mem

 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
2280 pi        20   0  637932 298028 249896 S  16.4 31.4   1017:18 chromium-browse

pi@rp5:~ $ chromium-browser --version
Chromium 72.0.3626.121 Built on Raspbian , running on Raspbian 9.9
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#13
The only effect i have, is higher temperature when automatic display start, maybe if it run during hours like that, RPI could cpu throttle to downside his temperature, and causing audio glitchs or ui unresponsiveness.

With V4.4, CPU usage is still very high when automatic display start, but only few seconds, then it go back normal, high, normal, high, normal etc...

With V5.2 it's high every time when automatic display start. No going back to normal, even for a few seconds.

For example my rpi is already at 72° celcius, it's 20° higher than normal, running 30 minutes since automatic display start.
Reply
#14
Here's two screen shots, one of top output the other of htop output, taken at slightly different times. I tried to capture extremes. There are also times when the CPU usage seems almost normal. The wonkiness doesn't start until the first time the automatic display kicks in (1 minute in my test case).

[Image: ti54MXb.png]

[Image: ZF2tem3.png]
Reply
#15
I guess we differ on what's an issue.I don't think Chromium should make us pay such a premium in CPU usage. If this is "normal" perhaps we could at least lower the priority of its processes.
Reply
#16
(05-24-2019, 01:17 PM)TookaFace Wrote: The only effect i have, is higher temperature when automatic display start, maybe if it run during hours like that, RPI could cpu throttle to downside his temperature, and causing audio glitchs or ui unresponsiveness.

With V4.4, CPU usage is still very high when automatic display start, but only few seconds, then it go back normal, high, normal, high, normal etc...

With V5.2 it's high every time when automatic display start. No going back to normal, even for a few seconds.

For example my rpi is already at 72° celcius, it's 20° higher than normal, running 30 minutes since automatic display start.

I suppose it could be thermal throttling if the Pi Touch rig is in an enclosure w/o good air flow. Mine is just in a bamboo stand and so the Pi is in open air. I also set CPU Governor to On-demand in System config.

The way to tell if thermal throttling is happening is to run the cmd below and then analyze the bit mask.

Code:
pi@rp5:~ $ vcgencmd get_throttled
throttled=0x50000

In the example above I'd been playing some 24/192 FLAC tracks for a while.

0x50000 = 1010000000000000000

Bit positions 17 and 19 are set. Using the table below this decodes to:

17 Arm frequency capped has occurred
19 Soft temperature limit has occurred

https://github.com/raspberrypi/documenta...cgencmd.md
Code:
get_throttled

Returns the throttled state of the system. This is a bit pattern.

Bit    Meaning
0    Under-voltage detected
1    Arm frequency capped
2    Currently throttled
3    Soft temperature limit active
16    Under-voltage has occurred
17    Arm frequency capped has occurred
18    Throttling has occurred
19    Soft temperature limit has occurred
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#17
(05-24-2019, 02:21 PM)TheOldPresbyope Wrote: I guess we differ on what's an issue.I don't think Chromium should make us pay such a premium in CPU usage. If this is "normal" perhaps we could at least lower the priority of its processes.

I agree but I think what is being shown is that the CoverView animated backdrop is driving up CPU utilization and temp in the Pi-Touch usage scenario. It's not causing any issues on my rig but maybe if the rig is in an enclosure w/o good air flow, thermal throttling is happening ??
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#18
(05-24-2019, 01:17 PM)TookaFace Wrote: The only effect i have, is higher temperature when automatic display start, maybe if it run during hours like that, RPI could cpu throttle to downside his temperature, and causing audio glitchs or ui unresponsiveness.

With V4.4, CPU usage is still very high when automatic display start, but only few seconds, then it go back normal, high, normal, high, normal etc...

With V5.2 it's high every time when automatic display start. No going back to normal, even for a few seconds.

For example my rpi is already at 72° celcius, it's 20° higher than normal, running 30 minutes since automatic display start.

You are observing this on Pi-Touch based rigs correct?
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#19
No Pi-Touch (i just tried with HDMI), both raspberry are 3B+, with Hifiberry DAC RTC+, ethernet, and SDCARD class 10.

I tried 4.19.42 and 4.19.34 kernel with 5.2, but no differences. I don't know if the difference i saw on the CPU usage between 4.4 and 5.2, has an impact on temperature (i guess yes a bit, but i didn't have time to test more).

EDIT: With a third RPI on 5.2 i can see kinda the same behavior as i saw in V4.4 earlier, so probably not relevant.

EDIT 2: No throttling (throttled=0x0)
Reply
#20
Thanks for all the replies..

I would like to point out, back to one of my previous responses, running 5.0 with the latest Kernel (4.19.42-v7+ #1219) the CPU usage, with Coverview Automatic Display running, NEVER gets about 10-14%

I don't understand why that combination is fine, but it works.

I tried the same scenario with 5.2 and upgrading to the latest Kernel (4.19.42) however, the CPU usage does the same, varies between 180% and 220% (seems to fluctuate from high to low then instantly back to high every 3-5 seconds).

Downgrading the Kernel as Tim suggested, resulted in the same high CPU Usage.

As TheOlePrebyope (Kent) mentioned with the standard 5.2 image, if I have had Coverview (Automatic display) on with the high CPU usage, then disable it, the high usage continues. If I reboot, then it is fine (unless I turn on Automatic display again). But, then what is the point of a display screen if I cant have the Coverview enabled.

Also to note, Tim, you mention playing a Flac file without any issues.... It doesn't seem to matter what type of file that is played, the same high CPU usage occurs with Automatic Display on. And, to add to that, even if I am not playing a song, just have it sitting there, the CPU usage is high with the Cover being shown.

Anyway, just a few more bits of information from testing over the weekend....

I'm quiet happy to try different scenarios out if need be to help.

Thanks,
Rob
Reply


Forum Jump: