DRAM-Less Testing
Random writes with relatively small block sizes over large areas are the weakness of DRAM-less SSDs. We tested this by sending random 4K block-sized writes to a file of varying size to control the locality of the writes, which should put different levels of stress on the flash-translation layer and reveal additional structure.
For workloads that are confined over a small area, 5 GB or less, the IG5220 controller works REALLY well, reaching the best result we've ever seen. Once the test area increases, performance drops quickly though. Beyond 15 GB, the performance is comparable to other last-gen DRAM-less designs. Still, as the real-life performance numbers show, performance is excellent.
IO Latency
In this section, we take a closer look at the IO latencies of our SSDs, which helps quantify the time it takes for a data transfer to travel through the OS and the SSD controller, get executed, and report its completion back to the application. The numbers presented are the 99th percentile, recording an upper latency limit (=worst case) you can expect from the drive with the given IO load. The 99th percentile was chosen to eliminate outliers caused by random events, like OS processor scheduling and background processes using up CPU time. Latency is an important factor for enterprise sectors that need to achieve certain quality-of-service levels, but ends up playing an important role to us enthusiasts as well. Our goal here is to identify bottlenecks in the controller or flash cell erase process.
Mixed Accesses Patterns
Our final synthetic test workload examines IO performance with various mixed read/write ratios. On the horizontal axis, we start with a 100% read (0% write) operation on the left, moving through various read/write ratios until we reach 100% write (0% read) on the right. The 99% ratio values are especially important data points here since it's rare to only send read or write operations to a drive. It is much more common to have reads and writes interspaced in between, one source of which is disk "noise" created by the operating system or background programs. The other read/write ratios are useful because they help determine the performance you can expect from various application scenarios.