Data Recovery Case File · Solid State & Flash · Reading Your Own Instruments
Full Activity With High Latency Describes a Device Waiting, Not Working
Her enquiry supplies measurements rather than impressions. Flash storage with read problems where "the task view shows 100% active time, with a latency of around 250 milliseconds, and read values fluctuate too much to get a bead on." Those two numbers together are the diagnosis — full activity means a request is outstanding continuously, and quarter-second latency means each one is taking hundreds of times longer than it should.
| Media | 128GB flash storage device holding content of personal value — continuous reported activity with sustained high latency and unstable throughput |
| Reported situation | Flash storage device presenting read difficulties · system reporting continuous active time · latency measured at approximately a quarter of a second · read throughput fluctuating without settling · content of personal value held · further diagnostic information offered |
| Fault class | Severe read latency with retries dominating — device responding but not returning data within usable intervals; controller-level error handling indicated |
| Equipment used | Activity and latency figures interpreted as time awaiting completion rather than work performed · device addressed through hardware with imposed timeouts rather than the host stack · controller state assessed in vendor technological modes · chip-level read past the controller where indicated · translation layer reconstructed in software |
The decode: what each figure measures, and why together they are conclusive
What active time actually counts: the proportion of the interval during which at least one request was outstanding. It measures time waiting for the device, not work the device completed — which is why a nearly idle drive answering slowly can report full activity.
Why that distinction matters so much here: full activity looks like a device working hard, and it means a device that has not finished. A healthy drive completes requests fast enough that the outstanding-request figure stays low even under heavy use.
What the latency figure adds: the scale. Flash storage ordinarily answers in a fraction of a millisecond, so a quarter of a second is hundreds of times longer than expected — and it puts a number on what "slow" means.
What the device is doing during that time: retrying. A controller that reads a region and gets a result failing its internal checks attempts it again, applies correction, and tries once more — and the elapsed time is that cycle rather than data transfer.
Why the fluctuating throughput completes the picture: figures that will not settle mean conditions varying across the device. Some regions return promptly and others consume the full retry cycle, so a stable average never emerges — the instability is the surface condition being sampled.
What this narrows the fault to: the memory or the controller's handling of it, rather than the connection or the host. A device that responds at all is present and communicating — the difficulty is in retrieving what is stored, not in reaching the device.
Why the measurements she took were the right ones: they distinguish between a device that is absent, one that is slow, and one that is failing. Symptoms described as slowness cover all three, and the figures separate them without anybody needing to open anything.
Why continued use is the risk now: a device spending its time on retries is a device working at its limit. Every access consumes the margin a capture would depend on, and on flash a controller in this state can stop responding entirely rather than degrading further.
What is done differently: the device is addressed through hardware that imposes its own short timeouts, so no single region absorbs the available time. Regions that respond promptly are taken first, and difficult areas revisited afterwards rather than allowed to stall the process.
What must not happen: no file-level copying, which proceeds in folder order and stalls at the first slow region. The device should come out of use now.
On the bench
Activity and latency figures were interpreted as time awaiting completion rather than work performed — active time measuring the proportion of an interval with a request outstanding rather than throughput achieved, so full activity indicates unfinished requests, while quarter-second latency against sub-millisecond expectation places elapsed time in retry and correction cycles. Unstable throughput reflects conditions varying by region. The device was addressed through hardware with imposed timeouts rather than the host stack.
The outcome
The figures read as time awaiting completion, the device addressed through hardware with imposed timeouts, and responsive regions taken first. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: your two numbers settle it. Active time counts time with a request outstanding rather than work done, and quarter-second latency is hundreds of times longer than expected — so the device is retrying, not working.
Reading activity and latency figures on a failing device
Take those two numbers together and stop using the device. Active time counts the proportion of an interval with at least one request outstanding — it measures waiting, not work — so a device reporting full activity while returning almost nothing has requests it hasn't finished. Latency gives you the scale: flash ordinarily answers in a fraction of a millisecond, so a quarter of a second is hundreds of times longer than it should be, and that elapsed time is retry and correction cycles rather than transfer. Throughput that won't settle means conditions vary by region. Avoid file-level copying, which stalls at the first slow area.
Take it out of use — call Easy Data Recovery on 028 9002 0144; figures read as time awaiting completion, addressed through hardware with imposed timeouts, responsive regions taken first.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.