Original Link: https://www.anandtech.com/show/8752/gskill-phoenix-blade-480gb-pcie-ssd-review
G.Skill Phoenix Blade (480GB) PCIe SSD Review
by Kristian Vättö on December 12, 2014 9:02 AM EST
G.Skill hasn't been a very visible SSD OEM lately. Like many DRAM module companies, G.Skill entered the market early around 2009 when the market was very immature and profits were high, but lately the company has more or less been on a hiatus from the market. Even though G.Skill has had an SF-2281 based Phoenix III in the lineup for quite some time, it never really did anything to push the product and a Google search yields zero reviews for that drive (at least from any major tech review outlet).
However, back at Computex this year G.Skill showcased a prototype of its next generation SSD: the Phoenix Blade. Unlike most SSDs on the market, the Phoenix Blade utilizes a PCIe 2.0 x8 interface, but unfortunately it is not the native PCIe drive many of you have been waiting for. It is driven by four SandForce SF-2282 controllers in a RAID 0 configuration. It makes sense for G.Skill to pursue the ultra high-end niche because the SATA SSD market is currently extremely populated. It ends up being close to impossible for the smaller OEMs to compete against giants like Samsung, SanDisk and Crucial/Micron while being profitable, since ultimately the NAND manufacturers that are vertically integrated will always have a cost advantage.
| G.Skill Phoenix Blade Specifications | |
| Capacity | 480GB |
| Form Factor | Half-Height, Half-Length (HHHL) |
| Interface | PCI Express 2.0 x8 |
| RAID Controller | SBC 208-2 |
| NAND Controller | 4x SandForce SF-2282 |
| NAND | Toshiba 64Gbit 19nm MLC |
| Sequential Read | Up to 2000MB/s |
| Sequential Write | Up to 2000MB/s |
| 4KB Random Read | Up to 90K IOPS |
| 4KB Random Write | Up to 245K IOPS |
| Power Consumption | 8W (idle) / 18W (max) |
| Encryption | AES-128 |
| Endurance | 1536TB (~1.4TB per day) |
| Warranty | Three years |
At this moment the Phoenix Blade is only available in 480GB capacity, although G.Skill plans to add a 960GB model later. 480GB is a logical choice because for the target group 240GB would be too small in many cases and doesn't provide the same level of performance, whereas the cost of the 960GB would push most shoppers away. In the end, G.Skill hasn't been actively involved in SSDs recently, so doing a 'soft' launch and observing the market's reaction is a safe strategy.
The interesting spec is the endurance and it's not a typo. G.Skill is indeed rating the Phoenix Blade at 1,536TB, which translates to 1.4TB (i.e. 1433.6GB) of writes per day for three years. I asked G.Skill about the rating method and I was told it's simply raw NAND capacity multiplied by the number of P/E cycles, which is then divided by the average write amplification. G.Skill assumes an average write amplification of 1x due to SandForce's real-time data compression, so 512GB*3,000/1 yields 1,536TB. As G.Skill's SSD venture is solely consumer focused, it has no reason to artificially limit the endurance to boost its enterprise SSD sales like many vendors do, although I am concerned whether the Phoenix Blade has been fully validated for workloads that write over a terabyte of data per day.
Delving into the Phoenix Blade reveals a massive metal heatsink that covers nearly the whole PCB (or both PCBs, actually). There's plenty to cool since each SF-2282 can draw up to ~4W under load plus at least another couple of watts for the RAID controller, which results in a maximum power rating of 18W according to G.Skill's data sheet.
Taking off the heatsinks reveals the main PCB as well as the daughterboard. Both are home to two SF-2282 controllers with each controller being connected to eight dual-die 16GB NAND packages (i.e. 32*16GiB=512GiB of NAND in total).
The RAID controller in the Phoenix Blade is a complete mystery. Googling the part number doesn't bring any light to the situation and due to confidentiality agreements G.Skill is tightlipped about any details regarding the controller. My best guess is that the controller features firmware from SBC Designs with the actual silicon coming from another vendor.
Update 12/13: It turns out that the controller has actually nothing to do with SBC Designs as it's from Comay that is a brand used by CoreRise, which is a Chinese SSD manufacturer. In fact, the Phoenix Blade looks a lot like CoreRise's Comay BladeDrive G24, so I wouldn't be surprised if G.Skill was sourcing the drives from CoreRise and rebranding them (nearly all memory vendors do this -- very few do the manufacturing in-house). I'm still inclined to believe that the silicon is from a third party as CoreRise's product lineup suggests that the company doesn't have the expertise that's needed for semiconfuctor design and development, but the firmware is likely unique to CoreRise.
The Phoenix Blade is bootable in any system. Upon boot, the drive loads legacy drivers before the BIOS and hence it can be selected as a boot device just like any other drive. Loading the drivers adds a few seconds to the boot time, but other than that the Phoenix Blade behaves like a normal SATA drive (but with much higher rated peak performance). TRIM and SCSI unmap are also supported.
While not easily visible in the photo due to residue from thermal pads, the Phoenix Blade uses the new B2 stepping of the SF-2282 controller. The fundamental design of the controller has remained unchanged, but the new stepping introduces DevSleep support for improved power efficiency, although in this case DevSleep brings no real added value.
Test System
| CPU | Intel Core i5-2500K running at 3.3GHz (Turbo & EIST enabled) |
| Motherboard | ASRock Z68 Pro3 |
| Chipset | Intel Z68 |
| Chipset Drivers | Intel 9.1.1.1015 + Intel RST 10.2 |
| Memory | G.Skill RipjawsX DDR3-1600 4 x 8GB (9-9-9-24) |
| Video Card | Palit GeForce GTX 770 JetStream 2GB GDDR5 (1150MHz core clock; 3505MHz GDDR5 effective) |
| Video Drivers | NVIDIA GeForce 332.21 WHQL |
| Desktop Resolution | 1920 x 1080 |
| OS | Windows 7 x64 |
Thanks to G.Skill for the RipjawsX 32GB DDR3 DRAM kit
Performance 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.
AnandTech Storage Bench 2013
Our Storage Bench 2013 focuses on worst-case multitasking and IO consistency. Similar to our earlier Storage Benches, the test is still application trace based – we record all IO requests made to a test system and play them back on the drive we are testing and run statistical analysis on the drive's responses. There are 49.8 million IO operations in total with 1583.0GB of reads and 875.6GB of writes. I'm not including the full description of the test for better readability, so make sure to read our Storage Bench 2013 introduction for the full details.
| AnandTech Storage Bench 2013 - The Destroyer | ||
| Workload | Description | Applications Used |
| Photo Sync/Editing | Import images, edit, export | Adobe Photoshop CS6, Adobe Lightroom 4, Dropbox |
| Gaming | Download/install games, play games | Steam, Deus Ex, Skyrim, Starcraft 2, BioShock Infinite |
| Virtualization | Run/manage VM, use general apps inside VM | VirtualBox |
| General Productivity | Browse the web, manage local email, copy files, encrypt/decrypt files, backup system, download content, virus/malware scan | Chrome, IE10, Outlook, Windows 8, AxCrypt, uTorrent, AdAware |
| Video Playback | Copy and watch movies | Windows 8 |
| Application Development | Compile projects, check out code, download code samples | Visual Studio 2012 |
We are reporting two primary metrics with the Destroyer: average data rate in MB/s and average service time in microseconds. The former gives you an idea of the throughput of the drive during the time that it was running the test workload. This can be a very good indication of overall performance. What average data rate doesn't do a good job of is taking into account response time of very bursty (read: high queue depth) IO. By reporting average service time we heavily weigh latency for queued IOs. You'll note that this is a metric we have been reporting in our enterprise benchmarks for a while now. With the client tests maturing, the time was right for a little convergence.
Quite surprisingly, the Phoenix Blade takes the lead in our 2013 Storage Bench and even beats the XP941. After reviewing the RevoDrive 350, I didn't get my hopes up for the Phoenix Blade, but it looks like G.Skill has done a much better job at optimizing the drive for performance.
AnandTech Storage Bench 2011
Back in 2011 (which seems like so long ago now!), we introduced our AnandTech Storage Bench, a suite of benchmarks that took traces of real OS/application usage and played them back in a repeatable manner. The MOASB, officially called AnandTech Storage Bench 2011 – Heavy Workload, mainly focuses on peak IO performance and basic garbage collection routines. There is a lot of downloading and application installing that happens during the course of this test. Our thinking was that it's during application installs, file copies, downloading and multitasking with all of this that you can really notice performance differences between drives. The full description of the Heavy test can be found here, while the Light workload details are here.
The Phoenix Blade continues to be strong in our 2011 Storage Benches, although the XP941 retrieves its crown as the fastest client drive. I'm guessing the XP941 is more optimized for typical client workloads, which the 2011 suites present, whereas the 2013 workload is much, much heavier and only applies to users with very heavy IO workload.
Random Read/Write Speed
The four corners of SSD performance are as follows: random read, random write, sequential read and sequential write speed. Random accesses are generally small in size, while sequential accesses tend to be larger and thus we have the four Iometer tests we use in all of our reviews.
Our first test writes 4KB in a completely random pattern over an 8GB space of the drive to simulate the sort of random access that you'd see on an OS drive (even this is more stressful than a normal desktop user would see). We perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time.
Random read speed is typical SandForce, which makes sense because the performance doesn't scale across multiple controllers at such low queue depths (QD=3 in this case).
The same goes for random write performance at queue depth of 3, which isn't very high but is normal for SandForce based drives. However, the Phoenix Blade scales brilliantly with the queue depth and is considerably faster than the XP941 or RevoDrive 350.
Sequential Read/Write Speed
To measure sequential performance we run a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 1. The results reported are in average MB/s over the entire test length.
Sequential performance is also excellent, although the XP941 enjoys a slight advantage in sequential read performance. Overall the Phoenix Blade seems to be well optimized for parallelism -- much better than the RevoDrive 350 -- as it's able to provide substantially higher performance than SATA drives.
AS-SSD Incompressible Sequential Read/Write Performance
The AS-SSD sequential benchmark uses incompressible data for all of its transfers. The result is a pretty big reduction in sequential write speed on SandForce based controllers, but most other controllers are unaffected.
Performance vs. Transfer Size
ATTO is a useful tool for quickly benchmarking performance across various transfer sizes. You can get the complete data set in Bench. Similar to the RevoDrive 350, the Phoenix Blade doesn't scale that well at small transfer sizes, but at 128KB and larger it offers the best throughput by exceeding 2GB/s at the largest IO sizes.
Click for full size
Final Words
The Phoenix Blade is a beast in performance. It's in the top two of all the client-level SSDs that we have ever tested and trades blows with Samsung's XP941 PCIe SSD (although I must say here that most of the client drives we have tested are SATA based, so the Phoenix Blade with its PCIe 2.0 x8 interface and four SF-2282 controllers in RAID 0 is obviously at an advantage). However, that doesn't necessarily dictate the drive's performance, especially outside synthetic benchmarks, because as we learned in the RevoDrive 350 review, a PCIe SSD isn't always faster than a good SATA 6Gbps SSD.
Comparing the RevoDrive 350 to the Phoenix Blade is actually very interesting: while the two share the same core (4x SF-2282), the Phoenix Blade is considerably faster in all our benchmarks. It's hard to point at the SBC controller given how little we know and the lack of information available, but most likely the RAID controller and its firmware are to thank for the performance as the SF-2282 controller and firmware are essentially the same for all vendors. I have to say I'm impressed with what G.Skill has been able to put out with its first ever PCIe SSD because OCZ has a long history of building PCIe designs.
| Price Comparison (12/11/2014) | |
| 480/512GB | |
| G.Skill Phoenix Blade | $700 |
| OCZ RevoDrive 350 | $795 |
| Samsung XP941 | $510 |
Better yet, the price is nearly $100 lower than what the RevoDrive 350 sells for, but on the other hand that's still almost $200 more than the 512GB XP941. As a result the XP941 will remain as my recommentation for users that have compatible setups (PCIe M.2 and boot support for the XP941) because I'd say it's slightly better performance wise for typical client workloads and at $200 less there is just no reason to choose the Phoenix Blade over the XP941, except for compatibility.
This is ultimately the niche for the Phoenix Blade. Since XP941 boot support is mostly limited to motherboards with the Z97 chipset, there is a market for users with older motherboards where the XP941 is simply not an option due to the lack of boot support. The Phoenix Blade features legacy drivers that load before the BIOS, so it can be selected as the boot device in practically any motherboard. As such it's currently the best option for people who don't have an Z97 system but want fast 'all-in-one' PCIe SSD storage. (Another option would be a PCIe RAID card with SATA 6Gbps SSDs in RAID 0, but that requires more set up and management.) It comes at a cost, but the users who need/want a drive with such high performance and fall into the non-Z97 niche shouldn't find the price overwhelming.
Facebook
Twitter
RSS
