TX retry policy for ARQ links: limit-vs-burst sweep, per-retry rate fallback, deadline-bounded retries, FEC dimensioning from the post-ARQ residual

[josephnef]

Context (measured, #359)

With the field-default DEVOURER_TX_RETRY_LIMIT=3, retry-exhausted frames are real, visible loss (ok=0): ~10–25/phase at 1 k fps under PixelPilot-shaped feedback bursts, ~700–900/phase at ~2.3 k fps saturation. Hardware retries are backoff-spaced, so a 3-retry budget can burn entirely inside one 2–3 ms burst — the frames that would have survived a longer straddle are dropped.

Steps

1. [measure] Retry-limit sweep. RETRY_LIMIT ∈ {3, 8, 16, 32} × burst arms (6M:10, 6M:30) on tests/arq_e2e_delivery.sh (knob already plumbed). Deliverable: delivered% vs airtime-cost curve + a recommended default for ARQ links, noted in docs/scheduled-mac.md.
2. [research] Per-retry rate fallback (J2/J3). Read the vendor xmit path for DATA fallback / lowest-rate descriptor controls and whether they apply to fixed-rate monitor injection; if yes, expose a retry-fallback knob and bench one arm (fallback vs fixed at the sweep's best limit). A retry ladder that steps down MCS converts repeats into robustness.
3. [research] Deadline-bounded retries. For FPV, late ≈ lost: investigate descriptor lifetime bits (J2/J3) to cap retries by time rather than count, tied to the video frame interval; queue_time_raw in tx.report is the measurement instrument.
4. [measure] FEC dimensioning from the post-ARQ residual. Extend tests/arq_e2e_analyze.py to emit the gap-length histogram of undelivered frames; derive the minimal wfb K/N covering P99.9 of the residual. Deliverable: the measured production pairing — ARQ tier for burst collisions + FEC floor for what retries can't reach (K=N=1 was diagnostic-only; this answers "how much FEC do I actually need with ARQ on" with data).

Acceptance

Published curves for (1) and (4); go/no-go with vendor citations for (2) and (3); a documented recommended (retry_limit, K/N) pairing.

Refs: #359 (bench, per-seq ledgers), docs/scheduled-mac.md.

[josephnef]

Step 4 first data — post-ARQ residual gap distributions from the recorded #359/#366 per-seq ledgers (near-field bench, retry_limit=3, PixelPilot burst shape; undelivered = report ok=0 plus unreported-and-undelivered, head/tail trimmed — conservative direction, slightly overcounts):

regime	residual	gaps (len×count)	P99.9 / max	FEC to cover P99.9
burst collisions only (baseline, healthy host)	0.18%	1×168, 2×20, 3×6	3 / 3	K=8 → N=11 (rate 0.73)
consumer stalls, plain async ring	3.81%	1×1054 … 100–111×4	111 / 111	N=119 (rate 0.07) — not coverable
same stalls, spsc-fat backpressure (#366)	0.56%	1×1127, 2×172 … ≤13	13 / 13	8/12 covers 94.9% of gaps (≤4); P99.9 needs N−K≥13

Reading: with hardware ARQ on, the collision residual is FEC-trivial — lighter than the classic 8/12. Stall-regime gaps are a ring-policy problem, not a FEC problem: plain-async stalls produce contiguous ~110-frame gaps no sane rate covers, while #366's backpressure bounds the same stalls to ≤13-frame gaps. The production pairing this suggests: retry_limit per step 1's sweep + backpressure ring + a modest FEC floor (8/12-class) sized to the collision residual, not to stall worst-cases.

Remaining for step 4: formalize the analyzer into tests/ (currently exploratory), and re-derive on the step-1 sweep arms so the (retry_limit, K/N) pairing lands from one dataset.

[josephnef]

Steps 1+4 measured and PR'd (#367): limit 3 → 99.72% (residual 0.26%), 8 → 99.97% (residual 0.03%, gaps ≤3, K8/N11 covers), 16 → 100.00% at +5.4% retry airtime, 32 → nothing for +17% more retries; queue-time p99 flat across limits. Recommendation in docs/scheduled-mac.md: 16 on an ARQ link, 8 + light FEC floor where airtime is precious. Steps 2 (per-retry rate fallback) and 3 (deadline-bounded retries) remain open.