The IO Stack

 How IOs traverse the SW/HW stack and are ultimately “seen” by the SSD at the physical Device level is important to understand when testing SSDs.

File Systems, System Caches and Device Drivers all influence how the IOs are presented to the SSD and returned to Application space.  While a user application may create a certain Access Pattern of IOs, these IOs may be subject to System File Caching or File Fragmentation.

IOs can be split, concantonated or coalesced.  The timing of IOs can be influenced by “Read Ahead Pre Fetches” and “Write Behind Lazy Write” Cached IOs resulting in a loss of one-to-one correspondence of the original IO to the IO at the SSD level.  For example, a large block 1024KiB SEQ write – perhaps from a streaming video – could be split by the OS into concurrent 128KiB Writes, effectively creating RND 128KiB Writes to the SSD.  Alternatively, a stream of SEQ 4KiB Writes could be coalesced by the system into a large block SEQ Write.  Finally, small block RND 4KiB Read Writes may be written to system cache and never make it to the SSD Device.

The net impact is that IOs at the SSD Device level can be very different from what came from, or ultimately ends up returning to, the System level user mode.  Accordingly, a test sponsor should be careful in selecting the test software or benchmarking tools.

CTS is a Linux based, HBA Device level software tool that applies a known and repeatable test stimulus directly to the SSD device.  Used in conjunction with a RTP Hardware platform, RTP / CTS can normalize effects of the hardware and help isolate performance measurements to the SSD Device.