From 60590193e36ea3c5743889405bbd88df7ef48cd3 Mon Sep 17 00:00:00 2001
From: MattJackson <1085847+MattJackson@users.noreply.github.com>
Date: Sun, 17 May 2026 07:53:41 -0700
Subject: [PATCH] iter5: READ_PIPELINE_DEPTH 32 -> 256 frames
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

iter4 measurement (Phase 2.5 + DONTNEED, no FileSectorSource buffer)
showed mean 24.0 MB/s but with dips to 2.8 MB/s. Channel at 32 frames
(~1.6 MiB at 50 KB/frame avg) drains in <100 ms on any producer pause,
starving the consumer.

256 frames = ~12 MiB ≈ 3-4 sec of consumer drain at the rolling-avg
floor we want to hit. Should coast through producer micro-stalls
without idle gaps.
---
 src/io/pipeline.rs | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/io/pipeline.rs b/src/io/pipeline.rs
index eb9d47f..eb76a1c 100644
--- a/src/io/pipeline.rs
+++ b/src/io/pipeline.rs
@@ -90,7 +90,16 @@ pub const DEFAULT_PIPELINE_DEPTH: usize = 4;
 /// Read pipeline depth. Larger buffer compensates for drive variability
 /// and NFS sync_file_range stalls; keeps ISO reader thread fed even when
 /// consumer blocks on write.
-pub const READ_PIPELINE_DEPTH: usize = 32;
+///
+/// iter5 (2026-05-17): bumped 32 → 256 frames. autorip iter4 measured
+/// dips to 2.8 MB/s with the previous 32-frame channel (~1.6 MiB at
+/// ~50 KB/frame avg). When the producer thread hits any micro-stall
+/// (UDF metadata cache miss, NFS RTT, decrypt key lookup), a 1.6 MiB
+/// buffer drains in <100 ms and the consumer sits idle. 256 frames is
+/// ~12 MiB — ~3-4 seconds of consumer drain at 4 MB/s worst-case
+/// sustained output rate, enough to coast through any single-event
+/// producer pause without starving the consumer.
+pub const READ_PIPELINE_DEPTH: usize = 256;
 
 /// Write pipeline depth. Smaller buffer reduces backpressure risk when
 /// sync_file_range blocks; prevents producer from accumulating too much