Eyes on Flash/ Driven by Insight
Contact

Search Eyes on Flash

Tip: press / or Ctrl+K on any page to open search.

Type to search.

    Benchmarking 101

    SSD Benchmarking 101, Part 2: Synthetic Benchmark Tools

    Use CrystalDiskMark, ATTO, AS SSD, and other synthetic tools with a clear understanding of their settings, results, and limitations.

    By
    On this page 27 sections

    Part 1 of Benchmarking 101 set the method. Lock down the host, precondition the drive, respect the SLC cache, and know what queue depth, block size and data pattern each do to a result. Part 2 puts that method to work on the synthetic tools most reviewers open first. Each one measures a different slice of drive behavior, and each hides a few settings that move the numbers. This part covers what each of six tools measures and shows, and gives formal test settings for CrystalDiskMark and ATTO. Part 3 then moves on to trace-based and real-world tests.

    What synthetic SSD tools isolate: sequential runs, random blocks and transfer sizeA three-panel cover on a grid of logical blocks. Left: a sequential test reads long runs of blocks in address order. Center: a random test touches small blocks scattered across the grid. Right: a transfer-size sweep, as ATTO runs it, drawn as bars that grow from small blocks to large and then level off. Drawing is schematic.GUIDE / BENCHMARKING 101, PART 2One pattern at a timeSEQUENTIAL · RANDOM · TRANSFER SIZE01 SEQUENTIAL02 RANDOM03 TRANSFER SIZELong runsin address orderthe box-top numberScattered blockssmall reads anywherecloser to daily usesmall to largeClimbs, then levelsthe sweep ATTO runsDrawing is schematic

    Synthetic benchmarks are the controlled laboratory tests of the storage world. They do not replicate real-world usage, and they are not meant to. Their value is precision and repeatability, since they isolate specific performance dimensions so you can compare drives under identical conditions. CrystalDiskMark, ATTO, AS SSD and Anvil form the backbone of consumer storage verification, and every serious review should include all four.

    CrystalDiskMark (CDM)

    CrystalDiskMark 8.0.4 results window with read and write columns in MB/s: sequential 1M Q8T1 reads 13,936.72 and writes 11,781.87, random 4K Q1T1 reads 79.69.

    CrystalDiskMark is the industry standard for what I call “hero numbers.” It is the tool I reach for first to check a spec sheet claim. If a Gen4 drive claims 7,000 MB/s sequential reads and CDM shows 5,200, you have either a configuration problem or a misstated spec sheet.

    CrystalDiskMark (CDM)

    CDM reports four test profiles, each with a read and a write

    A schematic results window with two columns, Read and Write, and four rows: SEQ1M Q8T1, SEQ1M Q1T1, RND4K Q32T1 and RND4K Q1T1. Teal bars in the Read column and paler dashed-edge teal bars in the Write column run long for the sequential rows and short for the random rows. The bar lengths are schematic.READWRITESEQ1M Q8T1SEQ1M Q1T1RND4K Q32T1RND4K Q1T1ReadWrite
    Figure 1 · The results window is a grid of four profiles by read and write, and sequential rows run far longer than random ones. Illustrative values.

    CrystalDiskMark configuration

    CDM’s default settings are adequate for casual checks but insufficient for review-grade data. The following configuration should be used for all formal testing:

    CrystalDiskMark configuration

    A 1 GiB test fits in the SLC cache and a 32 GiB test does not

    Two panels, each with an upper SLC cache zone and a lower NAND zone. In the left panel a short teal block labeled 1 GiB sits entirely inside the cache zone. In the right panel a tall dashed-edge teal block labeled 32 GiB starts in the cache zone and runs down into the NAND zone. Block heights are schematic.01 CACHE TESTSLC cacheNAND02 NAND TESTSLC cacheNAND1 GiB32 GiBMeasures the cacheReveals raw NAND speedFits in the cacheRuns past the cache
    Figure 2 · The small test measures the cache and the large test runs past it into raw NAND speed, so the page runs both. Illustrative values.
    Setting Value Rationale
    Mode NVMe (or default for SATA) Ensures the correct I/O path is used for the interface type
    Test Size 1 GiB (cache), then 32 GiB (NAND) 1 GiB fits inside most SLC caches; 32 GiB exceeds them and reveals raw NAND speed
    Passes 5 Averaging across five passes smooths out minor OS scheduling noise
    Data Pattern Default (random) CDM uses incompressible random data by default, which is correct for honest testing

    Reading CDM results

    CDM outputs eight metrics across four test profiles. Here is what each row actually tells you and why it matters:

    CDM Row What It Tests Real-World Relevance
    SEQ1M Q8T1 Peak sequential throughput at high queue depth Large file transfers when the drive is under sustained, heavy load. This is the marketing number.
    SEQ1M Q1T1 Sequential throughput at low queue depth Large file copies under typical single-threaded workloads. Closer to what users actually experience.
    RND4K Q32T1 Random 4K at high queue depth Database and server workloads. Rarely relevant for consumer use but shows controller capability.
    RND4K Q1T1 Random 4K at queue depth 1 OS boot, app launches, game loading. The single most important number for perceived system responsiveness.

    Reading CDM results

    Access pattern and queue depth place each CDM row on a map

    A two by two grid. Columns are sequential 1M and random 4K access; rows are high and low queue depth. Top left is SEQ1M Q8T1, the marketing number. Top right is RND4K Q32T1, which shows controller capability. Bottom left is SEQ1M Q1T1, closer to what users experience. Bottom right, outlined in copper, is RND4K Q1T1, the number that tracks perceived system responsiveness.SEQUENTIAL, 1M BLOCKSRANDOM, 4K BLOCKSHIGH QUEUE DEPTHSEQ1M Q8T1The marketing numberHIGH QUEUE DEPTHRND4K Q32T1Shows controllercapabilityLOW QUEUE DEPTHSEQ1M Q1T1Closer to what usersexperienceLOW QUEUE DEPTHRND4K Q1T1Perceived systemresponsivenessCDM rowMost important for responsiveness
    Figure 3 · Sequential rows are the top-line speeds and the random row at low queue depth is the one that tracks responsiveness. Illustrative values.

    Additionally, you can sort through the results and view them individually as IOPS, latency, or in GBps instead of MBps if you’re playing with fast flash.

    ATTO

    ATTO Disk Benchmark chart of write (red) and read (gray) throughput for I/O sizes from 512 B to 64 MB. Speeds ramp up with block size, then plateau near 10 to 13 GB/s; writes drop at 48 and 64 MB.

    Where CDM gives you snapshots at fixed block sizes, ATTO gives you the full picture. In my run above, the sweep covers I/O sizes from 512 B to 64 MB and plots throughput at each step. This produces a characteristic “ramp-up curve” that reveals how the controller handles different I/O granularities.

    ATTO

    ATTO sweeps from small transfer sizes to large and plots each step

    A row of twelve vertical bars standing for throughput at increasing transfer sizes. The leftmost bar, 512 B, is short; the bars climb steeply and then level off at the right, ending at 64 MB. Bar heights are schematic.512 B64 MBtransfer sizeThe ramp-up curveThroughput at one transfer size
    Figure 4 · Schematic bars, fewer than the sizes ATTO runs, from 512 B on the left to 64 MB on the right. Illustrative values.

    Why ATTO matters

    ATTO answers a question CDM cannot: at what block size does this drive reach peak performance? Throughput climbs with transfer size and then levels off, and the size where it levels off differs from one controller and firmware to the next. If the ramp-up curve is jagged or inconsistent, the controller is likely struggling with internal garbage collection or FTL inefficiency at those intermediate sizes.

    Why ATTO matters

    The size where the curve levels off differs between drives

    A schematic chart of throughput against transfer size. Two curves rise from the lower left and flatten at the same height. The teal curve levels off at a small transfer size; the dashed teal curve levels off much later. The axes carry no values.ThroughputhighlowsmalllargeTransfer sizeLevels off earlyLevels off late
    Figure 5 · Two drives climb with transfer size and level off, one early and one late, and ATTO shows where. Illustrative values.

    ATTO configuration

    Transfer size range

    My run above covers 512 B to 64 MB. Keep the whole range, because the small sizes at the low end are where controller weaknesses show up.

    ATTO configuration

    Three ATTO settings shape the sweep

    Three horizontal sliders. The first, transfer size range, is filled from 512 B to 64 MB, the full width. The second, total test length, runs from 256 MB at the left end toward 4 GB at the right end and is filled a little over halfway. The third, queue depth, runs from shallow to deep and has no fill or knob. Fill amounts are schematic.01 TRANSFER SIZE RANGE512 B64 MBKeep the whole range02 TOTAL TEST LENGTH256 MB4 GBLonger runs improve consistency03 QUEUE DEPTHshallowdeepEnough to show scalingSpan the test covers
    Figure 6 · Range, test length and queue depth are set as spans on three sliders, and the page keeps the full range. Illustrative values.

    Total test length

    Use 256 MB at minimum, as in my run above; larger values (1–4 GB) improve consistency but increase test time.

    Queue depth

    Use a queue depth of 4, as in my run above, which is enough to show controller scaling without entering enterprise territory.

    Reading the curve

    A healthy NVMe drive shows a smooth, steep ramp through the small transfer sizes, then a flat plateau at or near rated speed. Look for these warning signs in the ATTO output:

    Reading the curve

    A healthy ramp is smooth and steep, then flat

    A schematic ATTO curve. A dashed gray reference curve rises smoothly and flattens early. A teal curve rises more slowly, reaches its plateau late, wobbles up and down in the middle, and dips once near the right. Three numbered markers label the late plateau, the jagged curve and the write dip. No values are shown.01020301Late plateau02Jagged curve03Write dipPeak only at much larger transfersSwings between adjacent sizesSudden drop at specific sizesDrive under testHealthy reference
    Figure 7 · Against a smooth reference, a late plateau, a jagged stretch and a sudden write dip each point to a different cause. Illustrative values.

    Late plateau

    If the drive reaches peak speed only at much larger transfers than similar drives do, the controller may be struggling to coalesce small I/O.

    Jagged curve

    When throughput swings up and down between adjacent transfer sizes, suspect firmware instability or aggressive background garbage collection.

    Write dips

    Sudden drops in write throughput at specific block sizes can indicate SLC cache boundary effects or FTL mapping inefficiencies.

    AS SSD

    AS SSD Benchmark 2.0 results for a 1 TB drive: sequential 4,059 MB/s read and 4,220 MB/s write, access times 0.010 and 0.017 ms, and a total score of 9426.

    AS SSD is the hard truth of consumer synthetic testing. Unlike CDM, whose test data can be switched from random to all zeros, the standard AS SSD run shown above (sequential, 4K, 4K with 64 threads, and access time) uses incompressible data. This means compression-equipped controllers get no help in that run. Its speeds are the ones to expect with data that does not compress, like encrypted volumes.

    AS SSD

    AS SSD's standard run sends incompressible data

    Two horizontal lanes. In the first lane, CrystalDiskMark offers two test data choices, random in teal and all zeros in copper, which feed the controller; a note says the test data can be switched from random to all zeros. In the second lane, AS SSD's standard run uses incompressible data in teal, and a note says a compressing controller gets no help.01 CRYSTALDISKMARKRandomAll zerosControllerTest data can beswitched from randomto all zeros02 AS SSDIncompressibleControllerA compressing controllergets no helpIncompressible dataCompressible data
    Figure 8 · CDM can switch its test data to all zeros, while AS SSD's standard run gives a compression-equipped controller no help. Illustrative values.

    Unique value: access time

    AS SSD provides a metric that no other consumer tool does well, which is read and write access time in milliseconds. This is a direct measurement of the controller’s reaction time to a new I/O request, completely independent of throughput. A drive can have excellent sequential speeds but poor access time if its controller firmware has high per-request overhead.

    Unique value: access time

    One 1 TB drive's access times sit well under the NVMe limit

    A horizontal chart on a scale from 0 to 0.1 ms. A read access time bar ends at 0.010 ms and a write access time bar at 0.017 ms. Two dashed vertical marks sit at 0.05 ms, the good limit for NVMe, and 0.1 ms, the good limit for SATA. Both bars end well short of either mark.AS SSD access timeAccess time, ms00.0250.050.0750.1Read access time0.010 msWrite access time0.017 msMeasuredNVMe limitSATA limit
    Figure 9 · Measured read and write access times sit well under the 0.05 ms mark the page calls good for NVMe. Source: the author's AS SSD result on a 1 TB drive; limits are the author's rule of thumb.

    Good read access time

    A good result is under 0.05 ms for NVMe and under 0.1 ms for SATA, which indicates a responsive controller with efficient command processing.

    Concerning read access time

    Above 0.1 ms for NVMe suggests firmware overhead, thermal throttling, or a controller that deprioritizes latency in favor of throughput.

    The copy benchmark

    AS SSD also includes a three-pattern copy benchmark that simulates transferring an ISO image, a program folder, and a game folder, using fixed file mixes that stress the controller with varying file sizes and counts simultaneously, bridging the gap between pure synthetic and trace-based testing.

    The copy benchmark

    AS SSD copies three file mixes that stress the controller differently

    Three equal panels, each drawn as the file blocks one AS SSD copy test moves. The ISO image panel shows two large blocks. The program folder panel shows a grid of many small blocks. The game folder panel shows one large block, two medium blocks and a row of small ones. Sizes and counts are schematic.01 ISO IMAGELarge files02 PROGRAM FOLDERSmall files03 GAME FOLDERMixed sizesA file the test copies
    Figure 10 · Each copy pattern moves a different mix of file sizes and counts, which bridges synthetic and trace-based testing. Illustrative values.

    Anvil

    Anvil's Storage Utilities results for a 2048 GB PCIe SSD, listing response time, IOPS and MB/s for sequential, 4K, 4K QD4 and 4K QD16 reads and writes, with an overall score of 25,368.77.

    Anvil sits between consumer synthetics and heavier I/O analysis. Where CDM runs each profile at a single queue depth, and AS SSD adds one 4K row with 64 threads, Anvil runs its 4K tests at several queue depths in a single pass (4K, 4K QD4 and 4K QD16 in the result above), reporting both IOPS and response time at each level. This shows how a drive scales under increasing parallelism.

    Anvil

    Anvil measures how IOPS scale as the queue deepens

    A schematic chart of IOPS against queue depth at QD1, QD4 and QD16. A teal curve climbs through all three levels, gaining less at each step. A dashed teal line with hollow dots climbs to QD4 and then flattens at QD16. The axes carry no values.IOPSQD1QD4QD16highlowQueue depthScales with depthSaturated controller
    Figure 11 · A well-designed controller keeps gaining IOPS up the queue-depth steps, by less each time, and one that is saturated flattens or declines. Illustrative values.

    Key metrics

    IOPS scaling

    A well-designed controller should keep gaining IOPS from QD1 through QD16, though each step gains less than the depth grows. In the result above, 4K reads and writes both rise at every step. If IOPS flatten or decline at higher queue depths, the controller is saturated.

    Key metrics

    Anvil reads IOPS, response time and read-write asymmetry

    Three equal panels. The first shows a teal line rising steadily, labeled IOPS scaling, with a note that a plateau or decline means saturation. The second shows a dashed teal line that is flat and then climbs steeply at the deep end, labeled response time. The third shows three pairs of bars, solid teal for reads and dashed paler teal for writes, with the write bar taller than the read bar in every pair, labeled read versus write asymmetry.01 IOPS SCALINGGains stay steadyPlateau or declinemeans saturation02 RESPONSE TIMERises at the deep endQueued faster thanthey are served03 READ VS WRITEGap shows prioritiesCompare both atevery queue depthRead or IOPSResponse or write
    Figure 12 · Three views of the same queue-depth steps, each pointing to a different controller behavior. Illustrative values.

    Response time

    Anvil reports average response time per QD level. Watch for steep increases at the deepest queues, which indicate the controller is queuing requests faster than it can service them.

    Read vs. write asymmetry

    Compare read and write IOPS at each QD level. Large asymmetries can reveal controller design priorities and NAND page programming characteristics.
    When to Use Anvil: Anvil fills the gap between CDM’s snapshot approach and a custom fio job file. Use it when you need QD-scaling data but do not need that granular control.

    KDiskMark

    KDiskMark results window on Linux with the unit set to IOPS, listing sequential 1M and random 4K read and write results.

    KDiskMark is the Linux equivalent of CrystalDiskMark, delivering snapshot benchmarks for SEQ1M and RND4K read/write speeds across configurable queue depths and threads, using fio under the hood.

    KDiskMark

    KDiskMark runs fio, so Linux filesystem and scheduler effects show

    A vertical stack of four boxes joined by arrows: KDiskMark, fio, Linux filesystem and scheduler outlined in copper, and SSD. A note beside the copper box says these are the quirks Windows tools miss.KDiskMarkthe test windowfiothe engine underneathFilesystem, scheduleroverhead and queuingSSDthe drive under testLinux-specificquirks Windowstools missTest and driveLinux layers
    Figure 13 · The Linux layers between the test and the drive can move a result in ways a Windows tool never sees. Illustrative values.

    It uncovers Linux-specific quirks like filesystem overhead or scheduler impacts that Windows tools miss, enabling cross-OS drive comparisons. Profiles like NVMe SSD presets optimize block sizes for controller stress-testing, with exportable reports for sharing precise IOPS and latency data.

    AmorphousDiskMark

    AmorphousDiskMark 4.0.1 on macOS showing MB/s results: sequential 1M QD8 reads 3127.27 and writes 1405.44, random 4K QD1 reads 41.13 and writes 30.62.

    AmorphousDiskMark is the macOS counterpart to CrystalDiskMark, providing SEQ1M and RND4K read/write benchmarks in MB/s and IOPS. The result above shows fixed rows, SEQ1M at QD8 and QD1 and RND4K at QD32 and QD1.

    AmorphousDiskMark

    AmorphousDiskMark probes macOS bottlenecks on two storage paths

    At the top, one box, AmorphousDiskMark on macOS, with two arrows leading down to two parallel paths. The left path goes through a Thunderbolt enclosure, marked with a copper outline, to an external drive. The right path goes through Apple Silicon NVMe, marked with a copper outline, to internal storage.AmorphousDiskMark on macOS01 EXTERNALThunderbolt enclosureExternal drive02 INTERNALApple Silicon NVMeInternal storageThe same fixed test rows run over either pathTest and drivePossible bottleneck
    Figure 14 · The same test runs over an external Thunderbolt enclosure or Apple Silicon NVMe, and the limit shows at that hop. Illustrative values.

    Because it runs on macOS, it can show macOS-specific limits such as a Thunderbolt enclosure or an Apple Silicon NVMe drive, and it lets you set those results beside CDM-style results from other systems.

    Synthetic toolkit summary

    Each tool in this part serves a distinct purpose. Overlap is intentional, because cross-referencing results between tools exposes inconsistencies that a single tool would miss.

    Synthetic toolkit summary

    Six tools cross-check one drive by comparing results

    A central box labeled One drive with six tool boxes around it joined by lines: CrystalDiskMark, ATTO and AS SSD on the left, Anvil, KDiskMark and AmorphousDiskMark on the right. KDiskMark and AmorphousDiskMark are outlined in copper because they carry CrystalDiskMark-style tests to Linux and macOS.One drivecross-referencedCrystalDiskMarkhero numbersATTOtransfer sizesAS SSDincompressibleAnvilqueue depthsKDiskMarkLinux, CDM-styleAmorphousmacOS, CDM-styleToolCDM-style tool for another OS
    Figure 15 · Overlap is intentional, because results compared across tools expose inconsistencies a single tool would miss. Illustrative values.
    Tool Primary Strength Data Pattern Best For
    CrystalDiskMark Spec sheet verification Incompressible (default) Confirming rated speeds, comparing hero numbers
    ATTO Transfer size sweep Not shown in the settings Controller ramp-up analysis, identifying small-I/O weaknesses
    AS SSD Worst-case performance Incompressible (standard run) True NAND throughput, access time, copy simulation
    Anvil QD scaling & response time Configurable IOPS scaling curves, bridging consumer and enterprise testing
    KDiskMark Linux CDM parity Incompressible Cross-OS baselines
    Amorphous DiskMark macOS CDM parity Random/Zero Cross-OS baselines

    A note on synthetic discipline

    Synthetics are only as good as the methodology behind them. Every test in this part must be run on a locked-down system with a pre-conditioned drive at the correct fill level, as Part 1 sets out. Run each tool a minimum of three times, each a separate launch of the tool, and report the median, not the peak. If your three runs vary by more than 5%, something in your environment is not controlled, and it needs fixing before you publish.

    A note on synthetic discipline

    Three runs within 5% mean the environment is controlled

    Two groups of three horizontal bars, one per run. In the top group, in teal, the three runs are nearly the same length, within a shaded band marked 5%, and the verdict is controlled, report the median. In the bottom group, in dashed paler teal, the runs differ by much more than the band and the verdict is to fix the environment first. A dashed line marks the median run in each group.01 RUNS AGREERun 1Run 2Run 3Controlled: report the median02 RUNS SPREADRun 1Run 2Run 3Fix the environment firstOne run5% bandMedian
    Figure 16 · Report the median of at least three runs, and treat a wider spread as a sign the test setup is not locked down. Illustrative values.

    Part 3 moves beyond controlled laboratory conditions into trace-based and real-world testing, where the variables multiply.

    KEEP GOING / NEXT CHAPTERContinue to Part 3

    Sources

    Primary is the original paper, standard or datasheet. Secondary is a review, a vendor summary or a news report. Measured is my own test data.

    Show all 2 sources, 1 primary

    Continue reading

    Read next