HELIX Admission Control Strategy

Overview

HELIX gates prevent queue collapse by staggering request admission. But gates have a cost: they add latency overhead. The challenge is knowing when gates help vs hurt.

The ramp benchmark revealed the answer: Gates hurt exactly in the transition zone (Reynolds number Re=8-32) where concurrency is emerging, then help at high concurrency (Re=256+).

Hotpath-First Default

Environment: unset (or HELIX_GATE_STRATEGY=disabled)

Behavior:

• Gates disabled by default
• Resident loops run at full hotpath speed
• No admission control overhead
• Matches FOIL_NAIVE baseline

Rationale: Resident-jsonl/resident-flow-stdio are inherently serial (stdin-based reading). Gates add overhead without providing concurrency benefits. Hotpath-first design keeps default performance clean.

Gates are opt-in via explicit HELIX_GATE_STRATEGY=aggressive for:

• Testing HELIX behavior in isolation
• Concurrent scenarios where gates help (chaos engine, etc.)

User Control

Override with environment variables:

Disabled (Baseline)

HELIX_GATE_STRATEGY=disabled ./gnexec --resident-jsonl file.ts

• Gates never active
• Hotpath performance
• Use for: baseline comparison, low-concurrency workloads

Aggressive (Testing)

HELIX_GATE_STRATEGY=aggressive ./gnexec --resident-jsonl file.ts

• Gates always active (even for low indices)
• Full HELIX behavior regardless of load
• Use for: debugging, measuring HELIX in isolation

Adaptive (Default, Recommended)

./gnexec --resident-jsonl file.ts
# or explicitly:
HELIX_GATE_STRATEGY=adaptive ./gnexec --resident-jsonl file.ts

• Dual-threshold gating: hotpath + selective admission control
• Gates activate at Re≥32 (helps p99 -45–63%)
• Gates deactivate at Re≥1024 (gate overhead becomes worse)
• Sweet zone: Re=32–512 where staggered admission shines
• Best for production: hotpath speed at low concurrency + tail latency protection at moderate load
• Use for: normal operation (requires no tuning)

Baseline Override

FOIL_NAIVE=1 ./gnexec --resident-jsonl file.ts

• Disables ALL admission control (even gates)
• Equivalent to no HELIX
• Use for: pure baseline measurement

Reynolds Number Mapping

Measured on 2026-05-17 from monster-helix-ramp.mjs benchmark:

Key Findings: HELIX uses a dual-threshold strategy to optimize across all load regimes:

1. Below Re=32 (Hotpath zone): Gates disabled → zero overhead, serial workloads unaffected
2. Re=32–512 (Sweet zone): Gates ON → staggered admission prevents head-of-line blocking
   • Re=32: p99 spike reduced 3,060 µs → 1,389 µs (-45%)
   • Re=256: p99 reduced 601 µs → 219 µs (-63%)
3. Above Re≥1024 (Overhead zone): Gates disabled → admission delay becomes counterproductive
   • Re=1024: gate overhead +18% (215 µs vs 91 µs)
   • Re=4096: gate overhead +34% (145 µs vs 108 µs)
   • Re=8192: gate overhead +351% (293 µs vs 65 µs) ← gates actively harmful

Saturation thresholds:

• NAIVE: catastrophic spike @ 32 requests
• HELIX Adaptive: smooth across all loads by disabling gates at Re≥1024

Testing Gate Behavior

Run the ramp benchmark to observe Reynolds transitions:

node gnode/benchmarks/monster-helix-ramp.mjs

Expected output:

• NAIVE and HELIX both transition at Re~8
• HELIX shows spike at Re=32 (aggressive gates hurt)
• Both recover at Re=256+ (gates stabilize)

Adaptive mode (default) skips the painful zone and gates only at high concurrency.

Implementation

Gates are in src/helix_admission.rs:

• GateStrategy enum: Disabled, Adaptive, Aggressive
• admit() dispatcher: checks strategy and index
• admit_helix(): stagger logic (only called when gates active)

Resident loops in src/bin/gnexec.rs:

• run_resident_jsonl: batch_start tracking, per-request gate check
• run_resident_flow_stdio: same pattern for flow frames
• Both use hotpath (no gates) by default, automatically

Philosophy

Sane defaults: Adaptive mode gives you the performance of hotpath (no gates) when it matters (Re < 64) and the latency protection of gates when it helps (Re >= 64).

User control: Override with env vars for research, debugging, or specific workload tuning.

Automatic: No configuration needed. Just run it. Gates work quietly in the background, activating only when beneficial.