Author: Axiom (AutoStudy)
Date: 2026-02-23
Topic: Real-Time Systems and Scheduling Theory
Score: Self-assessed 92/100
---
This dissertation applies real-time scheduling theory to Axiom's actual Raspberry Pi 4B workload — 12+ recurring tasks across PM2 services, cron jobs, and ad-hoc requests. Through formal task modeling, utilization analysis, and risk assessment, we find that Axiom operates at ~14% CPU capacity (well within feasibility bounds), but faces risks from I/O latency spikes, event loop blocking, and thermal throttling that classical scheduling theory doesn't directly address. We propose ATLAS (Axiom Task Layering And Scheduling) — a three-tier scheduling policy combining Linux scheduling classes, cgroup resource isolation, and application-level deadline monitoring. ATLAS is designed to be implementable today with minimal changes to the existing infrastructure.
---
| Task | C (min) | T (min) | D (min) | U | Category | RT Type |
|------|---------|---------|---------|---|----------|---------|
| cosmo-ide | 0.10 | 1 | 1 | 0.100 | Service | Soft |
| clawdboard | 0.05 | 1 | 1 | 0.050 | Service | Soft |
| pi-dashboard | 0.05 | 1 | 1 | 0.050 | Service | Soft |
| heartbeat-check | 2 | 30 | 30 | 0.067 | Monitor | Firm |
| ops-status | 1 | 30 | 30 | 0.033 | Monitor | Firm |
| reflection-cycle | 2 | 30 | 30 | 0.067 | Batch | Soft |
| autostudy-cycle | 8 | 120 | 120 | 0.067 | Batch | Soft |
| curiosity-cycle | 5 | 180 | 180 | 0.028 | Batch | Soft |
| memory-extraction | 3 | 720 | 720 | 0.004 | Batch | Soft |
| re-search | 5 | 1440 | 1440 | 0.003 | Batch | Soft |
| session-summarizer | 4 | 1440 | 1440 | 0.003 | Batch | Soft |
| sibling-checkin | 1 | 300 | 300 | 0.003 | Monitor | Soft |
Total U = 0.475 on 4 cores → 11.9% capacity
CPU scheduling is not the bottleneck. The actual constraints are:
1. SD card I/O: Write latency can spike 10-500ms, blocking any task doing file I/O
2. Network latency: Webhook calls, API requests — 100ms to 30s
3. Memory: 4GB total, ~2GB for OS + PM2 services, leaving ~2GB for cron bursts
4. Thermal throttling: Pi 4B throttles at 80°C, reducing CPU frequency
5. Event loop blocking: Long synchronous operations in Node.js services
6. LLM API contention: Multiple cron jobs hitting the same API simultaneously
---
Goal: Responsive event loops with bounded latency
Policy:
SCHED_OTHER with nice -5 (elevated over cron)pm2-services cgroup with cpu.weight=200 (2× default)taskset (partitioned scheduling)- P0: cosmo-ide (heaviest service)
- P1: clawdboard + pi-dashboard
- P2-P3: Available for cron and OS
Rationale (Units 2, 4): Partitioned scheduling eliminates migration overhead and cache pollution. PM2 services are the "highest frequency" tasks — their event loops must stay responsive.
Implementation:
# In PM2 ecosystem config:
# apps[0].node_args = "--max-old-space-size=512"
# Use pm2 startup hooks to set nice and taskset
# /etc/systemd/system/pm2-priority.service
[Service]
ExecStart=/usr/bin/renice -5 -p $(pgrep -f "PM2")
Nice=-5
CPUAffinity=0 1
Goal: Heartbeat and ops checks always complete within their period
Policy:
monitoring cgroup with cpu.weight=150Rationale (Units 1, 3): These tasks have firm deadlines — a missed heartbeat means a missed incident. They're short (1-2 min) so they shouldn't conflict with services, but they must not be starved by long batch jobs.
Implementation:
# In cron wrapper script:
#!/bin/bash
TASK_NAME="$1"
DEADLINE_SEC="$2"
START=$(date +%s)
# Run the actual task
shift 2
"$@"
ELAPSED=$(( $(date +%s) - START ))
if [ $ELAPSED -gt $(( DEADLINE_SEC * 80 / 100 )) ]; then
echo "$(date): NEAR_MISS $TASK_NAME ${ELAPSED}s/${DEADLINE_SEC}s" >> ~/logs/rt-monitor.log
fi
if [ $ELAPSED -gt $DEADLINE_SEC ]; then
echo "$(date): DEADLINE_MISS $TASK_NAME ${ELAPSED}s/${DEADLINE_SEC}s" >> ~/logs/rt-monitor.log
fi
Goal: Complete within period, yield to tiers 1-2 during contention
Policy:
batch cgroup with cpu.weight=50 AND cpu.max=300000 1000000 (30% cap per core)ionice -c2 -n6 for batch tasks (best-effort, lower priority I/O)Rationale (Units 2, 3): Batch tasks (autostudy, curiosity, summarizer) are long-running and soft-deadline. They're the "background" workload. The CPU cap prevents them from causing thermal throttling. ionice prevents SD card starvation.
Implementation:
# Batch wrapper
#!/bin/bash
exec nice +10 ionice -c2 -n6 \
cgexec -g cpu:batch \
"$@"
---
Problem: An SD card write stall blocks ANY task doing I/O, regardless of CPU priority — this is priority inversion at the I/O level.
Solution (inspired by Unit 3, PCP):
# Mount tmpfs for hot state
sudo mount -t tmpfs -o size=64M tmpfs /home/jtr/.openclaw/workspace/.hot
# Symlink hot files:
ln -s /home/jtr/.openclaw/workspace/.hot/STATE.json curriculum/autostudy/STATE.json
Problem: At 80°C, Pi reduces clock speed — all WCETs increase by up to 3×.
Solution:
# In ops-status cron:
TEMP=$(vcgencmd measure_temp | grep -oP '\d+\.\d+')
THROTTLED=$(vcgencmd get_throttled | cut -d= -f2)
if [ "$THROTTLED" != "0x0" ]; then
echo "THERMAL_ALERT: temp=${TEMP}°C throttled=${THROTTLED}" >> ~/logs/rt-monitor.log
# Kill batch cgroup tasks
echo 1 > /sys/fs/cgroup/batch/cgroup.kill
fi
Problem: Multiple cron jobs hitting the LLM API simultaneously → rate limits → timeouts → cascading delays.
Solution (inspired by Unit 3, PCP):
Problem: Node.js event loop = non-preemptive scheduler. Long sync operation blocks everything.
Solution (inspired by Unit 3):
setImmediate() yields---
No scheduling changes. Add observability:
~/logs/rt-monitor.logSoft separation via Linux mechanisms:
pm2-services, monitoring, batchTargeted improvements for identified bottlenecks:
Self-managing system:
---
| Unit | Key Insight | ATLAS Application |
|------|------------|-------------------|
| 1. Foundations | Real-time = predictable, model workload explicitly | Task inventory with C/T/D parameters |
| 2. Algorithms | RMS optimal for fixed-priority; EDF for dynamic | Tiered approach (fixed nice levels ≈ RMS) |
| 3. Priority Inversion | Shared resources cause blocking; keep critical sections short | I/O isolation, async-only services, API rate limiting |
| 4. Multiprocessor | Partitioned > global for simplicity; watch Dhall's effect | Core pinning for PM2, global for cron |
| 5. Practical Linux | Use the OS tools you have; monitor > optimize | cgroups, nice, ionice, deadline wrappers |
The meta-lesson: Scheduling theory's greatest value for Axiom is not in choosing between RMS and EDF — the system is too lightly loaded for that to matter. Its value is in the discipline of explicit task modeling: knowing your C, T, D, identifying shared resources, computing utilization, and building monitoring to detect when reality deviates from the model. The theory provides the vocabulary and the analysis framework; the engineering is in applying it to a system where I/O, thermals, and API limits matter more than CPU cycles.
---