100% CPU use when wifi is enabled

[nfolken]

I installed Devuan on an old eeePC 701 and I chose to only install the LXQT desktop (which installed Connman and cmst). I used Ethernet during install, and afterwards I unplugged it and tried to get wifi working. Cmst said wifi was off, but I was able to turn it on with connmanctl, but now cmst is unusable! It chews up 100% CPU and is almost completely unresponsive. Turn wifi off and its fine again. I've tried purging and reinstalling it, and I've tried launching it from the terminal, hoping it would throw some errors, but no luck and I'm not sure how to troubleshoot it further. I don't know if it could be related, but its a sysv init system, no systemd,

[andrew-bibb]

I am a bit baffled by this one. All CMST does is sit in in the system tray monitoring DBUS signals from Connman. It only should do something once it receives a signal.

The way you enabled wifi bypassing CMST is not typical so I tried doing the same here and by using htop I observed a spike in CPU usage of 19% to 25% on one core (varies on what is running when I do this) caused by the Connman daemon (connmand). I have a relatively good desktop, not super powerful but good and the spike is short lived. The eeePC as I recall were a modest system and I'm wondering if that spike may be hosing it.

For debugging can you run top or htop to monitor system use and then try to start wifi using connmanctl without CMST running, then with CMST running. Be curious to see what results you get. If it only happens with CMST I'm not sure to go from there but we can at least start with observing the system in top or htop.

[nfolken]

yeah, the eeepc has an old, single core celeron cpu, so if any one program starts chugging, the whole system is unusable.

I watched top while doing the following: With cmst off I enabled and disabled wifi through connmanctl. There were small 10% CPU hits that only lasted a second, so no problem. With wifi off I started cmst. CPU use went up to 30% for a few seconds and then was fine. Then I enabled wifi with connmanctl and CPU usage goes up a little, but after about 10 seconds cmst goes up to 90% and stayed there as long as cmst was running. I disabled wifi and it took over a minute before cmst calmed down again.

I wasn't able to find a way to turn on wifi in the cmst window, but I did find the option to toggle WiFi when right clicking the system tray icon, but this also causes the CPU to spike.

I took a look at the output of "dbus-monitor --system", and with wifi enabled it does get spammed with a TON of info, maybe because there are so many wifi services around me?

[andrew-bibb]

You can toggle wifi on and off in the Technologies window in the first (Status) tab. The systemtray option is another way of getting to the same place.

I suspect you may have found the problem with dbus outputting a ton of information. Every time a signal is sent CMST responds to it and updates the display widgets accordingly. It may just be too much for the system.

I remember seeing something in the Connman documentation long ago about Connman filtering wifi to only the strongest signals. I don't recall is that was built in or something that can be set in the config file. I know it is not a property that can be set via dbus. I'll try to find it again in the documentation to see if it is something that can be changed by the user.

If it is a super low power system you may be stuck using connman via the connmanctl interface and not CMST. Another option if you are really brave is to try the Blueplate tray controls I have here on GitHub. That was more of a puttering type play thing but they do work and take almost no system resources. Been so long I honestly don't remember all that they can do or not do for Connman monitoring and I'm probably not even in a position to support them anymore, but they are a very low system usage option if you can get them working.

[the9000]

I also see some elevated levels of CPU consumption by CMST. I have a laptop with a i5-7300U, so CMST does not badly slow down the machine. But it sometimes keeps consuming a large part of a CPU core, which reflects badly on battery life.

I suspect that CMST receives many events about wifi signal strength, connection speed, etc. If connman generates a ton of these events because the signal strength and link speed fluctuate a bit due to a noisy RF environment and routers adapting to it, CMST may keep receiving and processing a ton of these events, which may cost some CPU.

I can imagine that there could be an option to unsubscribe form such high-volume, low-importance DBus topics, while staying subscribed t more crucial and rare topics.

This is my hypothesis; any advice on hos to test it are appreciated. Of course I can read the source of CMST and connman and dig out the right DBus topics, but I suspect that someone who develops CMST has the right names and command snippets around in some notes file :)

[andrew-bibb]

Your suspicion is correct, we listen for and process every DBUS signal issued by ConnMan. That means every WiFi signal strength change for every access point ConnMan finds. I like the idea of turning off the listening, or maybe better keeping the listening but having an option to turn off the processing part.

We had a similar issue years ago with the data counters really chewing up resources, but in that case it was mostly flooding log files. Finally ended up by having the ConnMan counters disabled by default instead of turned on by default. Those I could enable and disable but I think for this problem just toggling the processing on and off will be what we need, plus I also don't think there is a DBUS method for these signals where I can toggle them on or off at the ConnMan level. ConnMan sends the signals no matter what, all we can do is choose to listen for them and then process the signal. I am going to be busy pretty much until the end of the year but after the New Year I should have some time to look into this.