The Surface Pro 11 SSD was oddly slow only for 256MB writes

The internal SSD in the Surface Pro 11, an SDDPTQD-1T00-1124-WD, measured 348MB/s for a 64MB write and 197MB/s for a 256MB write.

Making the size larger made only the write slower. Reads rose from 682MB/s at 64MB to 1073MB/s at 256MB, which fits the simple expectation that larger sequential access is faster. Writes went the other way. I suspected a script bug when I saw it, but runs_ms showed that all three 256MB writes were in the one-second range. Reads and writes showed very different faces.

The test target was a Microsoft Surface Pro, 11th Edition, with a Snapdragon X 12-core X1E80100 @ 3.40GHz, 32GB of memory, and Windows 11 Pro 10.0.26200 ARM64. I ran the measurement at 20:17 on 2026-06-06 and used only that run. The target was the internal SSD, not an external drive.

A deliberately heavy write that waits for fsync

These numbers are not the same kind of measurement as checking catalog specifications in several GB/s. I opened the write file with buffering=0, then called os.fsync() after writing and flushed every time. Rather than letting the OS or drive cache absorb the work comfortably, I made it wait in a more operationally realistic way. I am stating this condition up front so the 197MB/s number does not take on a life of its own.

The script had a structure like this.

with open(path, "wb", buffering=0) as f:
    f.write(data)
    os.fsync(f.fileno())

with open(path, "rb", buffering=0) as f:
    f.read()

I ran 64MB and 256MB three times each. For small files, I created 2,000 files of 512 bytes and deleted them through the same flow. There were few repetitions. Three runs are not enough to call this a stable benchmark, so it is safer to read it as “this is how it looked here.” More runs would be needed to examine reproducibility.

Putting sequential I/O and small files side by side

The medians look orderly, so I am keeping every run as well. runs_ms and median_ms are in milliseconds; MB/s is the calculated value recorded in the JSON.

The 64MB write had a median of 183.87ms, and the 256MB write had a median of 1300.30ms. The data amount is four times larger, but elapsed time grew by about 7.1x. It follows that the calculated MB/s falls from 348 to 197. Reads went from 93.86ms to 238.50ms, only about 2.5x for four times the data, so the calculated speed rises from 682MB/s to 1073MB/s.

Only the 256MB write was sluggish

The most useful anomaly was that only the 256MB write was sluggish. For 64MB, the fastest of three was 152.37ms and the slowest was 260.43ms, about a 1.7x ratio. The 256MB writes ranged from 1250.54ms to 1452.99ms, shrinking the ratio to about 1.2x. It looked less like random variation and more like a stable stay in a slower bandwidth range.

I will not assert the reason. Because buffering=0 and os.fsync() force a wait every time, it is possible that the cache or internal write handling saturated during the 256MB sequential write. That is as far as I will go. I did not inspect SMART, temperature, or controller internals, so calling it “the cache running out” would add an unmeasured claim.

The read side moved in the opposite way. The 256MB reads were 223.91ms, 238.50ms, and 245.65ms, tightly grouped, with about a 1.1x fastest-to-slowest ratio. Larger sequential reads may have suited the drive and OS better. That too remains a hypothesis.

Small files are a different event

The test that created and deleted 2,000 512-byte files had a median of 1259.13ms and 1588 files/s. Per file, that is about 0.63ms. The number may feel fast, but each operation handles only 512 bytes, so it is a different event from 64MB or 256MB sequential I/O.

The reason node_modules and .git can feel slow is close to accumulating this 0.63ms. Even with a tiny file body, creation, directory-entry updates, deletion, and synchronization waits happen one file at a time. Two thousand files finish in around 1.26 seconds, but the wait becomes noticeable as the count grows. The experience of reading one large file at 682MB/s or 1073MB/s does not map cleanly to it, even on the same SSD.

This difference felt convincing to me. It is not a simple “ARM64 is slow” or “NVMe is fast” story; changing the access pattern changes what the Surface Pro 11 internal SSD looks like. That was the interesting part of this run.

I will not call the SSD slow yet

The most dangerous misunderstanding this time was almost seeing 197MB/s for the 256MB write and saying “the SSD is slow.” In reality, that number came from a measurement that forced a flush, and it should be treated separately from ordinary copying or application startup. Mixing the conditions would make the whole article wrong because the kinds of waiting being measured differ.

There were only three repetitions. Looking at the fastest-to-slowest ratios, 64MB reads moved by about 1.6x, 64MB writes by about 1.7x, and small_files by about 1.4x. The 256MB read was about 1.1x and the 256MB write about 1.2x, relatively stable, but this is still not enough to establish a trend.

Next time I would add sizes between 64MB and 256MB. Inserting 128MB should show a little more clearly where write speed starts to fall. A separate measurement with and without fsync is also needed. I intentionally kept the heavy condition this time because I wanted to get closer to the waits experienced with node_modules and .git.

A yardstick for development work

After seeing these results, I stopped judging an SSD only by the copy speed of a huge sequential file. The Surface Pro 11 internal SSD reached 1073MB/s for a 256MB sequential read, while a 256MB write with flushing fell to 197MB/s. Both are faces of the same drive.

Small files may matter more for development work: package extraction, Git checkout, and cache creation and deletion. Those operations touch huge numbers of 512-byte or few-KB files. The 1259.13ms for 2,000 files is a yardstick for remembering that wait.

If I have to rush to a conclusion: larger reads improved, larger writes with flushing fell, and small files were about 0.63ms each, a separate category from sequential MB/s. More runs are needed before making a firm claim, but the loose expectation that “NVMe makes everything fast” was wrong. Even this one run on June 6, 2026 established that much.