Performance Comparisons – TRIM Speed
Thanks to the plethora of data we have at our disposal from the new suite, I can derive some additional interesting data that nobody seems to have been paying any attention to yet. Have you ever deleted a large file and then noticed your system seem to hang for some time afterwards? Maybe file moves from your SSD seemed to take longer than expected?
That's your problem right there. In the above capture, a 16GB file was deleted while a minimal level of background IO was taking place. Note how that IO completely stalls for a few seconds shortly after the file was deleted? That's a bad thing. We don't want that, but to fix it, someone needs to measure it and point it out.
Latency Percentile data was obtained while running a 'light' (1000 IOPS) workload in the background while files of varying sizes were deleted. The amount of latency added during the deletions was measured, compared with a baseline, and correlated with the sizes of the deleted files. The result is how much latency is added to the active workload per GB of file size that was deleted. In short, this is how long you may see a stutter last after deleting a 1GB file.
This is another result from a different set of data. While our suite runs, it issues a full drive TRIM several times. Some of those times it is done on an empty SSD, others is it done on a full SSD. Any difference in time taken is measured and calculated, normalizing to a response time per GB TRIMmed. In short, this is how long an otherwise idle SSD would hang for upon receiving a TRIM command for a 1GB file. These times are shorter than the last chart, because the SSD controller does not have to juggle this TRIM with background activity, and it can service the request at full speed.
Speaking to the results, Samsung's controllers and firmware are extremely refined here. If you've ever partitioned a Samsung SSD (any model really) and it seemed abnormally quick, well, you weren't wrong.
Perhaps fanciful, but i agree
Perhaps fanciful, but i agree it could be a killer app?
“Conclusion: we have now reached a new era
in which mass storage is capable of performing
at close to the same sequential performance
as volatile DDR3 DRAM. Four such M.2 SSDs
in RAID-0 mode == ~8TB (before formatting).”
My take on it would be a less ambitious 2 drive raid 0 of 512gm 960 ssds.Best performing and cheaper.
PCIe Gen 3.0 allows 1GB ps per lane, bidirectionally, so 2GB per lane theoretical max.
OR, 8GB ps for the 4 lane dual M.2 ports on moboS.
In theory thats sufficient to max out 2 raid 0 960 ssdS, but 3500MB ps sequential reads (writes are 2100MB), are of course unidirectional.
so in theory it seems raid 0 pair of 960s yields 4000MB sustained, read or write.
I am pretty sure we will see 8 lanes available to m.2 mobo sockets (even w/ bargain AMD Ryzen mobos & cpus (32 lanes BTW)), allowing 7000/4400 MB ps read write in theory, w/o fancy controllers.
I dunno the numbers for ram bandwidth. a lot better am sure. not sure thats a deal breaker for my argument.
point is, 7000/4400MB are numbers in a league of their own compared to anything before – even in the server world. Its a new paradigm for coders.
ok, using it for virtual memory isnt as fast as real memory, but shit its big. I dunno enough about architecture etc., but a TB of ram may open many possibilities for completely new approaches to old coding problems.
the killer benefit of ssdS was fast random access. It transformed our PCs.
~150MB ps sequential was livable, access times were the killer on HDDs performance.
As many have said re the 960, more of the same will be barely noticed by many.
give a gamer 1 TB of passable virtual memory, and apps which use it, then that could be revolutionary.
it bears repeating btw, that IOPS has shown even more stellar performance gains in the 960, and I imagine thats important for virtual memory. As we hear, many consider this the main reason to spend the extra for the 960 over the 950.
PS, upon reflection, poor
PS, upon reflection, poor mans raid 0 on 4 lanes is still attractive for swap/page files, even with little read speed gain. Write speed almost doubles from a theoretical 2200 MB ps to 4000MB ps.