experiment-queue

Experiment Queue

Orchestrate large batches of ML experiments on SSH remote GPU servers with proper state tracking, OOM retry, stale cleanup, and wave transitions.

When to Use This Skill

Use when /run-experiment is insufficient:

• ≥10 jobs that need batching across GPUs
• Multi-seed sweeps (e.g., 21 seeds × 12 cells)
• Wave transitions (run wave 1, wait, run wave 2, wait, run wave 3...)
• Teacher+student chains (train teacher then distill; auto-trigger student after teacher done)
• OOM-prone configs where you need to retry with different GPU or wait
• Mixed seed grids where failed cells need re-running

Do NOT use for:

• Single ad-hoc experiment (use /run-experiment)
• Modal/Vast.ai deployments (those have their own orchestration)
• Experiments that need manual inspection between runs

Why This Exists

Based on session audit (2026-04-16), the major wall-clock sinks in multi-seed grid experiments are:

1. Stale screens — python finishes, wandb uploads, screen hangs, next wave blocked
2. OOM on shared GPU — previous job's memory not yet released
3. Wave race — new wave launches before previous wave fully settles
4. Missing checkpoints — student launches before teacher saved
5. Parser duplication — rewriting multi-seed analysis python every batch

All of these are pure engineering friction that can be orchestrated.

Core Concepts

Environment contract: queue jobs assume the target env is already built and validated per ../shared-references/compute-env-contract.md (spec-hash ledger + kernel witness). A wave of jobs dying at import time = the env contract was skipped, not a queue bug; check the provider's .aris/compute/<provider>.md ledger before re-queueing.

Job Manifest

A manifest lists jobs with explicit state:

project: my_grid_experiment
cwd: /home/user/your_project

Job State Machine

Operator note on stuck (the agent's move, not the queue's): the queue deterministically parks failed_other jobs as stuck — that part is code and unchanged. Before handing a stuck batch to the human, the OPERATING AGENT should check: if the same failure repeats across jobs, try ONE clean reimplement of the agent-generated wrapper/attempt script only — never user/project source, the manifest, queue state, logs, or results (per external-cadence.md, "Let a broken attempt restart, not just patch"). Reserve the human handoff for contract/environment doubts, not merely broken attempt code.

Wave Orchestration

A "wave" is a batch of jobs that fit available GPUs. Next wave only starts when:

1. All current-wave python processes have exited
2. No stale screens remain for current-wave tags
3. GPU memory has dropped below threshold (≤500 MiB)
4. Precondition checks pass for next-wave jobs

Workflow

Step 1: Parse Manifest / Build from Grid

Input can be:

• YAML manifest (explicit job list, recommended for complex cases)
• Grid spec (Cartesian product of param values, e.g., N=[64,128,256] × n=[50K,150K,500K,652K])
• Natural language description (Claude parses into manifest)

Bind run identifiers once so every later step refers to the same paths:

Save the built manifest to $LOCAL_RUN_DIR/manifest.json for reproducibility.

Step 2: Pre-flight

• Check SSH connection works
• Check conda env exists on remote
• Check cwd exists on remote
• Check all preconditions (checkpoints, input files)
• Check GPU availability (at least max_parallel free GPUs)

If any precondition fails, show user which jobs are blocked and why.

Step 3: Launch Scheduler

Resolve the bundled helper directory ($PROJECT_DIR / $RUN_TS / $LOCAL_RUN_DIR already set in Step 1). Phase 3.3 (Arch C) moved the canonical scripts to skills/experiment-queue/scripts/; tools/experiment_queue/ retains os.execv shims for legacy resolver layers:

Compute remote paths (note: modern scp runs in SFTP mode and does NOT reliably expand $HOME in destination paths — use remote-relative for scp, $HOME-prefixed for ssh command strings):

Bootstrap remote run dir + copy helpers + copy manifest. Per-invocation, idempotent:

Launch the scheduler as a detached nohup process:

Notes: --log-dir is what queue_manager.py actually consumes (per-job log files for OOM detection). Do NOT pass --log <path> — that flag is declared but unused.

Persist run identifiers for monitoring + resume (sourceable later):

%q shell-escapes values; REMOTE_RUN_DIR keeps a literal $HOME (correct for later reuse inside ssh "...").

Resume an existing queue. Do NOT regenerate RUN_TS. Reload from run_meta.txt and re-run only the launch command above (not the bootstrap):

The scheduler:

• Reads manifest
• Loops: for each pending job, assign to free GPU, launch via screen
• Polls job status (every 60s)
• Detects stale screens (python exited but screen detached → kill)
• Detects OOM (CUDA OOM in log → mark failed_oom → retry after delay)
• Detects completion (expected output JSON/file exists) → mark completed
• Launches next wave when current wave settles
• Writes state to queue_state.json continuously

Step 4: Monitoring

User can check state anytime, using $REMOTE_RUN_DIR from Step 3 (or reload it from $LOCAL_RUN_DIR/run_meta.txt):

Note: /monitor-experiment is currently focused on screen sessions, result JSONs, and W&B; it does not yet read queue_state.json directly. For queue-state monitoring, use the literal command above.

Step 5: Post-completion

When all jobs in manifest.json are completed or stuck:

• The remote scheduler (queue_manager.py) exits cleanly with All jobs done to its own stdout (captured in $REMOTE_RUN_DIR/queue_mgr.log). It does NOT write the local summary.
• The local skill agent then aggregates state into $LOCAL_RUN_DIR/summary.md (read $REMOTE_RUN_DIR/queue_state.json, group by status, optionally pull per-job logs).
• Local skill agent invokes /analyze-results if analyze_on_complete: true.

Grid Spec Syntax

Instead of writing 24 job entries manually:

Expands to 36 jobs automatically.

Wave Chaining

For sequential phases (teacher → student):

Scheduler enforces depends_on: distill_students jobs stay pending until every train_teachers job is terminal — completed or stuck. A failed teacher does not hold its students back, so check queue_state.json for stuck jobs before trusting a dependent wave.

OOM Handling

Detect OOM from stdout:

On detection:

1. Mark job failed_oom
2. Kill screen
3. Wait oom_retry.delay seconds
4. Check if current GPU is free; if not, try another free GPU
5. Requeue as pending
6. Max oom_retry.max_attempts before marking stuck

Stale Screen Detection

Every 60s, for each running screen:

1. Check screen exists (screen -ls)
2. Check python PID still running (ps -p)
3. If screen exists but python exited:
   • If expected output file exists → mark completed, kill stale screen
   • If no output file → mark failed_other, kill screen

Resume-on-restart

If scheduler crashes / is killed:

1. Read queue_state.json
2. For each running job: check screen; if still alive, keep; if not, re-evaluate state
3. For each pending: continue normally
4. Idempotent: safe to restart scheduler without losing state

Output: Summary Report

Comparison with /run-experiment

Rule: Use /run-experiment for ≤5 jobs. Use experiment-queue for ≥10 jobs or anything with phases.

Key Rules

• Never overlap screens on the same GPU — always wait for memory.used < 500 MiB before launching new job
• Always write state to disk — every state change flushed to queue_state.json
• Idempotent scheduler — safe to restart; picks up from state file
• Expected-output-based completion — don't trust screen state alone; verify output file exists
• Bounded retry — max N OOM retries, then mark stuck and alert
• Dependencies enforced at launch — a wave launches only after every job in the phases it depends on has reached a terminal state. Note "terminal" includes stuck: if a teacher job fails, the phase still completes and its students launch against a missing checkpoint. Check queue_state.json for stuck jobs before trusting a dependent wave's results.

Known Failure Modes

• SSH connection drop during scheduling: scheduler keeps running on remote (nohup), just reconnect and check
• GPU reservation by another user: scheduler waits, does not pre-empt
• Disk full on remote: scheduler detects write failure, marks all pending stuck, alerts

Example Session

User: "跑 T5+T6 全部实验：T5 = N∈{80,192} × n 4 values × seed {200,201}, T6 = N∈{384,512} × n 4 values × seed {42,200,201}; T6 需要先 train teacher"

Claude invokes /experiment-queue:

1. Parses description into 2-phase manifest
2. Phase 1: T5 (16 jobs, no teacher dependency) + T6 teacher training (2 jobs)
3. Phase 2: T6 distillation (24 jobs, depends on teachers)
4. Deploys scheduler via nohup
5. Reports: "Scheduler PID 93534, total 42 jobs, estimated 6-7h wall-clock"

Then user can check anytime or wait for summary report.

See Also

• /run-experiment — single experiment deployment
• /monitor-experiment — check progress (now reads from queue_state.json)
• /analyze-results — post-hoc analysis
• skills/experiment-queue/scripts/queue_manager.py (canonical, Phase 3.3 move) — the scheduler implementation. Legacy entry at tools/experiment_queue/queue_manager.py is an os.execv shim.
• skills/experiment-queue/scripts/build_manifest.py (canonical, Phase 3.3 move) — build manifest from grid spec. Legacy entry at tools/experiment_queue/build_manifest.py is an os.execv shim.

Rationale / Source

Identified via 2026-04-16 post-mortem analysis (Codex GPT-5.5 xhigh) of a 1.5-day multi-seed paper experiment session:

• Wall-clock sink: stale screens, OOM, wave transitions, manual parser
• Token sink: re-writing orchestration code each session
• Cognitive sink: tracking which cells succeeded, which failed, which to retry

This skill targets the wall-clock sink specifically; see artifact-sync and paper-fix-auto-apply for the other two.