Frequent wakeups of deconz binary

In order to find out why my home automation machine was running hot, I did some power profiling with powertop, top and iostat, and I noticed that the deCONZ binary was doing approximately 300 wakeups per second. This is the sort of thing that indicates a lot of frequent messages being processed.

I did some digging with strace and discovered that there is a ppoll() call being done every 0.003 seconds, the call looks like this:

ppoll([{fd=25, events=POLLIN}], 1, {tv_sec=0, tv_nsec=3000000}, NULL, 8) = 0 (Timeout)

In english this means: “Check to see if there’s data waiting on file descriptor 25, but return after 0.003 seconds” - and this is probably the source of the majority of the wakeups that deCONZ is doing.

If this polling interval were increased: even by a factor of 10 - to allow whatever else this polling loop processing is doing, no appreciable human latency would be introduced (there’s no other I/O happening on that thread), and CPU + heat + context switching could be reduced considerably.

This is just a guess based on strace data, it’s entirely possible there’s other considerations and the 0.003 second timeout is necessary for reasons I don’t understand. I don’t seem to have access to this source code so I can’t check.


The wakeup of the process by ppoll() is likely caused by the Qt serial port library. Such a call is required to read the serial com port. As far as I’m aware this is hard coded in the Qt library.

Was the test made with deCONZ version v2.12.6?

The use of the Qt serial port library here was changed from sync to async API, and in tests showed that the CPU usage was reduced.