KNOWLEDGE — Kalstor KNOWLEDGE K KALSTOR
HomeResourcesSLC cache explained: burst vs sustained flash write speed
Knowledge · Flash performance

SLC cache explained: burst vs sustained flash write speed

By Kalstor 8 min read
Key takeaways
  • Burst speed is the fast initial phase; sustained speed is what remains during a transfer longer than the device cache and background cleanup can absorb.
  • An SLC-mode write buffer can accelerate TLC or QLC storage, but its capacity is finite. When it fills or flushes to the main NAND area, write speed may fall sharply.
  • The interface label is only a ceiling. NAND, controller, firmware, thermal limits, source speed, file mix, free space and cache state can all become the real bottleneck.
  • For procurement, require a time-versus-throughput curve and test-file size—not only one “up to” number. Qualify the worst capacity and the actual workload.

A new SSD or USB flash drive may copy at an impressive rate for the first few seconds, then drop to a fraction of that speed during the same file. Repeating the test after a rest may bring the fast start back. That pattern is often the difference between burst and sustained write performance—not evidence that the USB logo changed mid-transfer.

For a buyer, the important question is not “What is the maximum speed?” It is “How much data can it write at each speed, under our workload?”

Burst and sustained speed answer different questions

Burst write speed describes a short interval while fast buffers and empty NAND resources are available. Sustained write speed is the rate the device can maintain after those temporary advantages are consumed and background work reaches equilibrium.

A 1GB benchmark can fit inside a cache. A 200GB video ingest, disk image or production-programming job may not. Both numbers can be accurate while describing very different user experiences.

Report performance as a curve:

  1. initial peak;
  2. amount of data written before the first drop;
  3. post-cache plateau and variability;
  4. recovery after idle time;
  5. temperature and fill level throughout the run.

One peak number hides all five.

How an SLC-mode write buffer works

TLC stores three bits per cell and QLC stores four. Some controllers temporarily operate part of that NAND in a one-bit-per-cell mode, creating a faster SLC-mode buffer. Implementations vary: the area may be fixed, dynamic, host-managed or absent.

KIOXIA's UFS WriteBooster brief provides a clear managed-flash example. Data first enters a finite SLC write buffer. When the buffer fills, writes go to the TLC user area and performance is reduced; the controller later flushes buffered data, often during idle or hibernate time [1]. Micron likewise describes Dynamic Write Acceleration as enabling burst writes in a client NVMe SSD [2].

The mechanism explains the familiar graph:

PhaseWhat the controller is doingExpected behavior
Fresh/idleAccepting writes into fast bufferHigh initial throughput
Buffer fillingWriting new data and managing spaceSpeed may begin to vary
Buffer fullWriting to main NAND and/or flushingLower sustained plateau
Idle recoveryMoving buffered data and cleaning blocksNext burst may recover

Do not assume every product uses the same cache size or policy. Two drives with the same capacity and interface can behave very differently.

The interface is a ceiling, not a promise

USB and PCIe link rates measure bits on the bus. Application throughput is lower because of protocol overhead and because the storage behind the link may be slower. Crucial notes that an older port, enclosure, adapter, cable or shared USB controller can limit attached storage; multiple devices on one controller divide available bandwidth [4].

Before blaming NAND, confirm:

  • negotiated USB/PCIe generation and lane count;
  • source drive can read faster than the target writes;
  • cable, hub, enclosure and card reader support the intended mode;
  • no other device is saturating the same controller;
  • test data is not being served from host RAM cache;
  • power management and thermal throttling are not changing the run.

Crucial's SSD guidance also points to motherboard lane sharing, firmware, BIOS and controller drivers as common reasons measured performance differs from a headline specification [3].

File mix and free space change the result

One large sequential file is NAND-friendly. Thousands of small files add filesystem metadata and command overhead. Random writes force more mapping and internal movement. Nearly full storage leaves the controller fewer convenient locations for garbage collection.

This is why a product can pass a short sequential benchmark and disappoint when a reseller copies a photo archive. Test the workload that customers actually use:

  • large video files for camera-media ingest;
  • many small documents for promotional USB drives;
  • full-device images for factory programming;
  • mixed random writes for an operating-system or database workload.

For the free-space mechanism, see why an SSD slows down when full. For the underlying cell trade-offs, see SLC, TLC, QLC and pSLC explained.

A procurement test that exposes the cache

For each capacity and approved BOM:

  1. Secure-erase or prepare the device using the agreed procedure.
  2. Record firmware, filesystem, free-space state and ambient temperature.
  3. Use a known-fast source and direct port.
  4. Write incompressible data larger than the expected cache—preferably a meaningful share of capacity.
  5. Log throughput and temperature over time, not only the average.
  6. Repeat when the device is partly filled.
  7. Allow a controlled idle period, then repeat to measure recovery.
  8. Run the real file mix and compare it with the sequential baseline.

The acceptance specification should state at least:

  • minimum sustained write speed after cache;
  • maximum permitted duration below that floor;
  • test size and fill level;
  • ambient and device temperature limits;
  • host, interface and queue settings;
  • firmware and BOM identity.

Qualify the lowest-capacity SKU separately. It may have fewer NAND dies or channels and a smaller dynamic cache than the higher-capacity model.

Bottom line

Peak speed sells the first seconds; sustained speed determines the long job. SLC-mode caching is a legitimate way to accelerate flash, but the buffer is finite and its behavior depends on firmware, fill level and workload. Buyers should ask for the complete throughput curve and a post-cache floor, then verify it on the exact capacity and BOM they plan to sell.

FAQ

Is a flash drive defective if copying starts fast and then slows down?
Not necessarily. The first data may land in an SLC-mode buffer; after that finite area fills, the controller writes to slower main NAND while also flushing cache. A repeatable plateau can be normal architecture. Freezes, I/O errors, disconnects or performance below the agreed sustained floor still require investigation.
Does USB 3.2 guarantee a fast USB flash drive?
No. USB 3.2 describes the interface capability, not the NAND or controller performance. A device can enumerate on a fast bus yet write slowly after cache. Cable, hub, reader, shared controller and source storage can also limit the result.
What benchmark should an OEM buyer request?
Request sequential write throughput over time using a data set larger than the cache, with device capacity, fill level, temperature, filesystem, host, port and test pattern recorded. Add small-file and random-write tests only if the real workload needs them.
Sourcing in volume?

We publish measured usable capacity and welcome trial-batch verification — automotive-grade, direct from the source factory.