Comparing the performance of modern high-speed SSDs isn’t easy, and if you think it should be straightforward, I challenge you with some results here, for a couple of Macs. I’m referring to an iMac Pro, which has its internal disk controller within the T2 SoC, and a shiny new M1 Mac mini. Although my focus of attention is comparing their internal SSDs, I’ll also compare them against a couple of external SSDs for reference.

My measurements are made using a new release of my benchmarking utility Stibium. This now incorporates two different read tests, and runs sequences of both read and write measurements, making it considerably more useful.

As Ric Ford and others have pointed out, one of the big problems with trying to measure the performance of storage is caching. When you write data to a disk, it’s normally fed to cache memory and written from there. Although you can ask the system to pause until the write is complete, there are no guarantees that it might not cheat.

At first sight, caching read data shouldn’t have any effect: ask the system to give your app the contents of a file, and until your app has that data in memory, there’s little that a cache could do. Except that, if you’ve only just written that data to the file (or read it), it could cheat and, instead of bothering to read the data from the disk, it could just copy the data from memory.

If you’ve ever written code for macOS, you’ll be aware of its tendency to cache information for surprisingly long periods: it’s a problem I’ve encountered when SilentKnight or LockRattler install a security update. When those apps try to check on the new version, macOS returns information which it has cached for the original file. In the end, I’ve worked around this by using a different method of checking versions on the second occasion.

There are several ways to work around read caching. Most storage benchmarks resort to low-level system calls which should bypass caching. But some of the odd, and sometimes seemingly impossible, performance results from other benchmarking apps suggest that often doesn’t work. As Ric Ford kindly pointed out in some of Apple’s old documentation, there is one high-level read call which has an option which disables read caching. I’ve therefore incoporated that as an alternative in Stibium. The other technique which is more generally useful is to flush the cache by reading other files before you come to read data which have been recently written. Stibium tries to do that too.

The app has grown a second row of controls, over Series tests. For the moment, the test sequences are coded into the app, but in a future version you’ll be able to import and choose your own tests. Following earlier testing on single files, this version of Stibium reads and writes a sequence of files of sizes:
10, 100, 500 KB, 1, 5, 10, 50, 100, 200, 400, 600, 800 MB, 1, 2 GB

It also automatically analyses results, calculating transfer speeds, and providing a verbose output which details every test, and summary results giving average, median and the range of results. As results don’t appear normally distributed, in the following I’ll refer to the medians and range.

Running these series tests on the Data volume, which is on the internal SSD, the M1 is consistently faster at both reading and writing files. Writing, the M1 achieved 3.3 GB/s (0.8-3.9), and the T2 3.0 GB/s (0.4-3.3). Results from reading are harder to interpret: using the uncached method, the T2 turned in a healthy 3.7 GB/s (0.1-6.9), but the M1 was far higher at 7.5 GB/s (0.3-8.2).

From those, it appears that, even using ‘uncached’ reads, the M1 is caching files when writing them, and reading them from that memory later. To test that, I performed further read tests using Stibium.

When you run a series write test using this new version of Stibium, it writes its test files to a folder of your choice. The read test works in reverse, and simply times how long it takes to read every file in any chosen folder. You can therefore read corresponding test files on very separate occasions, and get comparable results. I next ran the read tests again after quitting Stibium, then logging out and back in. Although the median speed fell to below that of the T2, at 2.9 GB/s, there were still two very high results, with a maximum of 8.4 GB/s. I next restarted the M1 Mac mini and repeated the test again with essentially unchanged results, a median of 2.9 GB/s with a maximum of 7.6 GB/s.

If the M1 and Big Sur are caching reads to produce rates over 5 GB/s, they can’t be caching them to memory!

I then ran read tests on a folder which hadn’t been written for many days: the /bin folder on the Sealed System Volume. This in itself is interesting, as it provides an idea of performance on some of the most heavily used files in Big Sur. As these are generally smaller than most of my test files, read rates were slow, at 0.5 GB/s on the M1 Mac, and 0.1 GB/s on the T2. Maximum rates were, though, just as high as on the files which Stibium had written: 7.0 GB/s on the M1, and 4.4 GB/s on the T2.

If you feel that you can explain these very high transfer rates, I’d love to learn how my M1 Mac mini is achieving them without breaking the laws of physics.

Finally, a short look at two different types of external SSD on the M1 Mac mini. The two under test are my expensive and underused Samsung X5 500 GB on Thunderbolt 3, and a Samsung 860 EVO 1 TB in a no-name SATA/USB-C enclosure (because I’m too cheap to buy a Samsung T5). Several sources have stressed the performance benefits of the X5 only when working with very large files. As the largest of my test files is only 2 GB, and the majority are in the MB range, I hope these results give a more accurate reflection of the disks in everyday use.

When writing, the SATA disk performed much as expected, with a median transfer rate of 0.4 GB/s (0.02-0.4). Except at some of the smallest file sizes, the X5 was consistently quicker, with a median of 1.9 GB/s (0.005-2.1). That makes the X5 more than four times the speed of a conventional SATA SSD.

The gap in performance is similar for reading: the SATA turned in a median rate of 0.5 GB/s (0.4-8.0), and the X5 2.5 GB/s (0.5-8.0). And there’s my problem: if I almost convinced you that those very high read speeds from the M1’s internal SSD might be real, how can they be achieved over a SATA 6.0 Gbps interface?

Stibium version 1.0b4 is now available from here: stibium10b4
I now have two areas in which I intend making further progress in the coming weeks: improving the breadth and depth of data analysis, and opening it up for you to run your own bespoke test regimes, including random sequences. Maybe we’ll also get a better understanding of how read rates can be so high.