The second and third one zoom into the beginning of steady-state operation (t=1400s) but on different scales: the second one uses log scale for easy comparison whereas the third one uses linear scale for better visualization of differences between drives. The first one is of the whole duration of the test in log scale. This gives us a look into the drive’s behavior with varying levels of empty space, which is frankly a more realistic approach for client workloads.Įach of the three graphs has its own purpose. We are also testing drives with added over-provisioning by limiting the LBA range.
The test is run for just over half an hour and we record instantaneous IOPS every second. Next we kick off a 4KB random write workload across all LBAs at a queue depth of 32 using incompressible data. To test IO consistency, we fill a secure erased SSD with sequential data to ensure that all user accessible LBAs (Logical Block Addresses) have data associated with them. When and how an SSD decides to run its defrag or cleanup routines directly impacts the user experience as inconsistent performance results in application slowdowns. The reason we do not have consistent IO latency with SSDs is because inevitably all controllers have to do some amount of defragmentation or garbage collection in order to continue operating at high speeds. Performance consistency tells us a lot about the architecture of these SSDs and how they handle internal fragmentation.
0 kommentar(er)
