SATA 6G shows up early

The SATA 6G Technology

In August we took an early look at the ASUS P7P55D Premium motherboard, a P55 chipset offering that supports the new Intel Lynnfield processors under the Core i7/i5 brands.  You might remember that ALL of the early P55 motherboards were going to support SATA 6G but the feature was suddenly pulled on almost every board due to mysterious performance issues.  The P7P55D Premium was one of the only boards that retained the feature thanks to some additional hardware used by ASUS engineers.  

Previous SATA 6G implementations used the Marvell 9123 chip that interfaced with the P55 chipset through a single PCIe 1.0 x1 lane - a connection that only had a 250 MB/s data rate.  That data rate is already lower than the 300 MB/s rated specs on SATA-II and is obviously much less than the 600 MB/s rated on the SATA 6G standard.  But because the Marvell 9123 could only support a connection of a SINGLE PCIe x1 lane, and because the P55 chipset only offers PCIe 1.0 connections, there was nothing motherboard vendors could do with the hardware provided.

The answer ASUS came up with involved a new chip: the PEX PLX8613 PCIe bridge chip.  The PLX8613 allowed the Marvell 9123 to connect to it via a single PCIe 2.0 x1 lane (2.0 being the key here) for a maximum bandwidth of 500 MB/s.  That is still not has high as the 600 MB/s limit of SATA 6G itself but is definitely a boost over the 250 MB/s mentioned above.  The PLX chip then connects to the P55 chipset via x4 lanes of PCIe 1.0 that provide as much as a 1 GB/s of bandwidth; more than enough to cover the 500 MB/s coming from the Marvell 9123. 

After getting all that information and then seeing these benchmarks above (provided by ASUS), it's easy to see how a storage-crazed world like the one we live in now would be very excited about SATA 6G technology.  Getting over 344 MB/s burst speed would be a huge advantage for 6G-based hard drives over SATA-II drives. 

The ASUS P7P55D Premium Motherboard

I already mentioned that the first motherboard to make this technology available was the P55-based ASUS P7P55D Premium that you can find online today.  Also coming soon from ASUS are other P55 offerings as well as an X58 offering that implement BOTH SATA 6G technology as well as USB 3.0 technology. 

Here you can see the two white SATA ports are the ones powered by the Marvell 9123 and the PLX bridge chip to support SATA 6G speeds.  The motherboard does come with specific SATA 6G cables but in my testing there was NO difference in performance using standard SATA cables in place of them.

This is the PLX bridge chip that takes the Marvell 9123's deficiencies (only being able to connect to a single PCIe lane) and the P55's deficiencies (only having PCIe 1.0) and makes a suitable fix to get SATA 6G technology working today.

I should note that there are some other implementations of SATA 6G coming on other P55 motherboards that don't create a positive situation for enthusiasts and gamers.  One such option will apparently require use of some of the lanes of PCIe 2.0 coming from the Lynnfield CPU; that would force the primary graphics card to run at x8 PCIe 2.0 speed and would not allow for multi-GPU configurations on said motherboard.  We are still getting details on what both Gigabyte and MSI are doing for SATA 6G in the future, so stay tuned!

There is one odd quick to this hard drive we wanted to note: it makes odd squeaking sounds like a mouse is in our case.  Check out the video below. 

It didn't seem to affect performance that we could tell, but we are not sure if this is a "normal" sound for this drive yet.

• P55 Chipset (SATA-II, 3.0 Gb/s)
• Marvell 9123 Driver 1008 (SATA 6G, 6.0 Gb/s)
• Marvell 9123 Driver 1027 (SATA 6G, 6.0 Gb/s)

The two drivers had very different results as you will see below on not only our Barracuda XT 2.0 TB hard drive, but also on the Barracuda 7200.11 1.5 TB hard drive and the Intel X25-M 80GB SSD as well.  The reason for this difference is that the 1027 driver implements a new caching system that uses system memory to attempt to improve performance.  Here is a better explanation from resident PCPer storage expert, Allyn Malventano:

----

To kick this off, lets quickly go over the different types of caching:

• Read Cache: There are different types of caching, but the simplest to explain is where data read from the device is passed through memory in a 'first in first out' basis. If a location is re-read and has not been altered since the last read attempt, and if that data is still in the cache, it is called a 'hit' and the cache provides the data to the system (much faster than the hard disk could have). If the requested data is not in the cache it is called a 'miss' and data retrieval takes place the old (slow) way.
• Write-Through Cache: Writes pass through the cache but are immediately and synchronously written to the disk. Some of the data remains in the cache, and in the case where new writes are identical to what is already on the disk, a write does not need to take palce. This is to some extent similar to how the read cache works.
• Write-Back Cache: A more agressive method of write caching where writes are not required to immediately sync up with the contents of the disk. If the data flows from the system faster than it can be written to the disk, the cache will fill with a backlog of data to be written out to the disk. The hard disk will basically 'fall behind'. When the system is done writing, the cache will then be able to catch up and finish writing the changes to the disk.

The new Marvell driver allocates a portion of system RAM to perform caching duties.  A cache is simply a buffer.  Hard drives have internal caches that are considerably faster than the physical seek time of the disk itself, but are still limited by the speed of the interface (i.e. SATA).  An additional cache on the 'other side' of the interface - in this case within the driver running on the host system, may provide additional performance in some situations, but can also introduce potential complications and drawbacks.  It is also redundant in that Windows already implements the same types of caching at the kernel level (above the driver):

From the above you will see that the greater the level of enabled caching, the more risk of potential data loss you are willing to accept in the case where power fails (or the system crashes) during a write operation.  Even with the above options cranked to the max, there will still be operations that take priority, such as file table and journal entries, as the data within a file is not as important as the means to find the file in the first place.  The above settings are only for write caching.  Windows will by default donate unused RAM to cache up to several GB of reads.

Now to analyze what type of caching this new Marvell driver is implementing.  Burst speeds are measured by writing a small bit of data to the drive and immediately requesting it back, sometimes several times in succession.  This usually results in a cache hit at the hard drive's own internal read cache.  Since most hard drive cache operates faster than the interface, the resulting burst speed typically comes out to right around the speed of the interface (i.e. SATA).  If you add another cache on the other side of the interface, you will see cache hits taking place at the new higher speed.  In the case of the new Marvell driver, that speed is based on system RAM minus driver overhead.  Aside from the additional use of system resources, this type of read caching is generally a performance booster with no significant drawbacks.

That said, we did find a catch with Marvell's cache implementation.  Something was awry with our HDTune results:

That spike at the start of the write pass suggests write-back caching is taking place within the Marvell driver.  If this is the case, it is significant, as the user is never presented with any warnings of potential data loss.  Even worse - there is no user selectable option to disable or modify the write caching policy.  If you have the new driver, you are stuck with a type of write caching that would normally require a battery backup to be considered safe.  A final note is that since the Marvell driver is not as aware as the kernel of what type of data is being written, file table entries given priority by the kernel would have to wait in line like the rest of the data passing through the Marvell driver cache.  This means not only is there a risk of file data loss the user may not be willing to accept, there is also the potential for file table corruption and more major types of data loss that happen when NTFS journal entries are cached without the kernels knowledge.

Click here for the Detailed Review