System Maneuverability Score

From OODA WIKI
Revision as of 17:54, 8 August 2025 by AdminIsidore (talk | contribs) (Created page with "The '''System Maneuverability (SM) Score''' is a real-time, composite metric that represents the available computational capacity of a hardware system. It functions as the "supply" side of the Agentic Maneuverability Score equation, providing a single integer from 0 (no capacity) to 100 (nominal/idle capacity) that quantifies the system's ability to take on new computational loads. The score is calculated by a sensor script that continuously observes system-level me...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The System Maneuverability (SM) Score is a real-time, composite metric that represents the available computational capacity of a hardware system. It functions as the "supply" side of the Agentic Maneuverability Score equation, providing a single integer from 0 (no capacity) to 100 (nominal/idle capacity) that quantifies the system's ability to take on new computational loads.

The score is calculated by a sensor script that continuously observes system-level metrics and subtracts "penalty points" from a perfect score of 100.

Technical Description

The SM Score is calculated by the `get_sm_score.py` sensor script, which aggregates multiple sources of system stress into a unified set of penalties.

Penalty Sources

The total penalty is the sum of several weighted factors:

  • CPU & GPU Utilization: The primary drivers of the score. High utilization in either processor incurs a significant penalty, weighted at 30% of the total score each.
  • Thermal State: A penalty is applied if system temperatures exceed a warning threshold (70°C) and scales up to a maximum penalty at a critical threshold (95°C).
  • I/O Wait: High I/O wait times, where the CPU is idle waiting for disk operations, indicate a storage bottleneck and incur a penalty weighted at 20%.
  • Memory Pressure: Penalties are applied if swap usage is high or if total RAM utilization exceeds 80%.
  • Crash Detection: A large, immediate penalty is applied if the script detects evidence of a recent "Out of Memory" (OOM) crash in the system's kernel log (`dmesg`).

System Architecture

The SM system consists of several interoperating scripts:

  1. Sensor (`get_sm_score.py`): The core Python script that observes system metrics and calculates the final score.
  2. Logger (`log_sm_score.sh`): A shell script, typically run as a cron job every minute, that executes the sensor.
  3. Status File (`/tmp/sm_status.json`): The logger writes the output of the sensor (both the current score and a 7-day rolling average) to this JSON file. This file acts as the canonical source of truth for any other process needing to know the system's status.
  4. Desktop HUD (`extension.js`): A GNOME Shell extension that reads the status file every 5 seconds to provide a persistent, at-a-glance display of the SM score on the user's desktop.