WAN Profiles & Impairments — Gray Space Parallel

delivered delayed / queued dropped corrupted duplicate reordered

How to read the animations. Each demo is one link: a sender (TX) on the left, a receiver (RX) on the right, and the emulator in between. Little squares are packets. The stack climbing at TX is the emulator's queue; watch it drain packet-by-packet into the sender as the link serves it. A big bright ✕ marks a drop. Animations are illustrative, not to scale — exact values are in the grey chips. Dynamic demos draw a timeline of their schedule with a moving playhead.

This page teaches; the emulator decides. The simulations here are approximations — in particular, when several dynamics overlap, the real scheduler merges them per field (strongest departure from base wins), while this page picks one dominant envelope. Before using any profile YAML for real, check it against the running emulator: POST /api/v1/profiles/validate.

Profile focus

The deep reference for one profile at a time: what it models, how the schedule behaves, exactly where you'd reach for it, what you can and can't tune today, how it differs from its neighbours, the tweaks people actually make, and the modulators worth stacking with it in a custom profile. Pick a profile — the Overview tab is the at-a-glance catalog; this is the manual.

profile

What's configurable, across every profile. A profile is a static base (all absolute values) plus an ordered list of dynamics. Base fields: bandwidth latency jitter loss lossCorr corrupt corruptCorr delayCorr duplicate reorder limit. Pulse fields (handover/burst/outage) must be deltas (+/-) so overlapping pulses add; envelope peak_* may be absolute or delta; an envelope takes either a cycle or phase durations, not both; markov bad: values are absolute.

config.yaml

The emulator is authoritative — validate any edit before use: POST /api/v1/profiles/validate. A per-link emulation: field overrides a single parameter at deploy without touching the profile.

Build your own profile

Start from a built-in profile (or from scratch), then tune the static base and stack on any of the nine dynamics — the link reacts live above. The right column shows the two ways to ship what you built. Approach A — a named custom profile under the top-level wanemu_profiles: key: reusable across links and it carries dynamics:. Approach B — reference the nearest built-in profile and pin individual fields with a per-link emulation: override under wanemu:: quick for a one-off, but static base fields only. Approach A always works; approach B appears only when a static pin can faithfully reproduce your build (it is withheld, with the reason, when it cannot).

start from a built-in profile

profile name (editable)

base — static impairment

dynamics — time-varying modulators

config.yaml — approach A: a named custom profile

Define it once under the top-level wanemu_profiles: key (a sibling of wanemu:, not nested inside it), then reference it by name from any impaired link's profile:. The whole base + dynamics travel with the name, and it is reusable across links.

config.yaml — approach B: a built-in plus per-link overrides

A per-link emulation: block pins static base fields only. It cannot add, remove, or edit dynamics:, and pinning a field a dynamic drives freezes that field flat. When your build can't be expressed this way, approach B is withheld and only A is valid. (Verified against the engine: emulation parses to an EmulationSpec applied as pins, last each tick.)

the emulator is authoritative — validate before use: POST /api/v1/profiles/validate

Self-contained: no external code, fonts, or network calls — every animation runs in your browser, safe offline or on an airgapped cluster. Built-in profiles mirror the emulator's shipped presets; animations are illustrative of behaviour, not literal timing. The running emulator is authoritative — validate any edited profile with POST /api/v1/profiles/validate before deploy.