USB Flash Module Endurance: MLC vs TLC for Frequent-Rewrite Applications

TL;DR

For a USB flash module that is rewritten constantly — data loggers, kiosk config stores, POS terminals, industrial controllers — the cell type is only one term in the endurance equation:

bytes the module can absorb = P/E cycles × die capacity ÷ write amplification

Three things move that number more than the MLC/TLC label: write amplification (random small writes and frequent flushes can push it from ~1.2× to 5–10×), capacity (a bigger die spreads the same host writes over more cells), and host write discipline.

The counter-intuitive part

MLC gives more erase cycles per cell than TLC in the same process generation, which sounds decisive. It usually is not.

A well-managed 16 GB TLC module commonly outlasts a small badly-written MLC module by a factor of ten — not because TLC is better, but because the larger die and the lower write amplification do more work than the cell type. Conversely, a small MLC module with WAF pushed to 6 loses to almost anything.

The right question is therefore not “MLC or TLC” but “what is my daily write volume, what WAF will the controller see, and what will the supplier commit to in writing?”

Write amplification is the term you actually control

WAF is flash bytes written per host byte. It rises when:

• Writes are small and random. A 4 KB random write can trigger a whole-block erase-and-rewrite cycle.
• The host flushes constantly. Every fsync on a log file costs a metadata update as well as the data.
• The filesystem writes in place. Log-structured or append-only layouts keep WAF near 1.
• The device is nearly full. Free space is what the controller uses to relocate data; below about 20% free, WAF climbs steeply.

Practical fixes that cost nothing: write append-only, batch and flush on a timer rather than per record, keep 20–30% of the volume free, and align writes to the erase block size when the driver allows it.

What to ask a supplier

Do not ask “is this MLC or TLC” and stop there. Ask these four, and get the answers in writing:

1. Rated P/E cycles for the die actually used in this build, not the generic family number.
2. The controller’s wear-levelling and WAF behaviour under the workload you describe — random or sequential, record size, flush cadence.
3. What endurance figure the supplier will commit to for your project, given your daily write volume. If nobody will put a number in the quote, the number does not exist.
4. Lot traceability, so that if a batch behaves differently in the field you can identify it.

WINTEL does not publish a generic endurance rating for modules. Endurance is quoted per project, after the workload is specified, because a single headline number would be wrong for almost every customer.

The test that settles it

Before a production run, ask for samples from the lot and run your own workload for the equivalent of a few months of field life — compressed by writing at maximum rate rather than waiting. Log bytes written, watch for the first bad blocks, and compare against the supplier’s committed number. Two weeks of accelerated testing is cheaper than a field recall, and it is the only evidence that the arithmetic above holds for the part you actually received.

If the module is going into a device that also has to survive power loss, test the two together — a badly timed cut during a garbage-collection cycle is where endurance problems and corruption problems meet.