---
name: a-delta-between-two-readings-dates-the-observation-not-the-event
description: "A rate computed from two readings is an average over the OBSERVATION interval, not the event's; it silently assumes the event fits between your samples, and the inflated rate then aims the hunt at a pathological cause."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: ff17cc2d-3104-46c4-af90-8dc91d121e49
  modified: 2026-09-09T11:06:01.673Z
---

2026-09-09, hfenduleam C: hit 0.02 GiB free. The dispatch reached me as: "195.76 GiB at 10:37Z,
0.06 at 10:58Z — ~195 GiB in ~20 min = a sustained **>150 MB/s** writer, not build churn. Find the
writer." The arithmetic is right and the conclusion does not follow. The two numbers are two
READINGS; nothing established that the consumption happened between them. The real cause was
hertz's two discriminator pools (82.88 + 64.44 GiB Length-sum — two full test-profile workspace
builds for a 5-test filter) plus CI `_work` 40.93 and Temp 9.8, ≈196 GiB, accumulated over the
**1.5–2 h of build** he had told me his lane was mostly made of. Ordinary build churn, spread
across hours, wearing a 20-minute rate because that is when someone happened to look twice.

**Why:** the derived rate does not just overstate — it *retargets the hunt*. ">150 MB/s sustained"
is not a big version of "builds are writing"; it is a different KIND of cause, and it sent me
looking for a runaway log, a crash dump, VSS expansion, a torrent preallocating. Every one of those
is a plausible pathological writer and none of them was happening. A cause that is merely large
gets excluded by a rate that is impossible for it.

**The refutation is cheap and does NOT require solving the problem.** Measuring the live write rate
took ~15 s and killed the premise before I knew the answer: top writer 0.57 MB/s, ~1.5 MB/s
box-wide, i.e. two orders of magnitude under the claimed floor. When handed a derived rate, measure
the rate *directly* — the instrument for "is anything writing fast right now" is independent of
"what consumed the space", and it is the one that tells you whether you are hunting the right shape.

**The near-miss, and the sharpest face: a CUMULATIVE counter that happens to match your gap.**
`Win32_Process.WriteTransferCount` named `msedgewebview2.exe` pid 20664 at **188.7 GB written** —
numerically ≈ the ~195 GiB missing, sitting at the top of the sorted list, ready to be reported.
It was TeamViewer's embedded browser, **started 2026-09-04**, so 188.7 GB is five days at ~1.5 GB/hr.
A cumulative total cannot answer an interval question *at all*, and the coincidence of magnitude is
exactly what makes it convincing. Check the counter's ZERO POINT (process start) before it enters a
sentence. Sibling: [[base-rate-is-over-cell-executions-not-suite-runs]] — ask what the denominator
spans.

⚠ And the meter itself lied first: `Get-Process`'s `WriteTransferCount` came back **blank** in this
shell, so the filtered query returned an empty set that read as "no process has written >1 GiB" —
a clean zero that would have cleared every process on the box. Caught only by re-running unfiltered
as a control; CIM carried the real numbers. Same family as
[[a-stricter-meter-answers-a-confident-empty]] and [[an-absent-row-and-an-unreadable-row-render-identically]]
(pagefile/hiberfil/`vssadmin` all came back UNREADABLE-unelevated here, which is not ABSENT and must
never be reported as clear).

**How to apply:** when a rate arrives derived from two samples, say out loud what bounds the event
— usually nothing does. Ask the peer whose work spans the interval what they were RUNNING (hertz had
already told me: build-heavy, 1.5–2 h), because the mundane cause is the one the inflated rate
excludes. Then measure the rate live before spending the hunt. Kin:
[[reap-step-duration-is-not-the-window]] (a window's boundary is *resource reappears*, never *step
returns* — same error one level down), [[a-single-idle-sample-of-a-busy-box-is-a-lull]],
[[an-unmeasured-item-inherits-its-categorys-size]].