Addressing RevoDrive X2's Shortcomings And Improving RevoDrive 3
At first glance, very little gives away the changes from RevoDrive X2 and RevoDrive 3 X2, but looks can be deceiving. Stare a little closer and the differences become much more apparent. First there are the obvious SandForce SF-2200-series controllers, of which there are four.
But also, connecting those four controllers to the PCI bus is handled in a more elegant (or at least modern) way. Remember that the RevoDrive X2 employed a Silicon Image Sil3124 four-port PCI-X-based SATA controller to create the equivalent of a RAID 0 configuration. A Pericom bridge chip in its "reverse" configuration enabled the four-lane PCI Express interface's conversion to PCI-X for that older controller component. A little latency might have been added overall, but the equivalent of four Vertex 2s weren't bottlenecked at all by the configuration.
The RevoDrive 3 X2 is different beast with a cleaner pedigree. Unlike its predecessor, OCZ relies on its new SuperScale controller, which means we're dealing with a new storage architecture. OCZ claims this fixes the firmware footprint issues affecting the compatibility of the RevoDrive X2 on certain motherboards (Ed.: Before I called the compatibility issues to light in the RevoDrive X2 update, OCZ told me it was working with Silicon Image to help alleviate its BIOS footprint, but eventually had to concede it wasn't going to happen; I'm happy to see those issues addressed here with the SuperScale controller).
The version of the SuperScale controller used on the RevoDrive 3 X2 is a PCIe-to-SAS device. Other versions will enable support for different interfaces, but in this case, the design allows OCZ to forgo the need for an additional bridge chip. It's a straight shot from the SuperScale controller to the SandForce devices.
A simplified design isn't OCZ's only goal here. Performance is actually the real impetus behind this change. The more cost-effective approach to the RevoDrive X2 effectively introduced a bottleneck for future devices, as the Pericom bridge chip was limited to PCIe 1.1 data rates. This meant the device topped out at 1 GB/s of bidirectional traffic on a four-lane link. Naturally, that not an acceptable ceiling for the company's newer RevoDrive, which claims speeds in excess of 1 GB/s. The SuperScale controller closes that gap with a second-gen PCIe x4 link, which effectively doubles the bandwidth to 2.0 GB/s.
Introducing VCA 2.0
But wait, there's more. SuperScale's benefits aren't limited to a a cleaner PCB layout. The new controller also exposes OCZ's Virtual Controller Architecture (VCA) 2.0. This new virtualization layer reduces CPU overhead by implementing queue balancing algorithms, and it improves direct memory access.
Interestingly, OCZ doesn't talk about RAID 0 at all in reference to how it organizes the SandForce-based controllers behind the SuperScale hardware. And when we've asked about FIS-based switching in the past, the company denies it's using that technology, either. As evasively as possible, it simply claims to employ a proprietary array architecture based on a trademarked Queue Balancing Algorithm that utilizes both native and tagged command queuing, which balances drive loading and achieves what the company says is nearly linear scaling.
VCA 2.0 also adds TRIM and SCSI Unmap support; equivalent commands that help maintain performance and minimize write amplification. This is big news because, previously, it was not possible to issue those commands to drives in the equivalent of a RAID array. The operating system doesn't know which pages are on what drive, so it's simply not possible to manage invalid data pages in a striped array. VCA 2.0 is able to do that, though. In theory, it knows what is happening behind the scenes, allowing it to mark the correct LBAs when an operating system sends the command.
Unfortunately, although the RevoDrive 3 X2 does feature VCA 2.0, like its predecessor, it's still missing TRIM support. The SuperScale controller employs SCSI commands over PCIe, and TRIM is an ATA command. That helps explain why OCZ employs StorPort SCSI drivers. Alright, so what about the SCSI Unmap command? Unmap is to SCSI (or SAS, in this case) what TRIM is to the ATA command set. But Windows 7 doesn't include the Unmap command as part of its native driver stack. OCZ is working on a solution to this problem. For the time being, though, don't expect TRIM functionality.
