USB-C to USB-A Adapter Test: Fast Reads, Slow Writes on the Same SSD

A USB-C to USB-A adapter can pass a benchmark while quietly capping your backups: on the tested mini PC, the same external SSD read at 539.1 MiB/s through a USB-C to USB-A adapter but wrote at only 39.23-39.66 MiB/s, while the identical drive and cable wrote at 288.97-298.91 MiB/s through a native front USB-A port. Every transfer was verified with SHA-256, so the gap is real throughput, not a caching artifact. If you judge an adapter by read speed alone, you will miss exactly this failure mode.

This page documents the full test: the equipment, the three measurements, the size-matched control, and where the adapter result sits next to the same unit’s four USB-A port map published earlier. All raw files are in the public EQi12 measurement data repository under CC BY 4.0, so you can re-derive every number in the tables below.

Where the numbers come from

The test machine is a Beelink EQi12 (Intel i3-1215U, 16 GB DDR4-3200, WD PC SN540 512 GB NVMe) running Windows. The storage target was one EAGET 1 TB external SSD with its original USB-A cable, used for every measurement on this page and for the site’s four-port USB comparison. The adapter path connected the EQi12’s USB-C port to a USB-C-to-USB-A adapter, then to the SSD’s original USB-A cable. The cable on the adapter was labeled 3A (a current rating), with no published data-rate specification.

Test conditions, 2026-07-12 (source files: EQi12_USB-C转USB-A转接头性能定位结论.txt, EQi12_USB-C_SSD_4GiB_Result.txt, EQi12_USB-C_vs_FrontUSB-A_1GiB_Control.txt in the repository):

• Payload files written by a deterministic generator, so every read-back has a known SHA-256 to compare against.
• Write timing uses copy-call time plus a forced durable flush (0.118 s in the flush-inclusive totals), so cached-but-uncommitted writes do not inflate the numbers.
• The SSD was idle before each test, and the 1 GiB retest ran after the drive had gone idle again, which rules out a hot SLC cache carrying one result.

One boundary statement up front: this is one adapter, one cable, one SSD enclosure on one Windows mini PC. The results show that this combo behaves asymmetrically; they do not prove that every USB-C to USB-A adapter caps writes. The honest-limits section at the end lists exactly what would need retesting to generalize.

Test 1: the read path through the adapter was genuinely fast

A full 4 GiB deterministic test file was read back through the adapter path and hashed on the fly:

A 539.1 MiB/s read is above what the same SSD’s native USB-A paths delivered on this unit (431.8-432.1 MiB/s unbuffered read-back in the 50 GiB four-port test). On read throughput alone, this adapter path looks excellent — which is precisely the trap.

Test 2: the write path through the same adapter sat near 39 MiB/s

Writes through the identical adapter combo told a different story:

Three details make this result trustworthy rather than a fluke:

1. The 4 GiB payload cannot hide in RAM cache, so the rate is sustained writing, not a cache sprint.
2. The 1 GiB retest ran after the drive went idle, and it reproduced the same ~39.5 MiB/s ceiling — a hot-cache effect would have faded by then, not persisted.
3. Flush-inclusive and copy-call timings agree within 0.5%, so the bottleneck is not an accounting artifact of the flush.

Test 3: the size-matched control that convicts the adapter

A slow write could be the SSD’s own garbage collection rather than the adapter. The control test settles it — the same SSD, on the same day, through the front USB-A port with its original cable, writing the same 1 GiB payload:

The same drive recovered roughly 299 MiB/s writes the moment it left the adapter path. That single row is why the conclusion reads “the adapter combo has a one-directional write anomaly” instead of “the SSD slowed down.” NAND cache exhaustion or garbage collection on the drive cannot explain a rate that recovers instantly when the path changes.

The same unit’s full USB speed map, for context

This adapter result is easier to interpret next to everything else measured on this machine with the same SSD and cable. The four-port 50 GiB comparison established the native USB-A picture, and a 3-round retest confirmed the slow port is stable, not intermittent:

Two paths on this unit land near 39-40 MiB/s writes for completely different reasons: the slow rear USB-A port is symmetric (reads and writes both fall to USB 2.0-class rates, consistent with link negotiation — the diagnostic method covers how to isolate that case), while the adapter path is asymmetric, reading above 500 MiB/s and writing below 40. Same symptom number, different failure mechanism — which is why a single speed number never identifies the faulty component.

Why read-only benchmarks miss this failure mode

Most quick adapter reviews — and most marketplace listings — quote read speeds, because reads are easy, fast to demonstrate and produce impressive numbers. For a media-drive use case (load files onto a player, stream from the drive), reads are also the right metric.

For a home-server backup target, the write path is the one that matters, and it is exactly where this adapter failed. A nightly backup pushing 50 GiB through this combo would take about 22 minutes of pure copy time at 39 MiB/s; through the front USB-A port it took under 3 minutes in the equivalent sustained test (301.51 MiB/s over 50 GiB). The adapter does not fail gracefully with an error message; it just quietly runs at one-eighth of the speed the read benchmark promised.

The practical rule this test supports: evaluate a storage path by its sustained write rate with hash verification, at a size larger than your RAM. Reads can stay fast through a component that throttles writes, so a read-only CrystalDiskMark screenshot cannot clear an adapter for backup duty.

What this test does not prove

The honest limits, explicitly:

• The native USB-C write capability of the EQi12 remains untested. The tested combo routes through an adapter and an A-to-C chain, so the anomaly could sit in the adapter, the adapter-to-cable junction, or the enclosure’s bridge chip renegotiating through it. A native USB-C high-speed SSD or a second, spec-rated USB 3.x C-to-A adapter would be needed for a final verdict on the port itself.
• The cable’s data rating is unknown. The 3A label is a current rating, not a data-rate certification. An under-specified cable is a live suspect in the write path.
• One SSD, one enclosure, one Windows machine. No Linux numbers, no other adapters, no other enclosures. Nothing here extrapolates to “adapters are slow” as a category — only that this combo, on this unit, wrote at one-eighth of its read rate.
• No data-integrity failure was observed. Every hash matched, including the 4 GiB read-back. Asymmetric throughput is a performance finding, not a corruption finding.

How to test your own adapter in 15 minutes

The minimal version of the method used here:

1. Generate or pick a deterministic test file at 4 GiB or larger (larger than RAM cache), and record its SHA-256.
2. Copy it to the SSD through the adapter path; note wall-clock time and hash the copy.
3. Copy it back and verify the hash again.
4. Repeat steps 2-3 through a native USB-A port with the same drive and cable.
5. Compare flush-inclusive write rates. If reads pass 400 MiB/s while writes sit near 40 MiB/s, you have reproduced the asymmetric pattern.

The full version, including port mapping, link-negotiation checks and a component-isolation matrix, is documented step by step in the USB SSD 40 MB/s diagnostic guide. For planning how long backups take at whatever rate your hardware achieves, the network transfer-time calculator accepts your measured rate directly.

Citable fact block

Measurement conditions: 2026-07-12, Windows, EAGET 1 TB SSD with original USB-A cable, deterministic payloads, SHA-256 verified, durable-flush timing included.