Dispersión

1. Abstract & Motivation

Modern operating systems expose hardware resources through generic, one-size-fits-all APIs. A video editing workstation, a gaming machine, and a CI build server all receive the same scheduler priorities and memory management policies — despite having radically different performance requirements at any given moment.

Dispersión addresses this gap for the Orzatty compute environment. It provides a direct, low-overhead bridge between application-layer performance intelligence and hardware-level resource allocation controls. When a CENTINELA-monitored process triggers a performance threshold, or when OrzattyOS determines that the active workload has shifted, Dispersión translates that signal into a precise hardware intervention — adjusting CPU scheduler priorities, flushing memory, or reconfiguring the graphics pipeline — all without user intervention and with sub-100ms latency.

2. System Architecture

Dispersión is organized as a set of cooperating subsystems, each with a clearly defined role. The Hardware Bridge is the only component that communicates directly with kernel interfaces. All other components send requests to the Bridge via IPC:

3. Hardware Bridge IPC

The Hardware Bridge is the privileged kernel-interfacing component of Dispersión. It runs as a system service and exposes a local IPC socket that application-layer components use to request hardware resource changes. All commands are validated and rate-limited by the Bridge before application to prevent runaway optimization loops.

IPC Protocol

Commands are sent as structured messages over a Unix domain socket. Each message includes a command identifier, target scope (system-wide, per-process, or per-device), and optional parameters. The Bridge responds with a JSON confirmation including the actual resource state before and after the intervention:

// IPC Command message format
{
    "command": "BOOST_LOW_LATENCY",
    "scope": "system",              // or "pid:1234" for per-process
    "priority": 8,                  // niceness delta (-20 to 19)
    "duration_ms": 5000,            // Auto-revert after N ms (0 = permanent)
    "requester": "dispersion-profiler"
}

// Bridge response
{
    "status": "applied",
    "command": "BOOST_LOW_LATENCY",
    "before": { "cpu_sched": "SCHED_OTHER", "nice": 0 },
    "after":  { "cpu_sched": "SCHED_FIFO",  "nice": -10 },
    "revert_at_ms": 1711058405000
}

Security Model

The Hardware Bridge only accepts commands from processes that present a valid capability token signed by Dispersión's internal key. This prevents rogue processes from abusing the IPC channel to hijack system resources. The token is issued by the Bridge to registered client processes at startup and rotated every 30 minutes.

4. Surgical Command Set

Dispersión defines a precise vocabulary of hardware intervention commands. Each command is named to be operationally descriptive, and all are designed to be time-bounded and self-reverting. The two primary commands in the current implementation are:

Command Extension

The command set is designed for extension. New commands are registered in the Bridge's command map and validated against a schema that enforces minimum duration bounds, scope restrictions, and privilege levels. Community-contributed commands can be added via the shared configuration module.

5. OGAL: Orzatty Graphics Abstraction Layer

The Orzatty Graphics Abstraction Layer (OGAL) is the graphics-specific hardware management component of Dispersión. While the Hardware Bridge handles CPU and memory resources, OGAL manages the graphics subsystem: GPU workload prioritization, VRAM allocation policies, display refresh rate adjustments, and rendering pipeline configuration.

Key Capabilities

• Workload Detection: OGAL classifies the current rendering workload (2D UI, 3D game, video decode, compute shader) and applies the appropriate GPU frequency and power profile
• VRAM Management: Tracks VRAM allocation per application and can proactively evict unused resources when a high-priority renderer requests space
• Refresh Rate Control: On Wayland/KWin, OGAL can request VRR (Variable Refresh Rate) mode changes via the KMS (Kernel Mode Setting) interface
• Multi-GPU Routing: On systems with both integrated and discrete GPUs, OGAL routes workloads to the appropriate GPU based on thermal headroom and workload type

Driver Interface

OGAL communicates with GPU hardware through the standard DRM (Direct Rendering Manager) kernel interface, making it compatible with all major open-source GPU drivers (AMDGPU, Intel i915, Nouveau) and the NVIDIA proprietary driver via its management API:

# OGAL capability detection (on OrzattyOS boot)
ogal detect-hardware

Output:
→ GPU 0: AMD Radeon RX 7900 XTX (amdgpu driver)
  VRAM: 24GB GDDR6 | VRR: Supported (48-144Hz) | Compute: ROCm 6.1
→ GPU 1: Intel UHD 770 (i915 driver)  
  VRAM: Shared (8GB dynamic) | VRR: Not Supported | Role: Display Output
→ OGAL routing: GPU 0 (compute/render) | GPU 1 (desktop compositor)

5.5. Dispersion AI (Confidential / Top Secret)

While the OGAL and Hardware Bridge components are documented, the third pillar of the project, Dispersion AI, remains highly classified. Currently operating within the strict confines of Orzatty Research Labs, Dispersion AI is a predictive neural layer designed to anticipate hardware bottlenecks before they occur.

By monitoring microsecond-level motherboard latencies, cache misses, and pipeline stalls, the AI engine proactively adjusts the Hardware Bridge's surgical interventions. All technical specifications regarding its parameters, architecture, and deployment timeline remain under embargo.

6. Monitoring GUI

Dispersión includes a real-time monitoring dashboard that provides operators with full visibility into current hardware resource states, active interventions, detected application workloads, and historical optimization outcomes.

Dashboard Panels

• Resource Monitor: Live graphs of CPU %, memory %, disk I/O, network I/O, GPU %, VRAM usage — all updated at the Hardware Bridge's monitoring interval (configurable, default 2 seconds)
• Active Processes: Table of all profiled processes with their categorized workload type, resource consumption rank, and any active optimization applied to them
• Intervention Log: Chronological log of all BOOST and PURGE commands applied, with before/after resource metrics and revert timestamps
• Override Panel: Operator-controlled manual command dispatch — allows direct BOOST_LOW_LATENCY or PURGE_AGGRESSIVE to any process without waiting for automatic trigger
• Performance Alerts: Critical alerts (e.g., CPU temperature > 90°C, memory exhaustion > 95%) displayed as overlay notifications

7. Configuration System

All Dispersión behavior is governed by a unified configuration file that is validated at startup and hot-reloadable at runtime:

[hardware_bridge]
monitoring_interval_ms = 2000    # Hardware state polling interval
command_revert_default_ms = 5000 # Default auto-revert window for time-bounded commands
max_concurrent_interventions = 3 # Maximum simultaneous hardware modifications

[ogal]
vrr_enabled = true
multi_gpu_routing = "auto"       # auto | discrete-only | integrated-only
vram_eviction_threshold = 0.85   # Trigger VRAM cleanup at 85% utilization

[profiler]
detection_interval_ms = 5000
workload_categories = ["gaming", "video", "development", "office", "idle"]
min_cpu_threshold = 0.05         # Ignore processes using less than 5% CPU

[gui]
update_interval_ms = 500
alert_temperature_celsius = 90
alert_memory_percent = 95

8. OrzattyOS Integration

On OrzattyOS, Dispersión is installed as two systemd services — one privileged (Hardware Bridge) and one user-level (OGAL + Profiler + GUI):

dispersion-bridge.service   # Runs as root. Manages IPC socket + kernel interfaces.
dispersion-user.service     # Runs as session user. Profiler + OGAL + GUI dashboard.

CENTINELA feeds performance anomaly events directly to the Dispersión Hardware Bridge and acts as a secondary trigger source: if CENTINELA's ResourceMetrics detect abnormal CPU or memory usage by a process, it can issue a PURGE_AGGRESSIVE command via the shared IPC interface — treating resource exhaustion as a potential security event (e.g., cryptominer, memory-flooding malware).

9. Roadmap