Software

sunneed

sunneed (sunneed users need no external energy daemon) is the main software component of this project.

High-level overview

If the battery dies, then the system dies with it; therefore, making sure the battery never reaches zero is the fundamental goal of sunneed. To that end, it should always be keeping an eye on the battery to take emergency measures if it gets in the red.¹ But obviously, we want to come up with ways to achieve that fundamental goal preemptively rather than reactively, so we need to take the first step and limit the power draw of an application before. There are a number of ways to go about this. The main approach I have in mind, and the one we have been discussing, is a daemon that aggressively constrains the power usage of client processes, blocking access to peripherals and system resources until "safe" to do so power-wise.

Applications running on a sunneed-using host are blocked from making system calls related to I/O and must instead use one of sunneed's library functions. The library function just uses a basic IPC connection of some kind to send the request for data to the currently running sunneed. Upon receiving one of those requests, sunneed weighs that application's power budget and the cost of the call in relation to the system's power budget and makes a decision on the syscall. After that, it sends a response containing a result code and any necessary data back to the client. The client process can then use the response data.

sunneed follows a fairly standard client-server architecture, in this case serving the client applications with grants for power. The clients request these grants in order to use hardware peripherals; consider the desired action as the operation and the cost of power-time as the price. So, it is necessary to give the daemon some kind mapping of operation → price. We can get as granular as we want here, but the idea we seem to be going towards is on the scale of power required per read(s) from a hardware peripheral. We should also keep in mind the prices for operations associated with othe parts of the system, namely storage and RAM. CPU is its own beast, but I have a solidified version of the approach we've been discussing below.

TODO: Talk about required equipment

TODO: Record metrics for power draw of different system components

Cycle bank

An approach for CPU tracking agreed upon was to run the CPU at a constant clock, only dropping to enter the processor's sleep state. With that in place, we can charge applications by CPU time, and then just multiply that by the power/time usage, which we know ahead of time since the CPU clock is constant. We can consider the available CPU time between now and an arbitrary time ahead in the future to be the reservoir of the cycle bank (technically CPU time bank is a more accurate name but cycle bank sounds much better). The client asks sunneed for a special operation before doing its calculations: a request for some amount of CPU time. If sunneed decides to allow it, then the client is free to consume CPU time. If a client starts performing things (instead of just blocking on the request for time) without having its cycles granted to it ahead of time, it is forcibly dealt with by sunneed. In that way, it is similar to a CPU time overuse killer, except it imposes upon applications and requires they interact directly with it or be killed.

Currently we need to decide on how and when time requests will be processed.

API Calls

First let's define some terminology:

• Resource: the physical handler of an operation that takes power to perform. Examples include peripheral devices like cameras as well as system resources such as the CPU. Resources are usually defined by the operation that is performed through them. Resources have additional parameters such as wakeup time that are defined separately from the operation.

• Operation: the action performed by a resource. Operations can be fixed tasks, like taking a picture with a camera, or can take parameters, such as rotating a servo to a specified position.

• Price: the cost, in power, associated with one execution of an operation. Because operations can take parameters, different invocations of one operation may have different prices.

TODO: Are there any properties we can add to operations to make them more useful? One idea I had was ensuring operations are fixed-price, to allow for ahead-of-time computation of prices.

COMPUTE(X)

The client will use X time units of processor time. Returns a result code indicating if the request was granted.

REQUEST(O, B)

The client wants the system to perform operation O and then store the results in buffer B.

Footnotes

1: Although certainly not within the realm of possibility anytime soon, I can theoretically see a system that doesn't monitor its battery, but instead uses known power consumption metrics to accurately predict the charge based on the total power consumed since a full charge. I don't know if there's any benefit to ditching the battery monitor, though.