-
Notifications
You must be signed in to change notification settings - Fork 4
Software
sunneed (sunneed users need no external energy
daemon) is the main software component of this project.
Software cannot use too much of a resource since that will take power.
- CPU Memory Batter manager (if not abstracted by sunneed) Wi-Fi/BT Network
- Motors
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
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.
TODO Come up with a formal spec for API calls accepted by sunneed
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 power 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.
2: If solar panels are our main energy source going forward it might be worthwhile to look into having an incoming power profile based on time of day or maybe even through some sort of weather lookup (something simliar to curl wttr.in)