SATA Controller Performance

Both NVIDIA and Intel offer support for NCQ in their SATA controllers, and given our recently renewed interest in NCQ performance, we decided to find out if there were any performance differences between the two SATA controllers.  However, as we've found in the past, coming up with tests that stress NCQ is quite difficult. Luckily, there is a tool that works perfectly for controlling the type of disk accesses that you want to test: iometer. 

An Intel developed tool, iometer allows you to control the size, randomness and frequency, among other things, of disk accesses, and measure performance using data generated according to these specifications.  Given that NCQ truly optimizes performance when disk accesses are random in nature, we decided to look at how performance varied according to what percentage of the disk accesses were random.  At the same time, we wanted the tests to be modeled on a multitasking desktop system, so we did some investigation by setting up a computer and running through some of our multitasking scenarios on it. 

What we found is that on modern day hard drives, the number of outstanding IOs (IO Queue Depth) is rarely above 10 on even a moderately taxed system.  Only when you approach extremely heavy multitasking loads (heavier than anything that we've ever tested) do you break into queue depths beyond 32.  So, we put together two scenarios, one with a queue depth of 8 and one with a queue depth of 32 - the latter being more of an extreme condition. 

In each scenario, we sent the drives a series of 64KB requests, 75% of which were reads, 25% were writes; once again, derived from monitoring our own desktop usage patterns. 

We then varied the randomness of disk accesses from 0% (e.g. 100% sequential) up to 100% (0% sequential reads/writes).  In theory, the stronger NCQ controllers will show better performance as the percentage of random accesses increases.  We reported both Average IOs per Second and average IO response time (how long accesses took to complete on average):

With a queue depth of 8, the two SATA controllers offer virtually identical performance.

Looking at latency, Intel actually offers a very slight performance advantage here - nothing huge, but it's definitely there.

The results get much more interesting as we increase the queue depth to 32:

Here, NVIDIA starts to pull away offering close to a 20% increase in average IOs per second as the access patterns get more random (e.g. as more applications running at the same time start loading down the hard disk). 

What's truly impressive, however, is the reduction in average response time - up to a 90ms decrease in response time, thanks to NVIDIA's superior NCQ implementation. 

But stepping back into reality, how big of a difference NVIDIA's NCQ implementation makes depends greatly on your usage patterns. Heavy multitaskers that are very IO bound will notice a performance difference, while more casual multitaskers would be hard pressed to find any difference.  For example, Intel was actually faster than NVIDIA in our gaming multitasking scenarios from our dual core investigation.

Workstation Performance - ATI GPU SLI Performance
Comments Locked

96 Comments

View All Comments

  • stevty2889 - Saturday, April 16, 2005 - link

  • PeteRoy - Saturday, April 16, 2005 - link

    Stevty, if you really work for Intel you would know that Intel has a specification for what case to use with 3ghz/90nm processors.

    Here's a link:

    http://support.intel.com/support/processors/pentiu...
  • stevty2889 - Saturday, April 16, 2005 - link

    I think Questar is cramitpals nemisis..
    Quester I work for Intel, even Intel knows that the prescott has heat issues, and that for most applications right now, AMD is winning in price/performance...having to use water cooling to get a chip to run at stock speed without throttling is a pretty major heat issue if you ask me..even a thermalright XP-120 couldn't keep my 3.4 prescott from throttling at stock speeds, my 3.2 ES, and 2.8 didn't have as much of an issue, but some of the prescotts are running WAY too hot..
  • stephenbrooks - Friday, April 15, 2005 - link

    ^^ I was just searching all the previous 81 comments for the word "Soviet" in disbelief. Guess we've spoiled it now though.
  • Houdani - Friday, April 15, 2005 - link

    Anyone else miss the days of only bickering about:
    "The message is clear..."
    "First!"
    "In Soviet Russia..."
    Ah, memories. Feels like only yesterday.
  • fitten - Friday, April 15, 2005 - link

    Well... it would be pretty stupid of a company to not roll with the punches. I'd rather see them shape their direction as they have that be rigid (which means they wouldn't compete anymore).

    The reason no one jumped at 64bits in x86 land is because the volume of 64bit processors out there wasn't worth the effort. So... 100,000 64bit systems are out there... compare that with over 1000X that number of 32bit only systems. Which would you target if you were developing software? Now that 64bit will be mainstream, the market will move that way.

    In addition, mom/pop won't see any real benefit from 64bit. There will be marginal speed benefits to having more general purpose registers, but that would have been the case in 32bit land. I doubt they are doing things that require more than 4G of memory, either. The only other real speed benefits are when you are manipulating 64bit integers and there just aren't that many apps that mom/pop use that need that kind of range.

    I like AMD as well (all 5 of my personal desktops have them) but I'm not a blind follower. It's nice to be excited about technology but don't let it become a religion. If Intel released a better processor than AMD, I wouldn't hesitate to buy those instead.
  • Questar - Friday, April 15, 2005 - link

    Jeez, how many times do I have to repeat myself?

    We don't qualify processors, we qualify systems!

    Let me provide you with some links:

    http://h10010.www1.hp.com/wwpc/us/en/sm/WF02d/1245...

    http://www1.us.dell.com/content/products/category....

    http://www-132.ibm.com/webapp/wcs/stores/servlet/C...

    Do you see any AMD based business computer lines from these vendors?

    I'll stop you from having to post a link to Gateway, or somebody even smaller. They don't provide the services we contract for when we buy systems. Again, it's about the entire system, and everything that is wrapped around it.
  • mlittl3 - Friday, April 15, 2005 - link

    #78,

    And I assume that means that in your companies infinite wisdom that AMD processors could never be qualified in such a way and even though AMD has tried to convince your company otherwise, you don't think it is the right time to stop kissing Intel's ass.

    You don't by any chance work for a little company called Dell do you?
  • Questar - Friday, April 15, 2005 - link

    Funny, I never said anything about Intel or AMD product roadmaps.

    I said vendor product roadmaps.

    For example, I know exactly when my current desktop system is going end of life, and I know what product will replace it. We will have POC units in our labs for our desktop engineering people to work with about 90 days before GA. They will buld the OS image for the systems, do extensive application testing, standardize the bios version and config (our PC vendor ships our systems preconfigured to our specifications). Everything that's different about the system from a technician standpoint will be documented. (Such as if you replace a system board, this is how to program the bios with the systems' asset tag). Our management systems will be updated with any changes that are needed to support the new systems.

    In the interim, I'll stock up with about a thousand units of the old system to bridge over the transition (four week supply). This is SOP for any large corporation. Every Fortune 500 that has centralized IT functions do it this way.

    This allows me to plan the resources that are needed to transition to the new system.
  • smn198 - Friday, April 15, 2005 - link

    Questar is a troll. See http://www.google.co.uk/search?sourceid=mozclient&...

    Tries to stir up trouble all the time. Best to just ignore such people.

Log in

Don't have an account? Sign up now