Seagate has finally started shipping their new Barracuda XT 2TB drives that feature the new 6Gb/s SATA interface based on SATA Revision 3.x specifications. We had an early preview of the drive a few weeks ago and finally received a production level item for review. Just as important, we now have retail motherboards from Asus and Gigabyte featuring 6Gb/s capabilities. Well at least the Marvell 88SE9123 chipset included on both motherboards is theoretically capable of 6Gb/s operation.

Asus and Gigabyte took a different approach to implementing the Marvell 9123 chipset on their motherboards. Asus’s top of the line P7P55D Premium (a very good board by the way, full review coming shortly) features a PEX PLX8613 PCIe bridge chip that will convert four of the P55’s PCIe x1 lanes (250MB/s each) into two 500MB/s lanes. While still short of the maximum theoretical 600MB/s transfer speed of the SATA 6G specifications, it will provide more than enough burst bandwidth for the first generation 6G hard drives. The benefit is that the 6G capability is always on without affecting the other capabilities of the board and the same PLX chipset will be utilized for the upcoming USB 3.0 (NEC chipset) option on their upper-end boards.

Gigabyte’s implementation will be utilizing an x8 PCIe 2.0 from the Lynnfield processor that will obviously provide more than enough bandwidth but the drawback is that CF/SLI capabilities will be disabled as only a single x8 PCIe 2.0 lane will be available to the GPU. The benefit in this approach is that the SATA 6G switch is disabled/enabled in the BIOS by the user based upon need. Since an additional hardware chipset like Asus is utilizing is not required, it should result in a slightly lower board cost. Gigabyte informed us this week that all P55A-xxx boards will feature both SATA 6G and USB 3.0 capabilities. We will compare the performance of Gigabyte’s solution against Asus’ implementation shortly.

For today’s preview we are utilizing the Asus P7P55D Premium motherboard, 8GB of GSkill’s DDR3-1600 Ripjaw memory, Asus HD5870 video card, Corsair 750HX power supply, Windows 7 x64 RTM, Western Digital Caviar Black 2TB HD, WD VelociRaptor 300GB, Intel X25-M G2 160GB SSD, and Seagate’s Barracuda XT 2TB HD. We will have a full review of both hard drives shortly with additional performance results along with temperature and noise tests.

We are utilizing the Intel 160GB SSD for our OS drive and comparing the Seagate XT drive to its closest competitor, the WD Caviar Black, on both the Intel P55 and Marvell 9123 controllers. The P55 is limited to SATA 3Gb/s operational mode when running either drive, while the Marvell controller will be operated in SATA 6Gb/s mode with the Seagate drive and in fallback 3Gb/s mode with the WD drive. We are utilizing Marvell’s latest 1027 driver and Intel’s driver set in AHCI mode.

HD Tune 3.50 Results -

See something strange, the read burst rate of 2766MB/s and write burst of 2705MB/s are incredible for single drive performance but like most synthetic test results, they are not a true indication of actual platform performance. The reason for these “outstanding” results is that Marvell’s latest driver allocates (dynamically) a portion of system memory for transfer cache operations. Intel’s own Matrix Storage Manager and JMicron’s latest driver set also utilize a similar approach. In fact, Windows 7 implements a similar type of caching at the kernel level that makes these driver optimizations redundant in some ways.

Marvell is using aggressive algorithms in this particular driver to read and write as much possible data out of the RAM cache as possible before relying on transfers via the hard drive’s own internal cache or reading/writing from the platter or NAND. In earlier driver sets from Marvell, they requested that Window’s write-cache buffer flushing option be disabled in order to gain the maximum benefit from the 9128 controller. From all indications, the 1027 driver automatically disables this function as our performance results were the same with it disabled or enabled.

While performance was generally up to 10% better with this driver compared to the earlier 1018/1025 driver sets, we have a problem with the write-cache buffer flush being disabled automatically. There is a potential for data loss or even file table corruption if the buffers are not flushed and written properly if power is lost or there is another problem with the system. Of course that potential problem even exists with the out of box drivers and with write-caching enabled.

Our concern is that the Marvell driver might not recognize file table priorities in the same manner that the kernel does and those journal entries will be placed into the same general cache queue with other mundane requests. That could increase the likelihood of data or table corruptions above the normal risk posed with write caching. We are still waiting on additional information about the driver design and will update our findings in the final review.

AnandTech Storage Bench
Comments Locked


View All Comments

  • Transisto - Thursday, October 29, 2009 - link

    Port multiplier technology are often used for external raid unit over a single Esata.

    That would be a good use,

    As for the article,,,,,,, did someone at Anand really though a "nothing special" HDD would saturate 3Gb/s ? I wonder if even 5% of readers though so.
  • Captainbob001 - Thursday, October 29, 2009 - link

    I agree with the other writers on here, no need for sata 6gb/s. I believe we are at the mechanical limit with 3 gb/s sata with spinning platters. I believe we will see differences when SSD starts utilizing it. Right now drives in raid0 configuration get much better mb/s times than these tests.
  • Concillian - Friday, October 30, 2009 - link

    We aren't necessarily at any limit, just that controller throughput is always well ahead of hard drive throughput. This has been the case since we had hard drive controllers installed in the ISA bus. It's always some great new throughput of the controller that the hard drives can't take advantage of yet.

    It's still a good thing though, because you don't want to be in the case where you have a traffic jam on your 2 lane highway 100% of the time before you add a new lane. If that were the case all the drives now would be on PATA/100. It's much better when the controller leaps are not very exciting. The manufacturers are doing their job if controller throughput leaps aren't exciting.
  • zephyrprime - Thursday, October 29, 2009 - link


    PEX PLX8613 PCIe bridge chip that will convert four of the P55’s PCIe x1 lanes (250MB/s each) into two 500MB/s lanes.

    Pcie 1.0 was 250mb/s for each lane but isn't pcie 2.0 500mb/s for each lane? I would think a p55 board would have pcie 2.0, right?
  • kureshii - Thursday, October 29, 2009 - link

    IIRC the P55's PCIe lanes are 2.0-specced, but bandwidth-limited to PCIe 1.1 speeds to prevent choking up the DMI bus.
  • chizow - Thursday, October 29, 2009 - link

    That's also correct from what I've read, the P55 is PCIE 2.0 but the ICH10R is only PCIE 1.1. It could very well be an attempt to prevent choking up the DMI bus, but knowing Intel, I wouldn't doubt it if the decision was made so X58 and P55 wouldn't feature-compete with each other or offer a competitive advantage to outside solutions before they rolled out their own native SATA 6.0 and USB 3.0 solution. That's really why we're seeing all these workarounds to begin with, because Intel has been dragging their feet on adopting and implementing these specs.
  • JarredWalton - Thursday, October 29, 2009 - link

    The catch is that PCI-E 1.x is 250MB/s aggregate bandwidth, but half of that is upstream and half is downstream. So the 500MB/s figure for two PCI-E 2.0 lanes is correct in that the maximum rate to or from the drive would be 500MB/s.
  • Griswold - Thursday, October 29, 2009 - link

    Get a port multiplier and hook up 4 of them per channel - watch the bandwith put to good use, if you actually need it.

    Now do the same with all the other ports and you got a, for a desktop system, ridiculous amount of storage capacity with all disks capable of operating at their best sequential read/write performance.

  • yyrkoon - Thursday, October 29, 2009 - link

    A good SAS controller would trump port multipliers using 2 channels cascaded.
  • Griswold - Thursday, October 29, 2009 - link

    Yea, just that nobody is talking about SAS in this context...

Log in

Don't have an account? Sign up now