G.Skill Phoenix Blade (480GB) PCIe SSD Review
by Kristian Vättö on December 12, 2014 9:02 AM ESTPerformance Consistency
Performance consistency tells us a lot about the architecture of these SSDs and how they handle internal defragmentation. 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. 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.
To test IO consistency, we fill a secure erased SSD with sequential data to ensure that all user accessible LBAs have data associated with them. Next we kick off a 4KB random write workload across all LBAs at a queue depth of 32 using incompressible data. The test is run for just over half an hour and we record instantaneous IOPS every second.
We are also testing drives with added over-provisioning by limiting the LBA range. 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.
Each of the three graphs has its own purpose. The first one is of the whole duration of the test in log scale. 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. Click the dropdown selections below each graph to switch the source data.
For more detailed description of the test and why performance consistency matters, read our original Intel SSD DC S3700 article.
 |
|||||||||
| Default | |||||||||
| 25% Over-Provisioning | |||||||||
Even though the Phoenix Blade and RevoDrive 350 share the same core controller technology, their steady-state behaviors are quite different. The Phoenix Blade provides quite substantially higher peak IOPS (~150K) and it is also more consistent in steady-state as the RevoDrive frequently drops below 20K IOPS while the Phoenix Blade doesn't.
 |
|||||||||
| Default | |||||||||
| 25% Over-Provisioning | |||||||||
 |
|||||||||
| Default | |||||||||
| 25% Over-Provisioning | |||||||||
TRIM Validation
To test TRIM, I turned to our regular TRIM test suite for SandForce drives. First I filled the drive with incompressible sequential data, which was followed by 60 minutes of incompressible 4KB random writes (QD32). To measure performance before and after TRIM, I ran a one-minute incompressible 128KB sequential write pass.
| Iometer Incompressible 128KB Sequential Write | |||
| Clean | Dirty | After TRIM | |
| G.Skill Phoenix Blade 480GB | 704.8MB/s | 124.9MB/s | 231.5MB/s |
The good news here is that the drive receives the TRIM command, but unfortunately it doesn't fully restore performance, although that is a known problem with SandForce drives. What's notable is that the first LBAs after the TRIM command were fast (+600MB/s), so in due time the performance across all LBAs should recover at least to a certain point.
Facebook
Twitter
RSS
62 Comments
View All Comments
Supercell99 - Sunday, December 14, 2014 - link
Someone makes this now. Just saw a review recently, can't remember where. Very fast, but absurdly expensive. If Samsung or Intel got behind something like this and put out a design that could be easily mfg with commodity ECC ram, then the adoption rate would be high. Shops that need high file I/O, such as big data or database applications would benefit from a batt backed RAM disk card.gammaray - Monday, December 15, 2014 - link
why pay 700$ for this when i can grab samsung 850 pro for half?