WebPlatformForEmbedded/meta-wpe

Temperature on RPI

bobby-beckmann opened this issue · 8 comments

So, I've got sumo latest built and running in a docker container using resin-wpe as my starting point (but upgrading all packages to sumo). I've noticed that the pi has started running about 8c hotter than it was with same content on the wpe build that comes with resin-wpe. Has anyone had any issues with it running hot? Wondering if there's a setting I need to set so it doesn't light up the CPU as much. The content isn't driving any video, so something else must be making it steamy. Thanks!

kraj commented

check your /boot/config.txt and see what all options are enabled

/boot/config on the host is the same. So, the diffs between the meta-wpe's is:
5920963...d749c9a

Seems like when it introduced WPEFramework to launch WPE the temp went up 10 degrees, so it feels like it's a configuration issue? I notice that WPEFramework is using a full core and running at 100% cpu.
(from the host)
1749 root 20 0 226752 14540 11900 R 100.3 1.9 20:50.26 WPEFramework

Well, I just built off of master, and now temperature is normal. Not sure what I did, however, now CSS animations are kind of clunky. And, as an edit, it crashes most of the time when I load up my web page.

Is there a particular yocto release that's best suited for a docker container? I'm having a hard time figuring out what direction I should be going here for the best performance. I'll give rocko a shot next...

@bobby-beckmann it seems like one of the plugins is stuck and hogging up a CPU. Master contains bleeding edge and stuff may break however I'm curious to know what is going wrong on your end. I did not experience the same on my master build from a week ago, but I'll fire one up and cross check the latest to be sure.

If you have time I got some Q's / steps that will help trying to figure out what's going wrong.

  • Does this also happen if you foreground the WPEFramework process? (e.g. /etc/init.d/wpeframework stop and just run WPEFramework -c /etc/WPEFramework/config.json

  • Can you enable coredumps and kill -HUP the WPEFramework process, getting a stack trace is very helpful.

Alternatively we can disable a bunch of plugins, easiest way to do this is as follows:

  1. Move all *.json files to away (do not remove) that are in /etc/WPEFramework/plugins, e.g. move them in a subfolder called off. This will force WPEFramework to not start any plugins.
  2. Foreground WPEFramework, is the issue still there?
  3. Add plugins one by one back into /etc/WPEFramework/plugins until the issue is back and repeat step 2.

That will be helpful in order to determine which plugin is causing the issue. Thanks!

I just tried with a vanilla (non-docker) RPI3 image from master and CPU usage is normal:

  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  348     1 root     S     218m  35%   0% /usr/bin/WPEFramework -b

Is this specific to running in docker? Can you try with a RPI3 image instead?

Alright, sorry was out yesterday. So, here's what I've got:

I put a docker image here: bobbybeckmann/resin-wpe:latest. I built it using rocko master.

If do the following:
docker run --device=/dev/vchiq -p 8001:80 fcb1a5e22569 /usr/bin/WPEFramework
100% CPU usage

Now, if I do this:
docker run -it --device=/dev/vchiq -p 8001:80 fcb1a5e22569 /bin/bash
Then, run WPEFramework from the command line. Runs nice and cool.

So, something is happening when it runs as a foreground process.

I've solved it by adding a file that runs WPEFramework from /etc/init.d and then starts /bin/bash in the background. I'll fold these into the image at some point, but it seems like there's an issue somewhere, but I don't even know where to start looking. Now, I'm mostly just curious.

That being said, this is a nice piece of software that's been quite easy to use.

Closing this. There's a valid workaround I don't think it needs more investigation.