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.

    Technical guide

    Benchmarking 101

    How to test an SSD so the result means something, from locking down the host to reading a trace-based score.

    A benchmark result depends as much on the host, the drive's state and the workload as on the drive itself. Part 1 sets up a repeatable method: a quiet host, a preconditioned drive, and a clear view of cache behavior, queue depth and workload mix. Part 2 covers the synthetic tools, what their settings do and where they stop being useful. Part 3 moves to application and trace-based tests that show how storage behaves under real software.

    The series

    Read in order

    Each part builds on the one before, so start with Part 1.

    A repeatable SSD test: lock down the host, fill the drive, then change one variable at a timeA three-panel cover. Left: four host settings fixed before a run, the drive under test kept off the operating system volume, search indexing off, updates paused and PCIe link power management off. Center: a fresh-out-of-box drive drawn as empty blocks beside a drive written into its used state, full of data with stale blocks among it. Right: three sliders for the variables a test changes, the read and write mix, sequential or random access, and compressible or incompressible data.GUIDE / BENCHMARKING 101, PART 1Test the drive, not the boxLOCKDOWN · DRIVE STATE · VARIABLES01 LOCKDOWN02 DRIVE STATE03 VARIABLESNot the OS driveIndexing offUpdates pausedPCIe ASPM offSame host every runnothing changes butthe variable you testFresh out of boxUsed statelivestaleFill it firstone full-span writeends the fresh stateRead / write mixSequential / randomCompressible or notOne at a timeeach one moves theresult on its own

    Part 1

    A repeatable test method

    Build a repeatable SSD test method: control the host, precondition the drive, and understand cache behavior, queue depth, and workload mix.

    Read Part 1
    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

    Part 2

    Synthetic benchmark tools

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

    Read Part 2
    From one synthetic pattern to replayed application traces and hand-timed real workA three-panel cover. Left: a synthetic test sends the same request at an even pace, drawn as identical bars. Center: a trace benchmark replays recorded application I/O, reads and writes of mixed sizes with idle gaps between them. Right: real-world tests, a file copy progress bar and a stopwatch for a game load, timed by hand. Drawing is schematic.GUIDE / BENCHMARKING 101, PART 3The drive under real workSYNTHETIC · TRACE · REAL WORLD01 SYNTHETIC02 TRACE03 REAL WORLDone request, againOne patternclean, repeatable,unlike an appreadwriteReplayed appsmixed sizes, pausesPCMark and 3DMarkFile copyGame loadstopwatchTimed by handcopies, game loadsDrawing is schematic

    Part 3

    Application and trace-based tests

    Move beyond synthetic scores with PCMark, 3DMark, Procyon, and hands-on tests that reveal how storage behaves under real applications.

    Read Part 3

    On this site

    Where it connects

    Continue on this site

    All Guides Flash Foundations Labs