Why the head-to-head spec sheet cannot answer the latency question
Most eMMC-versus-UFS comparisons end at one number each: roughly 400 MB/s for an eMMC 5.1 device in HS400 mode, versus a four-figure MB/s class figure for UFS 3.1 and above. That gap is real, but it tells you almost nothing about what a controller waiting on a log flush, a firmware update, or a camera frame buffer will actually experience. Sequential bandwidth describes one long, well-behaved transfer. Mixed workloads describe several short, badly behaved ones arriving at once — and that is where the two interfaces stop behaving like scaled versions of each other.
This comparison sets up a fair, like-for-like test plan for mixed-workload latency, states the assumptions it rests on, and shows where the difference changes a design decision and where it does not.
The architectural difference that makes latency diverge
Both parts are NAND plus an on-package controller. The split is at the interface and command layer:
- eMMC uses an 8-bit parallel bus in half-duplex. A read and a write cannot be in flight together, and command handling is essentially sequential; a command queue mechanism exists in later revisions but is a limited feature rather than the scheduling model.
- UFS uses a serial differential link (MIPI M-PHY based) in full duplex with native multi-queue command handling based on a SCSI command set. Reads and writes can overlap, and the host can keep several commands outstanding.
Consequences for latency follow directly. On eMMC, a write burst blocks the read path for its duration; queuing delay is added on top of service time because there is no place to park the next command. On UFS, a small read can be serviced while a large write is still streaming, and deep queues absorb bursts instead of serialising them. The advantage is therefore load-dependent: it is smallest when the device is doing one thing, and largest when the host mixes small random reads with background writes.
Define the metric before comparing the parts
“Latency” means at least four different things in a procurement conversation. Fix the definitions first, or the numbers will not be comparable:
- Service time — how long one request occupies the device. Closest to a spec-sheet figure, least useful under load.
- Queueing delay — time a request waits behind others. Dominated by queue depth and duplex capability; this is where eMMC and UFS separate most.
- Tail latency — the 99th or 99.9th percentile, not the average. Real-time control loops and UI responsiveness fail on tails, not averages.
- Blocking latency — the worst case experienced by a latency-critical task when a bulk write is in progress. This is the number that decides whether the design meets its deadline.
Report all four. A comparison that only reports averages will make almost any storage look adequate.
A like-for-like test plan
1. Hold everything except the interface constant
Same host platform class, same CPU and memory, same OS image, same filesystem and mount options, same file size and block alignment, same NAND generation and die count where sourcing allows. If the UFS part has more dies or a larger SLC cache, the comparison is measuring capacity and caching, not protocol. Where the two parts differ in raw capacity, keep the tested partition identical.
2. Build a workload matrix, not a single script
- Idle baseline: single-threaded 4K random read and random write, queue depth 1.
- Mixed ratio: read/write blends such as 70/30, 50/50 and 30/70 at fixed queue depths.
- Concurrency: queue depth 1, 4, 16 and beyond, since depth is what UFS's queueing model is designed for.
- Interference case: a small periodic read (a sensor or config lookup) against a sustained multi-gigabyte write.
- Steady state: run long enough to pass the cache and reach the device's sustained behaviour, then report the second half of the run separately.
3. Report the whole distribution
Average, median, p99, p99.9, and maximum, plus IOPS and MB/s at each point. Note the queue depth and the read/write ratio next to every number; a latency figure without them is not reproducible.
4. Instrument the host, not only the drive
Filesystem choice (ext4, F2FS, read-only squashfs with an overlay), write-back caching, dirty-page thresholds and mount options can each move measured application latency by more than the interface difference under light load. Measure at the application boundary as well as the block layer, and record the settings.
5. Control thermal and power state
Run within the intended operating envelope and record device temperature and the power/clock state during each pass. Throttling behaviour differs between parts and can masquerade as a protocol difference.
Reading the results: what actually changes
Expect a pattern rather than a single verdict.
- At queue depth 1, single stream: the gap narrows to the interface rate and controller efficiency. A small eMMC part in HS400 can serve a boot or config read fast enough that the difference is not the design constraint.
- Mixed read and write: the gap widens sharply. On eMMC the read path competes with the write; on UFS it overlaps. This is the case where a modest interface difference becomes an order-of-magnitude difference in perceived responsiveness.
- Tail latency under interference: usually the decisive result. If p99 of the critical read stays inside the control-loop budget with a background write running, the storage is adequate; if it does not, no amount of average throughput compensates.
- Sustained state: once caches are exhausted, both parts converge toward their NAND's sustained write behaviour, and the protocol advantage shrinks for long writes while remaining for concurrency.
State clearly which of these the application depends on. A device that writes a log line every few seconds and reads a config at boot needs almost none of UFS's advantages; a device that records several video streams while serving a web UI needs them.
Assumptions that must be declared
Any comparison of this kind rests on choices that can flip the conclusion. Write them down next to the result:
- Which eMMC revision and mode (for example 5.1 with a high-speed DDR mode) versus which UFS generation and lane configuration. Comparing a mature eMMC part to a current UFS part measures generations as much as interfaces.
- Whether a command queue feature is enabled on the eMMC side, and whether the host driver actually uses it.
- Host controller and driver maturity — an immature UFS driver can erase the protocol advantage entirely.
- Temperature class, endurance rating and the part's declared lifetime, since a stressed part behaves differently near end of life.
- Cost of the whole subsystem, not the memory part alone: UFS typically requires a controller in the SoC, which changes platform choice and therefore total cost.
What does not transfer between the two
Two practical points decide feasibility before performance matters. First, the two are not footprint-compatible: similar ball-grid packages can appear on both sides, but signal definitions and controller requirements differ, so the route is fixed at hardware design time. Second, qualification differs — automotive programmes usually require part-level qualification for the chosen interface, and industrial designs depend on long-term availability of the specific part, which is often easier to secure on eMMC at low capacity.
A decision rule that survives scrutiny
Compare on the metric the product is judged by, under the load the product actually creates:
- If the workload is single-stream, sequential or light, and the critical path is boot plus occasional reads, an eMMC part with a documented industrial temperature range and predictable firmware is usually the lower-risk choice.
- If the workload mixes concurrent reads and writes — recording, serving, updating simultaneously — the latency difference is structural, and choosing UFS is a design decision rather than a performance optimisation.
- If the platform already includes a UFS controller and the capacity is large, the incremental cost of UFS is often smaller than the engineering cost of tuning an eMMC design around its half-duplex limits.
- In every case, publish the test conditions with the conclusion. A latency claim without queue depth, read/write ratio, cache state and temperature is a marketing number, not evidence.
Used this way, the comparison stops being a speed contest and becomes what it should be: a checklist of assumptions and measured tails that tells you which interface your product's timing budget can actually tolerate.