fault-injection-loop

Submit prioritized fault-injection experiments in pairs via sbatch on SLURM clusters.

320|60|Updated Oct 4, 2024
One-click install
npx skills add https://github.com/NVIDIA/nvidia-resiliency-ext --skill fault-injection-loop
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fault-injection-loop
Source: https://github.com/NVIDIA/nvidia-resiliency-ext/tree/main/src/nvidia_resiliency_ext/skills/nvrx-attr/fault-injection-loop
Command: npx skills add https://github.com/NVIDIA/nvidia-resiliency-ext --skill fault-injection-loop

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

Closed-loop fault-injection experimentation is automated end-to-end, enabling rapid benchmarking of resilience workflows for large-scale ML training by coordinating a prioritized pool of experiments and submitting them two at a time to bound filesystem load.

Core Features & Use Cases

  • Closed-loop fault pool design with prioritized (fault_type, rank, iter, nodes) entries and automated submission.
  • Deterministic batching: two simultaneous jobs per round with SBATCH and waiting until both finish.
  • Automatic post-run analysis: log-analysis and FR-analysis, then attribution scoring and gap aggregation to guide improvements.

Quick Start

Configure your environment and run the batch workflow with bash scripts/prepare_node_alloc.sh to start submitting fault-injection experiments.

Frequently Asked Questions about fault-injection-loop

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate fault-injection benchmarking for large-scale ML training on a SLURM cluster?

Closed-loop fault-injection benchmarking is automated by identifying prioritized experiments and submitting two jobs at a time via sbatch to bound filesystem load while testing large-scale ML training resilience.

What is the best way to bound filesystem load during concurrent fault-injection experiments?

To bound filesystem load during fault-injection experiments, the workflow submits exactly two simultaneous jobs per round using sbatch and waits until both finish before starting the next batch.

Does this closed-loop fault-injection workflow support Megatron-LM training workloads?

Yes, this closed-loop fault-injection workflow is compatible with Megatron-LM workloads, automatically running post-run log-analysis and FR-analysis on experiments to score attribution against ground truth.

Do I need logsage and LLM_API_KEY to run attribution scoring and FR-analysis?

Yes, you need logsage and an LLM_API_KEY to run attribution scoring, because the workflow relies on nvidia-resiliency-ext installed tooling to perform post-run log-analysis and FR-analysis.

How do I iteratively improve fault attribution modules after running fault-injection jobs?

To iteratively improve fault attribution modules, the workflow automatically runs log-analysis and FR-analysis after each batch completes, scores attribution against ground truth, and aggregates gaps to guide module improvements.

What are the limitations of submitting only two fault-injection jobs at a time via sbatch?

Submitting only two fault-injection jobs at a time via sbatch bounds filesystem load but limits throughput, requiring the workflow to wait until both jobs in a batch finish before proceeding to the next prioritized experiments.