Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Loco Sock

macrumors member
Original poster
**[Beta] DiskTruth — F_NOCACHE Mac disk benchmark with SLC cliff detection, negotiated interface speed, and cryptographically signed leaderboard**

Hello — I've been building a disk benchmark for Apple Silicon Macs and I'm opening up the TestFlight beta. I wanted to post here because this community tends to care about methodology, and there's a real methodology story behind this one.

---

**The problem with existing benchmarks**

BlackMagic Disk Speed Test is the standard, but it doesn't use `F_NOCACHE`. macOS maintains a unified buffer cache in RAM, and without explicitly bypassing it, a significant portion of reads on a high-memory Mac are served from memory rather than the drive. Write results can also be affected because the OS batches writes through its page cache. The result is that benchmark numbers on a 64 GB Mac look noticeably better than the same drive on a 16 GB Mac — not because the drive is faster, but because more of the test data fits in RAM.

AmorphousDiskMark is more capable than BlackMagic but also doesn't use `F_NOCACHE` and hasn't been updated since 2022.

---

**DiskTruth's approach**

`fcntl(fd, F_NOCACHE, 1)` is set on every file descriptor before any I/O. Write buffers are populated with `arc4random_buf` — random data prevents hardware compression from inflating write throughput on drives that implement it. Standard mode uses a fixed 16 GB test file across 3 iterations, reporting the median.

---

**What it measures**

*Sequential read/write (MB/s)* — per-chunk throughput recorded for every 64 MB segment during write. Live graph updates in real time.

*SLC cliff detection* — when per-chunk throughput drops more than 20% sustained, a cliff event is recorded and marked on the graph. The reported write speed is the honest median across all three full iterations, including post-cliff performance. This is the number that represents what the drive actually does under sustained load — not just the fast cached phase.

*Random 4K IOPS + latency* — 10,000 operations per pass at QD1. Per-op latency tracked; average and p99 reported. p99 is the number that reveals controller consistency.

*Queue depth scaling* — QD1, QD4, QD16, QD32 (3,000 ops per level). Apple Silicon internal NVMe has a notably different QD scaling profile vs desktop NVMe — extraordinary QD1 latency, less dramatic scaling at higher depths. Worth seeing on your own hardware.

*Negotiated interface speed* — reads from IORegistry, not from the port label. Shows actual Thunderbolt or USB4 link speed for your specific port + cable + enclosure combination. I've found this surprisingly useful — a TB4 enclosure with a third-party cable will sometimes negotiate at USB 3.2 speeds without any obvious indication.

*Speed Doctor* — a layered diagnostic (Cmd+Shift+D) that walks through: interface negotiation → thermal state → system background load → firmware check → drive eject for cable reseat.

---

**Leaderboard and result integrity**

Standard mode results can be submitted to a community leaderboard. The result payload is P256-signed at benchmark time — the signature covers numbers, drive info, Mac model, test configuration, and integrity fields. The server verifies the signature, checks Isolation Mode was active, deduplicates by device+drive, and scores result integrity. Results that pass get a Verified badge. The signed result card PNG includes a QR code linking to the live verification page — useful for forum posts when someone questions your numbers.

Isolation Mode (required for Standard): suppresses notification banners, prevents App Nap, raises scheduler priority, blocks display/system sleep. Keeps conditions consistent across submissions.

---

**Beta priorities**

I have decent coverage of M1/M2 internal drives but I'm thin on:
- M5 (MacBook Pro M5, MacBook Air M5 — any SSD tier)
- Thunderbolt 5 enclosures (requires M4 Pro/Max or M5 Pro/Max)
- USB4 Gen 3×2 (40 Gb/s) enclosures
- Mac Pro M2 Ultra with PCIe NVMe expansion
- Any unusually large internal SSD (4 TB, 8 TB)

All Apple Silicon Macs on macOS 13 Ventura or later are welcome.

---

**Links**
- Site + leaderboard: https://disktruth.com
- Beta signup: https://disktruth.com/beta
- Methodology / glossary: https://disktruth.com/learn
- Privacy policy: https://disktruth.com/privacy

Happy to answer questions about the F_NOCACHE implementation, the signing scheme, SLC detection logic, or anything else.
 
**The problem with existing benchmarks**

BlackMagic Disk Speed Test is the standard, but it doesn't use `F_NOCACHE`. macOS maintains a unified buffer cache in RAM, and without explicitly bypassing it, a significant portion of reads on a high-memory Mac are served from memory rather than the drive. Write results can also be affected because the OS batches writes through its page cache. The result is that benchmark numbers on a 64 GB Mac look noticeably better than the same drive on a 16 GB Mac — not because the drive is faster, but because more of the test data fits in RAM.

AmorphousDiskMark is more capable than BlackMagic but also doesn't use `F_NOCACHE` and hasn't been updated since 2022.

All Apple Silicon Macs on macOS 13 Ventura or later are welcome.

Hi Loco Sock, appreciate the rigorous approach to measuring real I/O performance.

QQ: why only Apple Silicon and why is macOS 13+ required?

There are two limitations this presents:
-I would like to benchmark my Intel Macs (I still have two I am fond of) and especially compare them with more recent Macs (e.g. Intel MacBook Air Intel versus Apple Silicon MacBook Air)
-I like to measure how real I/O subsystem performance changes (or not) over time with different OS -- Mojave versus Catalina versus Monterey versus Sonoma versus Sequoia

If it would be possible to relax those requirements that would be great.
 
**The problem with existing benchmarks**

BlackMagic Disk Speed Test is the standard, but it doesn't use `F_NOCACHE`. macOS maintains a unified buffer cache in RAM, and without explicitly bypassing it, a significant portion of reads on a high-memory Mac are served from memory rather than the drive. Write results can also be affected because the OS batches writes through its page cache. The result is that benchmark numbers on a 64 GB Mac look noticeably better than the same drive on a 16 GB Mac — not because the drive is faster, but because more of the test data fits in RAM.

AmorphousDiskMark is more capable than BlackMagic but also doesn't use `F_NOCACHE` and hasn't been updated since 2022.
Do you have any evidence for this whatsoever? Whenever I've used either of those two, they've always reported speeds consistent with what I'd expect, and not consistent with memory speeds. For a SATA SSD, I get speeds below 500MB/s, and for an external HDD I get speeds around 200MB/s. If it were cached, I'd expect speeds in the gigabyte range.
 
Hi Loco Sock, appreciate the rigorous approach to measuring real I/O performance.

QQ: why only Apple Silicon and why is macOS 13+ required?

There are two limitations this presents:
-I would like to benchmark my Intel Macs (I still have two I am fond of) and especially compare them with more recent Macs (e.g. Intel MacBook Air Intel versus Apple Silicon MacBook Air)
-I like to measure how real I/O subsystem performance changes (or not) over time with different OS -- Mojave versus Catalina versus Monterey versus Sonoma versus Sequoia

If it would be possible to relax those requirements that would be great.

Thanks for the kind words and the great questions, these are exactly the right things to ask.

Why Apple Silicon only:

The short answer is IOKit. DiskTruth reads negotiated interface speed, drive firmware, enclosure vendor/product IDs, and controller details directly from the IORegistry. The IOKit APIs that expose this information behave very differently on Intel Macs. Many of the registry paths and property keys that work reliably on Apple Silicon either don't exist, return different structures, or require different traversal logic on Intel. Getting accurate interface detection (the difference between "Thunderbolt 3" and "USB 3.2 masquerading as TB3") on Intel would essentially be a separate implementation. It's on the roadmap but not v1.

Why macOS 13 Ventura minimum:

SwiftUI APIs. Several of the UI components, particularly the live throughput graph built with Swift Charts, require macOS 13. Swift Charts alone was introduced in macOS 12, but the specific chart modifiers and data series APIs used in DiskTruth require 13. Dropping to macOS 12 would mean rewriting the graph with a custom Core Graphics implementation. Dropping to macOS 11 or below would mean losing SwiftUI features used throughout the app. macOS 10.x and Intel-era OS versions would require a near-complete rewrite in AppKit.

The honest answer on Mojave/Catalina:

Those releases predate Swift Charts, predate many SwiftUI APIs, and on the IOKit side the storage subsystem changed significantly with Apple Silicon. A version of DiskTruth that ran on Mojave would share almost nothing with the current codebase. It would be a different app. The benchmark methodology (F_NOCACHE, arc4random_buf, CLOCK_MONOTONIC_RAW timing) would carry over, but everything else would need rebuilding from scratch.

The Intel comparison use case:

This is genuinely interesting and I understand why you want it. Intel vs Apple Silicon internal NVMe is a fascinating comparison, especially SSD controller behavior and QD scaling profiles. I'm keeping Intel support on the list. If and when it lands it would likely ship as a separate legacy build with reduced interface detection rather than trying to unify everything.

Thanks again for the detailed feedback. This is exactly the kind of input that shapes what gets built next.
 
Last edited:
Do you have any evidence for this whatsoever? Whenever I've used either of those two, they've always reported speeds consistent with what I'd expect, and not consistent with memory speeds. For a SATA SSD, I get speeds below 500MB/s, and for an external HDD I get speeds around 200MB/s. If it were cached, I'd expect speeds in the gigabyte range.

You're raising a fair point, and you're right that for slow storage (SATA SSDs and HDDs) the cache effect is minimal or nonexistent. Those drives can't saturate memory bandwidth so the numbers stay honest regardless.

Where it matters is fast NVMe, especially on high-RAM Apple Silicon Macs. Here's the scenario: a 16 GB test file on a Mac with 64 GB of RAM. On the first pass, data gets loaded into the unified buffer cache. On subsequent passes (which most benchmarks run to get "consistent" numbers) reads are increasingly served from RAM rather than the drive. Apple Silicon's unified memory architecture is exceptionally fast, and the buffer cache is large enough to hold the entire test file comfortably.

The result is that repeat-run benchmarks on fast NVMe and high-RAM Macs report inflated read speeds that reflect memory bandwidth, not drive throughput. You won't see this on a SATA SSD or HDD. You will see it on a Samsung 990 Pro or Apple's internal NVMe on a Mac Studio with 64+ GB RAM.

This isn't a theoretical concern, it's measurable. Run BlackMagic on a fast NVMe Mac, note the read speed on run 1, then run it again immediately without clearing caches. The second run will be faster. With F_NOCACHE active, both runs return the same number because the cache is bypassed entirely.

DiskTruth exists specifically for that class of hardware. For SATA and HDD the difference is negligible and you're right that it doesn't matter much. For fast NVMe on Apple Silicon, it does.
 
You're raising a fair point, and you're right that for slow storage (SATA SSDs and HDDs) the cache effect is minimal or nonexistent. Those drives can't saturate memory bandwidth so the numbers stay honest regardless.
No, the opposite is true, and your second sentence makes zero sense whatsoever. Your AI is hallucinating garbage. If you're just going to copy and paste AI responses to me, I am going to block you.
 
No, the opposite is true, and your second sentence makes zero sense whatsoever. Your AI is hallucinating garbage. If you're just going to copy and paste AI responses to me, I am going to block you.
The sentence was poorly worded and the logic doesn't follow. What I should have said is this: on a slow drive, the difference between cached and uncached reads is small because the drive itself is the bottleneck regardless. The cache effect isn't absent, it's just less consequential at those speeds. On a fast NVMe drive, where the drive can approach memory bandwidth territory, the gap between a cached and uncached benchmark becomes significant and misleading. That's the actual argument, and I wrote it sloppily. Fair criticism.

It's a benchmark, it's not going to alter anything.
 
Thanks for the kind words and the great questions, these are exactly the right things to ask.

Why Apple Silicon only:

Why macOS 13 Ventura minimum:

The honest answer on Mojave/Catalina:

Thanks again for the detailed feedback. This is exactly the kind of input that shapes what gets built next.

Hi Loco Sock, really appreciate the detailed explanation and reasoning behind these requirements. I guess behind a mostly similar UI/UX and a lot of forward compatibility, I now understand there's been a lot more behind-the-scenes and infrastructure changes in macOS over the years that challenge making a single code base for a tool like this. When you mentioned fcntl(F_NOCACHE...) I was thinking it was mostly UNIX/C code at its heart all wrapped in Cocoa, etc.

One other option might be a CLI version of the benchmark code. The signatures, QR code, isolation mode, etc options would be outside the tool but one could still run tests for personal use.
 
One other option might be a CLI version of the benchmark code. The signatures, QR code, isolation mode, etc options would be outside the tool but one could still run tests for personal use.

A CLI version is totally doable and would be for personal use (DiskTruth is a personal use tool, sharing the results is totally optional). I did some digging and could probably turn out a CLI tool that would be compatible with Big Sur and newer. I could at least sign the binary with a dev certificate, but that won't stop people intent on tampering. The results would be text anyway so there's that. But I'm thinking of all the checks we do in DiskTruth that inflating numbers would be very difficult and I don't think it's much of an issue anyway if it's just personal use.

Thank you for the idea, if I get a CLI version of it out, you'll have top billing 🙂

Edit: Ok, since the original reply, I've spec'ed out a CLI version. It will have a couple of options from the App and the numbers should be very comparable between the two (firmware check, standard/extended testing, output to terminal, json, cvs and an interactive option).
 
Last edited:
  • Love
Reactions: bzgnyc2
How can the drive be the bottleneck for cached reads where the drive is not even involved?
Cached reads return data from RAM and the drive isn't accessed at all. So drive speed can't be the bottleneck for something the drive isn't doing. The whole point of F_NOCACHE is to bypass that cache so you're measuring the actual drive, not your RAM.
 
The latest Beta just went live, here's What's New:

- Drive capacity now shown alongside model name (e.g. "APPLE SSD AP0256Q · 256 GB")
- USB enclosure controller chip identified and displayed (e.g. "Realtek RTL9210", "ASMedia ASM2464PD")
- Results table text larger and easier to read
- QR code on result card now labeled "Scan to view on leaderboard"
- Leaderboard link added to Help menu (⌘⇧L)
- Fixed: free space pre-flight warning now shows used percentage for context

Website updates: OS version now visible on leaderboard, enclosure chipset shown on result pages, similar results section added to each result page.
 
Build 13 is out on TestFlight with some meaningful updates. Drive health data (TBW and power-on hours) is now captured at benchmark time for NVMe drives. OS beta and OCLP results are now labeled on result pages for context when comparing. Also fixed a progress bar bug during 4K and queue depth phases, ETA now recalculates correctly through all phases, and benchmark folders are automatically cleaned up after a run.
 
  • Like
Reactions: bzgnyc2
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.