CPU C-State Exit Latency Jitter Slippage Playbook

Why this exists

Execution hosts can look healthy on average CPU utilization while still leaking p95/p99 slippage.

A frequent hidden source is aggressive CPU idle power states (deep C-states) in low-latency paths. When cores sleep too deeply, wake-up latency adds bursty decision-to-dispatch delay.

That delay is small in mean terms but large enough to break queue timing quality in fast books.

Core failure mode

When execution threads or IRQ-handling cores repeatedly transition into deep idle states:

• wake-up latency becomes state-dependent and bursty,
• decision loops miss intended dispatch cadence,
• child orders bunch after delayed wake windows,
• cancel/replace timing drifts behind touch dynamics,
• queue-age quality decays,
• fallback aggression rises near deadlines.

Result: tail implementation shortfall increases even when average host latency dashboards still look normal.

Slippage decomposition with power-state term

For parent order (i):

[ IS_i = C_{delay} + C_{impact} + C_{miss} + C_{power} ]

Where:

[ C_{power} = C_{wake-latency} + C_{burst-clustering} + C_{queue-decay} ]

• Wake latency: additional delay from deep idle exit
• Burst clustering: delayed intents released in short bursts
• Queue decay: stale passive quotes and reset-heavy retries

Feature set (production-ready)

1) Host power/CPU-state features

• per-core C-state residency ratios (C0/C1/deep states)
• deep-state exit-latency proxy (from perf/power counters)
• wake-event burst frequency (per second/per minute)
• CPU frequency transition rate during execution windows
• IRQ service delay under equal traffic load

2) Execution-path timing features

• decision-to-send latency quantiles (p50/p95/p99)
• inter-dispatch gap variance
• short-window dispatch bunching index
• cancel-to-replace path latency drift

3) Outcome features

• passive fill ratio by wake-latency bucket
• markout ladder (10ms / 100ms / 1s / 5s)
• completion deficit vs schedule
• branch labels: stable-power, wake-jitter, burst-recovery, deadline-chase

Model architecture

Use baseline + power-jitter overlay:

1. Baseline slippage model
   • existing impact/fill/deadline model
2. Power-state overlay
   • predicts incremental uplift:
     • delta_is_mean
     • delta_is_q95

Final estimate:

[ \hat{IS}{final} = \hat{IS}{baseline} + \Delta\hat{IS}_{power} ]

Train on matched windows (same symbol/session/volatility bucket) across different host power-state regimes to isolate power-path effects from market-state confounders.

Regime controller

State A: POWER_STABLE

• low wake jitter, smooth dispatch cadence
• normal policy

State B: WAKE_WATCH

• rising deep-state residency + widening decision tails
• reduce replace churn, enforce smoother child pacing

State C: WAKE_JITTER_STRESS

• sustained wake jitter and dispatch bunching
• cap burst size, increase minimum spacing, avoid fragile queue-chasing

State D: SAFE_POWER_MODE

• repeated stress episodes + deadline pressure
• conservative completion policy with strict anti-bunch guardrails

Use hysteresis + minimum dwell time to avoid control flapping.

Desk metrics

• CEI (C-state Exit Impact): wake-jitter pressure score
• JBB (Jitter Burst Bunching): clustered-dispatch severity
• QRD (Queue Reliability Decay): fill-quality drop under wake stress
• DDL (Deadline Drift Load): residual urgency accumulated during jitter windows
• PUL (Power Uplift Loss): realized IS - baseline IS in power-stress states

Track by host, kernel profile, symbol-liquidity bucket, and session segment.

Mitigation ladder

1. Latency-critical core policy isolation
   • pin execution + critical IRQ paths to low-jitter cores
2. Power-governor tuning for critical paths
   • keep critical cores out of deepest idle states where needed
3. Execution containment under watch states
   • bounded catch-up pacing, no blind backlog flush
4. Host segmentation
   • route highest-urgency flows only through validated low-jitter hosts
5. Continuous calibration
   • re-estimate uplift after kernel/firmware/power-policy changes

Failure drills (must run)

1. Synthetic idle-stress replay
   • verify early WAKE_WATCH detection on known jitter episodes
2. Catch-up pacing drill
   • ensure bounded recovery outperforms burst flush on q95 IS
3. Confounder drill
   • separate power-jitter effects from network/venue latency spikes
4. Policy rollback drill
   • validate safe revert path for power-policy changes

Anti-patterns

• Using average CPU utilization as a latency-health proxy
• Allowing deep idle policies on latency-critical execution cores by default
• Immediate backlog flush after delayed wake windows
• Blaming market microstructure without host power-path attribution

Bottom line

Deep C-states are not "bad" by default, but unmanaged wake jitter can become an invisible execution tax.

If you do not model and control power-state-induced timing distortion, queue-quality erosion will keep leaking basis points in tail windows.