Seek starvation by superseded readers + cold far-seek latency

[cmcpherson274]

What happened?

Seek on a large remote MKV: superseded seek/prefetch AVIO readers keep fetching and starve the active seek — landing budget expires and re-anchors stack to 13-25 s; separately, a cold far seek anchors one segment before the target (~5 s floor at 65 Mbps source over a ~90 Mbps link)

Two related behaviours on far seeks in a large high-bitrate MKV served over HTTP, measured on a
real device with millisecond-timestamped logs (10 repetitions: 5x isolated cold seek 0->640 s in
fresh sessions, 5x rapid sequence 600->30->302->640 at ~4 s intervals).

THE BUG (rapid-seek case): when a new seek supersedes one still in flight, the superseded
pipeline's AVIOReader range connections and the forward subtitle prefetcher KEEP FETCHING. We
counted 5-8 concurrent range connections at 32 MiB-stride offsets competing on a link barely
above the source bitrate. The active seek's segment serve then starves: the same seg159 that
served in 2.2 s on a cold seek took 7.5 s (wait=7456.1 ms) under contention, the 8 s landing
budget expired — your own log: "seek did not land within budget (1 extension; starved,
island=1.37s at target...)" — the producer re-anchored, contention repeated, and observed
landings stacked to 13.7-25.2 s. The engine starves itself: its own budget is defeated by its
own uncancelled readers.

PERFORMANCE CONTEXT 1 (not claimed as a bug — cold-seek floor): on a fresh session, seek to
640.0 lands in 4.4-6.1 s (5/5, positionally exact every time). The timeline decomposes cleanly:
the producer restart anchors at the segment BEFORE the target (seg158 = 632.38 s for a 640.0
target at the seg159/seg160 boundary), so ~7.6 s of pre-target media — 56.4 MB at this bitrate —
must flow before the playhead reaches the target. We measured that transfer at 90 Mbps, our
link's line rate; the engine's own repositioning took 0.31 s (restart 33 ms, first ranged data
177 ms, A/V gates open at +310 ms). So the floor is transfer-bound geometry, not engine CPU.

PERFORMANCE CONTEXT 2: first new PGS cue after a cold first seek arrives in 3.7-6.4 s (10/10
sessions); after later seeks in the same session, usually 0.2-0.9 s. The warm number shows the
fast path exists; the cold path pays the full pipeline serially. (49 PGS tracks on this file.)

Our product gate has a 2 s command-to-correct-state seek deadline — that is OUR bar, not any
contract of yours, and this report is framed accordingly: the starvation is the part we believe
is yours; the cold floor on our Wi-Fi bench is substantially our link (on gigabit the same
geometry would cost ~0.5 s).

Steps to reproduce

1. Serve a large high-bitrate MKV over HTTP (ours: 48.29 GB 4K HEVC DV P8.1 remux, ~65 Mbps
   overall; any comparable file should do) and play it via the local-HLS path into AVPlayer
   (4.000 s segment duration).
2. BUG: while playback runs, issue several far seeks ~4 s apart (e.g. 600 -> 30 -> 302 -> 640).
   Watch the AVIOReader connection log: superseded generations keep opening/fetching at 32 MiB
   strides alongside the new seek's reads. On a link within ~1.5x of the source bitrate, the
   active seek's segment serve time balloons (2.2 s -> 7.5 s for the same segment), the landing
   budget expires ("starved"), and the re-anchor cycle stacks landings to 13-25 s.
3. COLD FLOOR: from a fresh session, single seek to a far target near a segment-boundary end
   (e.g. 640.0 with 4 s segments). The producer restarts one segment early (632.38 s), forcing
   ~7.6 s of pre-target media through the pipe before landing.

AetherEngine version or commit SHA

5.25.2 (cf164d8); FFmpegBuild 2.2.0 (e832f22c), LibDovi 1.0.2

Host app

Custom / my own integration

Platform

tvOS

OS version

tvOS 26.5

Device / chip

Apple TV 4K (3rd generation), AppleTV14,1 — real hardware, not simulator. Network: Wi-Fi, ~90 Mbps effective measured (relevant to the numbers above and stated so the transfer-bound share is attributable to our bench, not your code).

Playback path

Native AVPlayer

Source media (for playback bugs)

48.29 GB Matroska remux: 4K HEVC, Dolby Vision Profile 8.1, DTS-X, 2 audio + 49 PGS tracks,
~65 Mbps overall bitrate, served by Jellyfin 10.11.11 as a direct file over HTTP range reads.
Cannot be attached (size + commercial content); full timestamped logs of every repetition are
available on request, and the behaviour should reproduce on any comparable large high-bitrate
MKV over a link within ~1.5x of its bitrate.

Error codes / log lines

No error is raised; the seek eventually lands. The two annotated timelines:

COLD SEEK (isolated-1, 5.199 s total; times relative to the seek command):
  t+0.000  seek begin target=640.0
  t+0.005  AVPlayer GETs /seg158.mp4; out-of-range -> producer restart
  t+0.039  producer restarted at idx=158, seek=632.38s absolute source PTS
           (restart took 33ms; stopWait=32 seek=0 build=0)
  t+0.216  new persistent range connection first data (offset ~4.52 GB — correct
           region immediately, no index hunting)
  t+0.310  video gate open: actual=632382 target=632382 shift=0 / audio gapMs=2.0
  t+2.725  seg158: served 21986807 B (wait=2719.9ms)
  t+5.024  seg159: served 34399188 B (wait=2241.6ms)
  t+5.199  landed at exactly 640.0

STARVED SEEK (sequence-2 gen=4, 25.1 s total, after superseding two in-flight seeks):
  t+0.011  seg159: out-of-range fetch -> producer restarted at idx=159 (101ms)
  t+0.9    firstNewCue=927ms (subtitle path is FINE here — video starves, cues don't)
  t+1.4..t+12  persistent conn starts gen=9..16 at 32 MiB strides — the superseded
           pipelines and forward prefetcher still fetching alongside the live seek
  t+7.5    seg159: served 34399356 B (wait=7456.1ms — same segment, 3.3x the cold time)
  t+8.1    "seek slow but producer serving target (island=1.37s at target...); extending
           budget 1/4"
  t+12.1   "seek did not land within budget (1 extension; starved, island=1.37s at
           target, rendered=603.01s buffered=603.01s); holding clock at target 640.00s
           and re-anchored producer at 640.00s, re-seeking"
  ...cycle repeats; landed at 640.0 at t+25.151

Anything else

• The fix(seek): recover slow-source VOD seeks without reverting the clock #216 bufferedSecondsAtTarget landing logic and the anchor= field from the PGS: 5.23.11 side-reader park (#230) regresses the 5.15.2 #143 shape — a seek landing whose only later display set is beyond the 60 s lead is never shown again (bisected: 5.23.10 good, 5.23.11 dark) #234 fix are
  both visible in these logs and behaving as documented; this report is about the transfer
  geometry and reader contention AROUND them, not their correctness.
• Possible paths, offered not prescribed: cancel in-flight AVIO generations when their seek is
  superseded; pause or deprioritize the forward subtitle prefetcher while a video seek is in
  flight; anchor the restarted producer at the target's own segment (or shorter post-seek
  segments, or expose the anchor choice) to shrink the cold-seek transfer.
• Landing CORRECTNESS was flawless throughout: every observed landing positionally exact
  (640.0/600.0/302.0/30.0), zero wrong-target landings, and nothing resembling the old
  far-seek item-death class (Far-forward seek into an unproduced region (loopback-HLS VOD) #141 in our records) at this release.
• Full millisecond-timestamped logs of all 10 repetitions, the m3u8/segment ledger lines, and
  our seek-target truth map are available on request.

[superuser404notfound]

Fixed in 5.28.0. Thank you for the measurement discipline in this report: ten repetitions, both cases separated, the transfer-bound share attributed to your own bench, and the discriminator built right into the data. The isolated cold seek measuring at line rate while the same segment took 3.3x longer in the burst is what made this findable, and I took the framing straight from it.

What it was

Not superseded readers, though I understand why the log reads that way. A producer restart stops the old pump and waits for it, and markCloseds a demuxer it has to replace; the restart coalescer runs one restart at a time; a prefetch re-anchor cancels its task and markCloseds its side demuxer. None of those leak a fetching connection.

What the log could not tell you is that the generation counter is per reader and that a bounded range starts a new generation every 32 MiB, so one reader walking forward looks exactly like several concurrent connections. There were two readers, not five to eight, and that was enough.

The second one is the subtitle forward prefetcher (#151), and on Matroska it is a second full copy of the stream. matroska_parse_cluster has ebml_parse read the whole cluster off the wire, and only matroska_parse_block then honours AVDISCARD_ALL, so a "subtitle-only" reader still pulls every video and audio byte to reach the sparse subtitle packets. Your session was asking the link for about twice the media rate; measured on another report's capture it came to 2.6x. On a link at 1.38x that is oversubscribed by construction, and the two readers split it.

Then it fed itself, which is the part that produced your 13 to 25 s. The landing budget expires, the recovery re-anchors the producer, the clock jumps, and a clock jump is what tells the prefetcher to re-anchor: it tore its session down and built a new one, paying a fresh open, the Matroska cue-index prewarm and a positioning seek, each of which since 5.24.0 takes a full bounded range off the same link. More contention, next serve starves, budget expires again.

What changed

The video path has priority now, as a rule rather than a share, since playback is load-bearing and subtitle lookahead is not:

• A seek in flight owns the link outright. Nothing else may spend the landing budget.
• A pump that is fetching outranks a side reader. A parked pump (forward buffer full, which on a link with headroom is nearly all of the time) leaves the link to it.
• Two bounded escapes so this cannot become a mute switch: a grace window after each anchor, so a freshly selected track fills even against a busy pump, and a cap on continuous yielding, so a pump that never parks cannot silently disable lookahead for the rest of a session.
• A playhead jump re-anchors the running prefetch session in place. One seek on a demuxer that is already open and already has its index, instead of a rebuild.

Your three suggestions all landed in some form, arrived at from the reader side rather than the cancellation side: the prefetcher is deprioritized while a video seek is in flight, superseded work stops paying for the link, and the per-jump rebuild cost is gone.

Measured

Reproducing this needed a bench that shapes the SUM of all connections; with per-connection shaping two readers each get the full rate and the defect cannot appear at all. That mode plus a far-seek pattern driver are in the release (Scripts/throttle-origin.py --shared, aetherctl play --seek-pattern).

900 s Matroska at 8 Mbit/s with one SRT track, everything sharing 1.4x the media rate, five far seeks 25 s apart, two runs per build:

	before	after
seek landing, median	23.5 s / 23.7 s	12.7 s / 13.8 s
source connections	35	21
side reader share of bytes	~47%	~24%

On your two performance notes

The cold-seek floor is yours to keep, and you priced it correctly. The producer anchors where AVPlayer asks: it requested seg158 for a 640.0 target, so the pre-target media is AVPlayer's own preroll geometry, not a choice the engine makes. At 90 Mbit/s against 65 Mbit/s of content that is about 5 s of transfer, and on gigabit it is the ~0.5 s you estimated. I would rather not shorten segments after a seek to hide it: the segment plan is what the whole timeline continuity rests on, and a variable-duration tail near the seek target has cost more than it saved every time it has come up.

Which also means a 2 s command-to-correct-state gate is not reachable on a link at 1.38x the source bitrate, whatever the engine does. The bytes for two segments have to arrive. What was ours was everything above that floor, and that is what this release removes.

For the retest

If it is still slow, the log now answers the attribution question directly. Connection lines name their reader ([AVIOReader] pump conn start gen=4 offset=... len=32MB versus prefetch), and the 30 s memprobe carries pumpFetchedMB next to prefFetchedMB plus prefetch=read|yield|park and prefetchYielded=Ns. If prefFetchedMB still tracks pumpFetchedMB during a seek burst, the arbitration is not engaging and I would want that log. 49 PGS tracks is also a lot of side-reader work in general, so I am interested in what your numbers look like against the synthetic bench above.

[superuser404notfound]

Re-measured the table above, because the bench script that produced it had a defect of its own.

rrgomes flagged it on #220: the throttle-origin.py that was in path for those numbers passed a body that ended short of its own Content-Length off as a complete one, which left the client waiting on bytes that could no longer arrive until its own 20 s stall timeout fired, and a single 180 s socket timeout also closed connections that were parked legitimately. Both are fixed in 96c85fa8, and the script now emits [proxy TRUNCATED] and [proxy GONE ... reason=], so neither can happen quietly again.

Both arms re-run with the fixed script, same driver, same shaped rate, same seek pattern, two runs per build:

	before	after
seek landing, median	17.8 s / 18.0 s	12.1 s / 12.2 s
source connections	21 / 21	15 / 15
proxy truncations	0	0
proxy idle closes	0	0

The improvement stands, and neither defect fired in any of the four runs, so nothing in the original table came from a teardown the script produced. source connections is now the count of TCP connections the proxy accepted, which the old script did not log at all.

The absolute values moved because the bench file had to be rebuilt: same 10x concat of the same source, same 4 s key frame interval, same 8 Mbit/s, but not a byte-identical encode, so segment boundaries and therefore landings differ. Read this as a like-for-like comparison inside one experiment rather than against the earlier one, and where the two disagree these are the numbers taken with a script that reports what it does.

The retest above is unaffected either way; this is about what the measurement rows are worth, not about the fix.

[superuser404notfound]

The arbitration got measured from the byte-attribution side, on different hardware and a different origin.

The reporter of #220 ran 5.28.0 with a subtitle track selected on a 4K HEVC Dolby Vision title at about 11.2 MB/s media rate, 4295 s to natural end of media, with every connection sharing a 15 MB/s shaped link:

	bytes fetched
pump	43.8 GB
side reader	5.7 GB

The side reader took 12% of what the video path did. The same title over an unshaped LAN pulled 57 GB against the pump's 73 GB, so about 0.78 of a full second copy of the file. Constrain the link and strict priority collapses that to roughly a tenth while the video path holds media rate, which is the bench table above arrived at from the opposite side of the wire.

Worth being precise about what that rate means. With a subtitle track selected two readers want about 2x media rate, so 15 MB/s against 11.2 is roughly 0.67x of what the pair would draw unarbitrated. The link is under-provisioned for the pair by construction, which is the condition this issue exists for, and it played to a clean end of media with zero slow reads.

What the same run also showed

Ten AVPlayerWaitingToMinimizeStallsReason freezes, five of 3.0 s and five of 4.0 s, nine of them in the back half. The reading offered was that the pump sat at media rate with no margin, so every hiccup surfaced as a stall. Two numbers from the same run do not fit that:

• The loaded range held around 33 s throughout. A 33 s buffer absorbs a 3 to 4 s deficit without AVPlayer ever having to wait.
• The link was not saturated. 43.8 plus 5.7 GB over 4295 s is 11.5 MB/s against a 15 MB/s cap, so about 3.5 MB/s went unused on average.

Two candidates, and they are cleanly separable:

1. AVPlayer's bandwidth estimator rather than the buffer. On the HLS loopback it estimates from segment delivery, and a slow segment can put it into waiting-to-minimize-stalls with plenty still buffered. Then the loaded range does not dip at the stall instant.
2. A valve grant. The continuous-yield cap fires only when the pump fetches for 60 s without parking once, and the side reader then takes 10 s of the link back so lookahead cannot be muted for a whole session. Each grant is 10 s at close to full rate in front of a pump with no reserve. The counter-argument is in the same numbers: 5.7 GB over 4295 s averages 1.33 MB/s, which fits inside the 3.5 MB/s the link had spare, so ordinary pump parks can account for all of it without the valve ever firing.

One run answers it. grep the log for #151 forward prefetch yielded the link for, which is emitted once per grant and gives the count and the timestamps directly, and log loadedTimeRanges from the timeControlStatus handler so the buffer is sampled at the stall instant instead of on the 30 s memprobe cadence. If the grep comes back empty, candidate 2 is dead and the estimator is the whole story.

If it turns out to be the valve, the lever is not the priority rule but the grant's granularity. A 32 MB range taken in one piece is too coarse in front of a pump with no reserve, where the same 10 s spent in smaller slices would stay inside the buffer's tolerance.

None of this changes what this issue is waiting on, which is the retest on the library with 49 PGS tracks.

[cmcpherson274]

Following up on my own report, with a correction and a data point.

The cold far-seek half of this issue was substantially my bench, not the engine.

I re-ran the identical seek shape (isolated 640 s ×5, then the sequence 600→30→302→640 ×5) on a wired Apple TV 4K instead of the ~90 Mbps Wi-Fi one, against the same 48.29 GB / ~65 Mbps HEVC file and the same 5.25.2 build:

  | Wi-Fi (original report) | wired, same build -- | -- | -- command→landing, all repetitions | 3.385 – 25.151 s | 0.180 – 0.885 s (median 0.692) under a 2.000 s bar | 0 / 20 | 25 / 25 isolated cold seek ×5 | 4.398 – 6.058 s | 0.836 – 0.885 s cue reacquisition | 3726 – 6402 ms | 101 – 1367 ms did not land within budget | 4 | 0 superseded / unobserved landings | 7 of 20 | 0 of 25

That matches the arithmetic in the original report rather than contradicting it: ~56.4 MB of pre-target media at 90 Mbps line rate is ≈5 s, while the engine's own repositioning measured 0.310 s. On a link where the transfer is not the bottleneck, the same geometry costs well under a second.

Two things this sharpens, both in your favour:

1. The starvation signature disappeared entirely (4 → 0). The superseded readers are still not cancelled, but their harm appears to need a link near saturation before it shows. So the severity in my original report was bench-specific, and the priority-gate approach in the 5.28.0 notes looks well aimed at where it actually bites.
2. The 7 "superseded / unobserved" landings were a cadence artefact of a slow link, not a pipeline defect. My harness issued the next seek on a fixed 4 s cadence; at ~0.7 s landings nothing is superseded and all 25 were observed. That part of the report was my instrument, not your engine.

I have not run 5.28.0 yet — when I do it will be under a pre-registered protocol, and I will report whatever it shows. Thanks for the quick turnaround.

(Bench: Apple TV 4K 3rd gen, tvOS 26.5, wired gigabit, ping stddev 0.607 ms. Same server, same file, same build as the original report. Not a controlled one-variable comparison — the unit also went 64 GB → 128 GB — so read it as "the failure did not survive the move off Wi-Fi", not as an isolated network measurement.)

[superuser404notfound]

Thank you for going back and re-running your own report against a second link. Retracting half your own severity is not the common move, and the wired arm is worth more than the retraction: it is the control the original report did not have.

The arithmetic closes on both arms

Your 56.4 MB of pre-target media, priced at each link:

	transfer	plus 0.310 s repositioning	you measured, isolated cold seek
~90 Mbit/s Wi-Fi	~5.0 s	~5.3 s	4.398 to 6.058 s
gigabit wire	~0.45 to 0.5 s	~0.8 s	0.836 to 0.885 s

Two links an order of magnitude apart, and on both of them the transfer plus the engine's own repositioning accounts for the landing with under a tenth of a second left over. That is about as cleanly as this kind of attribution ever resolves. The cold far-seek floor is AVPlayer's preroll geometry moving over the wire, in both arms, and there is nothing in it for the engine to give back.

One correction, because it would misdirect the retest

The superseded readers are still not cancelled

They are, and this matters for what to look for in the 5.28.0 logs. A producer restart calls stop() on the old pump, waits for it, and markCloseds the demuxer it replaces; the restart coalescer runs one at a time; cancelSubtitleForwardPrefetcher cancels the task and markCloseds its side demuxer, so a parked AVIO read cannot survive teardown either. What the log could not tell you was reader identity, and the generation counter is per reader and increments on every 32 MiB re-request, so one reader walking forward prints exactly like five to eight concurrent connections.

What 5.28.0 changed is not cancellation. It is which of two live readers gets the link. The distinction decides what the retest should grep for: connection lines now name their reader (pump, prefetch, nativesubs, extract), and a single prefetcher will still climb through gen= values without that meaning anything is leaking.

Which arm can show 5.28.0, and which cannot

The arbitration rule is "an actively fetching producer wins the link". On a link with headroom the producer parks as soon as its forward buffer is full, which is nearly all of the time, so the policy hands the link to the side reader exactly as before. On your wired box, before and after run the same program by construction. The Wi-Fi box is the arm this release exists for.

Since you are pre-registering, here is what I am predicting, before your run:

Wired (control, plus one real prediction)

1. command to landing does not move. It stays around your 0.692 s median. No Seek starvation by superseded readers + cold far-seek latency #240 mechanism touches it.
2. cue reacquisition should fall, and the 1367 ms upper edge should go first. The in-place re-anchor is the one part of 5.28.0 that does not depend on a constrained link: through 5.25.2 every playhead jump tore the prefetch session down and paid a fresh open, a Matroska cue-index prewarm and a positioning seek, each of which since 5.24.0 takes a full bounded range. From 5.28.0 it is one seek on a demuxer that is already open and already has its index. If that number does not move on wire, the re-anchor path is not engaging and I want the log.
3. grep '#151 forward prefetch yielded the link for' should come back empty and the memprobe should show prefetchYielded=0s. If it does not, a pump on an unthrottled link is not parking when it should, which is its own finding and a more interesting one than the seek numbers.

Wi-Fi (the actual test)

4. The 4 "did not land within budget" go to 0, and the 13 to 25 s tail goes with them. That tail was the self-feeding cycle, not the floor.
5. The floor stays, so do not set the bar at 2 s in that arm. Five seconds of preroll transfer at 90 Mbit/s is not reachable whatever the engine does. What 5.28.0 actually claims there is "no landing far above the transfer floor, and zero budget misses", not "under 2 s".
6. prefFetchedMB should sit far below pumpFetchedMB through the seek bursts. Measured on another reporter's shaped link it came out at 12% of the video path, against 78% unshaped.

And the risk in the other direction, which interests me more than the landings: strict priority can starve subtitle lookahead on a link that is already short. The 8 s grace after each anchor and the 60 s continuous-yield cap exist to bound that, but they are bounds, not proofs. If cues arrive late after a seek, or a freshly selected track comes up empty, that is a 5.28.0 regression and I want prefetch=read|yield|park plus prefetchYielded=Ns from the run. On the library with 49 PGS tracks that is the more informative of the two tests.

[cmcpherson274]

5.28.0 retest, wired arm, same rig and same shape as my previous comment: isolated 640 ×5 plus the 600→30→302→640 sequence ×5, the 48 GB / 49-PGS-track title, PGS track selected throughout. One build note first: a fresh resolve of 5.28.0 today floats LibDovi to a release whose tvOS platform floor is 17 against the engine's declared 16 and the build fails — I pinned the transitives to 5.28.0's own Package.resolved (ffmpegbuild 2.3.0, libdovi 1.0.2, smbclient 0.3.1) and built with automatic resolution disabled.

Against your predictions

  | 5.25.2 wired | 5.28.0 wired -- | -- | -- command→landing, all 25 | 0.180–0.885 s, median 0.692 | 0.181–0.908 s, median 0.707 cue reacquisition | 101–1367 ms | 101–1384 ms, median 920 did not land within budget | 0 | 0 superseded / unobserved landings | 0/25 | 0/25

1 — command→landing does not move: confirmed. Median 0.692 → 0.707 s.

2 — cue reacquisition falls: it did not. The upper edge is 1367 → 1384 ms. You said if the number doesn't move on wire the re-anchor isn't engaging and you'd want the log — it is engaging: all 25 seeks emit

#151 forward prefetch re-anchored in place at 640.00s (seek)

one line per seek, zero per-seek teardowns (the 45 forward prefetch started: lines across the run are the 10 app launches plus track-selection restarts, each startAt=0.00s, none follows a seek). So the mechanism works as designed and the wired number is flat anyway — reading it here, the fresh-open cost the re-anchor removes doesn't look like it was the dominant term of wired cue reacquisition at 5.25.2 in the first place. Happy to attach the per-repetition log slices.

3 — the yield grep comes back empty: yes, but the two surfaces disagree. grep '#151 forward prefetch yielded the link for' = 0 hits, as you predicted. But the memprobe does not show prefetchYielded=0s — it climbs 2s → 6s within sessions, and prefetch=yield appears in 2 of 127 fragments:

… prefWinMB=15 prefSusp=1 prefFetchedMB=1151 prefetch=yield prefetchLead=59.5s prefetchHarvested=5173 prefetchTbFallback=0 prefetchYielded=4s …

Either prefetchYielded counts ordinary priority yields that the once-per-grant line doesn't (and the counters are consistent, with the prediction pointing at the wrong one), or something is granting without logging. You'd know which; the full memprobe series is easy to hand over.

The regression you said interests you more: not observed on this arm. The prefetcher parks at prefetchLead=59.x s almost immediately and stays there (park in 112 of 127 fragments, read in 13), every post-seek first cue arrived inside 1.4 s, and a freshly selected track never came up empty. Unshaped byte split end-of-run: prefFetchedMB=1633 against pumpFetchedMB=1816, ~0.90 — same territory as the ~0.78 unshaped you quoted from the other reporter.

Caveats: fresh app session per repetition, so every rep pays one cold prefetch start; the Wi-Fi unit that produced the original report is retired from my bench, so your predictions 4–6 (the arm this release actually exists for) stay untested here. And thanks for the correction on reader cancellation — with the readers now named in the connection lines, pump/prefetch attribution was clean throughout: one walking reader climbing gen= values looks exactly as you described.