Project Logs

Collapse

• Added Powersave Modes to Version 1.2 and Louia 1.4

  Lee Djavaherian • 12/06/2025 at 02:03 • 0 comments

  I added what I learned and did with Louia ObScura over the last 2 1/2 months on the Pi Picos to my original Linux-based Louia, releasing version 1.4 today which also contains a new, experimental powersave mode, turned on by default (although I probably should have kept it off).  I also added that powersave mode to this Pico-based project, and released version 1.2 of Louia ObScura today under GPLv3, the tarball attached in the Files section.

  I've got both the Pico 2 W version and the Linux-based version running simultaneously over at spartan://greatfractal.com now on different ports, the default Spartan port still directed to the Pico 2 W.  The Linux-based version has always been many times faster running on a single-core 32-bit Pi Zero, but of course that is at 1 GHz with 512 MB RAM, and it gets to use all of the CPU, Linux, and LuaJIT optimizations, too.  The Pico 2's RP2350 is also 32-bit (even dual-core with two more RISC-V cores), and similarly, I only use one of its two ARM cores, but it only runs at 150 MHz with almost a thousand times less RAM.  Using Lua 5.5 to also implement its own OS, the code got 3x larger on the Pico so the server is running a lot more interpreted code per request which also slows it down, as I have not optimized it.

  But I did take the time to add one optimization lately to reduce power.  In both versions, I had previously turned off blocking for TCP/IP sockets and just quickly looped through the socket function checking to see if there was a new connection before spawning a new coroutine.  Since I needed to loop anyway to allow my main dispatch loop (a sort of "kernel") to process multiple, concurrent requests so that I could avoid actual blocking of the socket for other requests, I had to use a lot more CPU cycles when I turned off the blocking on those socket checks.  In my early versions of Louia, I used something like the Unix select() function under LuaSocket's socket.select() to check for new or changed connections or block if nothing was happening.  But once I got a connection and the dispatch loop returned around to that socket check again, a lack of network activity would block its concurrency, becoming network IO bound and not CPU bound.  So I had to time it out quickly, negating much of the reason to use select in the first place, which would have saved me a lot of CPU cycles and power otherwise.

  But in working with them lately I realized that there is no good reason to keep the socket check unblocked if there is no concurrency in progress (no running coroutines).  So during the idle periods where there are no connections coming in and the last coroutine has ended, it starts blocking again which stops the main dispatch loop to save CPU power.  So on the Linux-based version, I just did a simple check to see if there are any coroutines running, and if not, set the socket.select() timeout variable to nil (blocking indefinitely until network activity).  It works in testing although I'm not sure yet if the socket itself is timing out after long periods of inactivity since I'm not calling it anymore, as I've gotten occasional locks with 1.4, so I may have to add a (long) timeout or periodic watchdog anyway.  Nevertheless, this new feature can be turned off.  But if there are coroutines running, or this feature is turned off, it sets it instead to the TIMEOUTCHECKSECS variable, a short delay that I use to control the dispatch loop speed and CPU.  On the Pi Zero when running atop Void Linux, when the powersave mode was turned on, the CPU use for louia.lua dropped so low during idle it was off the screen where I couldn't even see it.  Great!

  Yet... when I tried to do the same thing for the Pico 2 W, I ran into some problems.  Firstly, select(), of course, is a Unix-like construct that does not usually exist if you have no Unix-like OS (which is what I have here).  MicroPython (which I've never...

  Read more »

View project log