KDE Eco organized a two-day sprint to work on KEcoLab — the energy measurement lab I maintain. A few more people came and joined on day two, which made the discussions richer. The sprint was mostly about figuring out the next steps for KEcoLab, fixing some open issues with the measurement pipeline, and trying to get a second system set up in the lab. You can find the full sprint notes here.
Thanks to KDE e.V. for sponsoring the sprint, KDAB for hosting us at their Berlin office, and Volker for the guidance and support throughout.
Headless Remote Access
The first thing we wanted to sort out was making the lab PC fully remotely accessible, which means we could use it without having someone physically in the room to debug our issues with the lab PC. SSH was already working fine, but RDP was not very reliable (it used to break sometimes). Nowadays, We had to go to the lab PC in person once to allow remote connections, which is exactly the kind of thing you do not want to do repeatedly. During the sprint, we applied a fix using flatpak permission-set to persist screen capture permissions across reboots, based on a recently merged patch (plasma/xdg-desktop-portal-kde!326).
However, the issue is not fully closed. A couple of days after the sprint, the problem came back and it was not clear what had changed. We had a follow-up meeting to discuss this, notes here. Joseph and Volker are currently testing different approaches to figure out how to properly persist the session across reboots. We will update this once we have a reliable fix.
Setting Up a Second Machine
Cornelius Schumacher donated a Fujitsu Esprimo 510 to the lab for us to add as a second System Under Test. It did not go well. The machine threw six beeps on boot, which pointed to a CPU or motherboard problem, most likely a BIOS flash failure. We tried reseating the RAM, resetting the CMOS battery, testing each RAM stick one by one. Nothing changed. The machine is not usable, but we are keeping the hardware for spare parts.
Debugging the Okular Pipeline
We ran the full Okular measurement pipeline on Wayland and hit a few problems. On day two, we saw an R error about non-numeric data. When we looked into it, the collectl files had data from pipeline runs we had stopped earlier, stopping a pipeline mid-run was causing the next run to append data to existing files, which broke the statistical analysis. We now have issues open to fix this properly:
A cleanup stage has since been added to the pipeline to handle this — see !152.
The reports also had wrong durations and missing averages. That turned out to be missing stopActions in the ydotool scripts. Once we fixed those, the numbers looked reasonable. Joseph is continuing to work on this and will follow up on the remaining open questions.
There is also a broader question about the data itself. Our power draw results look very different from measurements taken at Umwelt Campus Birkenfeld back in 2022. Their data showed distinct power draw phases across tasks, while ours is mostly flat apart from the spike when Okular opens. It could be Wayland versus X11, Flatpak versus a repo package, or just Fedora versus Ubuntu. Probably a mix of all of them. Something to investigate.
Future Planning
We went through the open issues and talked about what comes next, integrating KEcoLab into a broader KDE Plasma testing workflow, planning for the Akademy BoF, and ideas around extending ydotool/kdotool to make measurement scripts more flexible. We did not get through everything but the direction is clearer now.
Outside the Lab
After the first day, Carl, Aakarsh, Joseph, and I headed to Tempelhofer Feld. It was a warm evening and the field was full of people cycling, skating, and just sitting around. We walked around for a while and talked about everything except KEcoLab, which was exactly what we needed. A big thank you to Carl and Joseph for showing us around, Berlin has a way of making you feel like you have all the time in the world, even when you have a pipeline to fix in the morning.
Not everything worked, but we came away knowing exactly what needs to be fixed and why. That is usually what a good sprint looks like.
Tempelhofer Feld