tccd uses 3% CPU continuously

[xrat]

We received an InfinityBook S 14 v5 installed w/ Tuxedo Ubuntu Budgie 20.04 and we observed the following also on the same hardware with a fresh installation of Tuxedo Ubuntu 20.04 (i.e. w/ GNOME 3): tccd continuously uses about 3% CPU according to top.

# delay=10
# LC_ALL=C.UTF-8 top -b -d $delay -p $(pgrep tccd) | awk -v OFS="," '$1=="top"{ time=$3 }
  $1+0>0 { print time,$1,$NF,$9; fflush() }'
...
22:45:08,6872,tccd,3.4
22:45:18,6872,tccd,3.7
22:45:28,6872,tccd,3.1
22:45:38,6872,tccd,2.7
22:45:48,6872,tccd,3.0
22:45:58,6872,tccd,3.1
22:46:08,6872,tccd,3.2
22:46:18,6872,tccd,2.7
22:46:28,6872,tccd,2.6
22:46:38,6872,tccd,2.7
22:46:48,6872,tccd,3.3
22:46:58,6872,tccd,2.8
22:47:08,6872,tccd,2.6
22:47:18,6872,tccd,3.4
22:47:28,6872,tccd,3.3
22:47:38,6872,tccd,3.3
22:47:48,6872,tccd,3.7
...

[tuxedoxt]

Hello,

this is in percentage of one logical core right?

It is not clear what your exact issue is. Does this affect the performance of other programs you run? How is the CPU usage during other types of load? Does it have a noticeable effect on energy performance for you?

[nickma82]

Same here ~2.8% of a logical core v1.0.3.
journalctl -b -u tccd -f is not logging anything suspicious.

[xrat]

We just received our 2nd InfinityBook S 14 v5 with a 4 core Intel i7-10510U which shows the same behavior.

this is in percentage of one logical core right?

Yes, top reports per process cpu usage per logical core.

Does this affect the performance of other programs you run?

No.

How is the CPU usage during other types of load?

It goes down to about 1%. To reproduce use e.g. dd if=/dev/zero of=/dev/null. But apparently, it does not depend on CPU but rather(?) interrupts b/c I see the same drop when I start cheese.

Does it have a noticeable effect on energy performance for you?

This is hard to measure, as you know. Moreover, I have only very limited time where I can test the hardware before I have to give it to the users we bought it for. Anyway, 3% for a program that I expect to idle (especially when the system is idling) seems like too much.

BTW, I am not running the Control Center GUI, not even the tray icon.

BTW2, I realized the Awk command in OP does not work well in Mawk which is the default at least on the Tuxedo Budgie I received:

# delay=2
# LC_ALL=C.UTF-8 top -b -d $delay -p $(pgrep tccd) | mawk -W interactive '$1=="top"{ time=$3 }
  $1+0>0 { print time,$1,$NF,$9 }'

[tuxedoxt]

Right. Of course it is idling for the most part. According to previous profiling the "heaviest" part is the fan control. This is, of course, idling for the most part as well but spends some time reading/writing to the hardware, which I believe should not actually be CPU intensive.

How often to do this is a balance between responsiveness, "smoothness" and being lean. I'll have a look in between on what can be further optimized.

Otherwise please let me know if there are any concrete noticeable issues regarding energy performance. Our aim is of course to have all passive processes (tccd and the tray) use the least amount of resources while providing their benefits.

Note: With GUI, especially on the dashboard, more communication is done with tccd.

[mbway]

I have the same situation where tccd takes around 5-10% cpu at all times. After some fiddling I was able to run the service without having it packaged so that I could use the node profiler (using node --prof):
note: tuxedo-control-center is not running, this is running the daemon completely idle

sudo NODE_PATH="./dist/tuxedo-control-center/data/service:${NODE_PATH}" node --prof ./dist/tuxedo-control-center/service-app/service-app/main.js --start
node --prof-process isolate* > processed.txt

An overview of the results are

 [Summary]:
   ticks  total  nonlib   name
     43    0.7%    0.9%  JavaScript
   4817   78.0%   99.1%  C++
    115    1.9%    2.4%  GC
   1316   21.3%          Shared libraries

 [C++]:
   ticks  total  nonlib   name
   3176   51.4%   65.3%  v8impl::(anonymous namespace)::FunctionCallbackWrapper::Invoke(v8::FunctionCallbackInfo<v8::Value> const&)
   1138   18.4%   23.4%  epoll_pwait
     87    1.4%    1.8%  __libc_read
     69    1.1%    1.4%  __libc_open
     68    1.1%    1.4%  access
     36    0.6%    0.7%  syscall
     29    0.5%    0.6%  node::native_module::NativeModuleEnv::CompileFunction(v8::FunctionCallbackInfo<v8::Value> const&)
     19    0.3%    0.4%  node::fs::ReadDir(v8::FunctionCallbackInfo<v8::Value> const&)
     13    0.2%    0.3%  void node::Buffer::(anonymous namespace)::StringSlice<(node::encoding)1>(v8::FunctionCallbackInfo<v8::Value> const&)
     12    0.2%    0.2%  node::fs::Open(v8::FunctionCallbackInfo<v8::Value> const&)
     12    0.2%    0.2%  node::fs::Access(v8::FunctionCallbackInfo<v8::Value> const&)
     12    0.2%    0.2%  __write

 [C++ entry points]:
   ticks    cpp   total   name
   3299   73.0%   53.4%  v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*)
    507   11.2%    8.2%  v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*)
    373    8.2%    6.0%  v8::internal::Builtin_JsonStringify(int, unsigned long*, v8::internal::Isolate*)
     87    1.9%    1.4%  __libc_read
     69    1.5%    1.1%  __libc_open
     68    1.5%    1.1%  access
     36    0.8%    0.6%  syscall
     19    0.4%    0.3%  v8::internal::Builtin_ArrayBufferConstructor(int, unsigned long*, v8::internal::Isolate*)
      9    0.2%    0.1%  __write

So, there are a few things to note from the results

• the javascript-based logic is insignificant and only accounts for ~1% cpu usage
• I/O doesn't seem to account for much either (<5%) (at least, I/O initiated directly from javascript, Not counting any I/O done in the native library)
• There could be some wasted time spent parsing the config files when they haven't changed since last time? (~20%). Maybe the mtime could be checked before re-parsing?
• FunctionCallbackWrapper::Invoke might be to-do with the calls to the native-library? profiling that might be tricky.

from what I can tell, the epoll_pwait is to do with the libuv event loop inside node.
I tried profiling a setTimeout call to see whether time spent sleeping is counted by --prof and it doesn't look like it is. Looking at the implementation of epoll_pwait (specifically, ep_poll), it looks like the kernel enters a busy loop (which makes sense since the function has poll in the name).

using time, it looks like more time is spent in kernel-mode than in user-mode which would agree with this hypothesis

# time ... node .../main.js
real    0m58.922s
user    0m0.853s
sys     0m1.979s

I could be wrong about what is going on however. I haven't written any node applications so there may be some things I'm missing.

[sma-ops]

Having the same behavior (~4 % constant CPU usage) on my Infinity Book with Ubuntu 18. Control center is not running.

I saw no updates on the issue for quite some time. Is the current status that it is an expected / to be tolerated behavior?

[mbway]

I would still be interested in looking more into this at some point but it's a bit disheartening that there is no communication from tuxedo computers (my first pull request has been sitting idle for 5 months). If a simpler c++ daemon was written that would be easier to profile as there would be no node runtime polluting things and it might turn out that node was the culprit anyway, meaning the problem would automatically be solved by this c++ daemon. The first step to achieve this is to move the configuration state out of the typescript code and into configuration files so that TCC and tccd aren't so coupled. That's what my pull request #44 starts to do

[Matheus-Garbelini]

Hi @mbway I don't get high cpu usage, but I'm using a ryzen 3900x. If you try to increase this value from 500 to, 3000 for example:

tuxedo-control-center/src/ng-app/app/tcc-dbus-client.service.ts

Line 38 in 7e92317

private updateInterval = 500;

Do you get a reduction in cpu usage? It seems there a lot of IO fetch happening there every 500ms and dbus-next is the library being used to do that. So I'm not sure if its their code or something on their dbus-library which could be blocking somewhere.

[MartinLuethi]

I just bought a InfinityBook S 15, very nice hardware. With help of powertop I got the power consumption down to about 5 W, mostly screen and keyboard backlight.
tccd sucks up about 200 mW continuously (according to powertop) without doing much (no control center running). This also keeps on CPU in a higher state than necessary. Switching off tccd gives me about 1 W less power consumption, which is 20%!

Is nodejs this inefficient? How often is the hardware polled, and can this be adjusted (I have a hard time finding anything in the code).
Thanks, Martin

[Matheus-Garbelini]

@MartinLuethi maybe take a look here:

tuxedo-control-center/src/ng-app/app/tcc-dbus-client.service.ts

Line 38 in 7e92317

private updateInterval = 500;

try increasing this time from 500 to something like 3000 to see if CPU usage reduces.

[MartinLuethi]

Thanks! I tried this and it changed a lot!
Although, now using the original version of tccd again is much better, too, and power is down to 3 mW now.
My best guess is, that one of the million libraries, that get pulled in building tuxedo-control-center is different and might have caused the problems in the first place.

Never having used npm before, the instructions in the README are not sufficient. Missing packages were

• pkg and electron (from the AUR on Archlinux)
• angular which I installed using sudo npm i -g @angular/cli
  So, maybe angular was to blame for the bad performance?

[brunoais]

Angular is very unperformant if not tamed (which is very hard to do). It can very well be angular.

[Fuzzillogic]

On my Infinity Book Pro 14 gen 6 tccd consumes more than 0.4W constantly, according to powertop. That's about as much as plasmashell, which does a lot more. On ~6.5W total idle consumption that's quite significant. And I too wonder about the choice to use web technology as Angular and Electron for a always-active background service on a device where power efficiency is a top priority. Wrong tool for the job?

[brunoais]

I think so too. Electron is a bad tool for the job.