<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: SAS drive performance</title>
	<link>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/</link>
	<description>Storage Solutions for Real World IT Professionals</description>
	<pubDate>Sat, 20 Mar 2010 12:19:51 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.2</generator>

	<item>
 		<title>Comment on SAS drive performance by: Vicc</title>
		<link>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-252850</link>
		<pubDate>Mon, 10 Nov 2008 04:41:10 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-252850</guid>
					<description>We are on the verge of taking a decision between a SAN storage or a SAS storage solution for a SAP ECC 6.0 on a blade configuration. The number of users at this point are only about 80 max. Would you be able to bench mark the performance difference between the 2 storage solutions also considering the huge price differential.</description>
		<content:encoded><![CDATA[	<p>We are on the verge of taking a decision between a SAN storage or a SAS storage solution for a SAP ECC 6.0 on a blade configuration. The number of users at this point are only about 80 max. Would you be able to bench mark the performance difference between the 2 storage solutions also considering the huge price differential.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on SAS drive performance by: Vic</title>
		<link>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-84593</link>
		<pubDate>Thu, 01 Nov 2007 12:12:27 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-84593</guid>
					<description>I would have made the same decision between the 6 and 8 drives as to the maximum sustained output being bottle necked by the rest of the subsytem. But you are forgetting performance when the load is not at the maximum of a the total system like when in a database you are performing a series of transactions which are not running in parallel but are sequential. You are not reaching anywhere near the capacity of the system. What you have essentialy are small data requests and the 50% speed advantage in seek time and latency of each 15K drive makes the difference. The difference is though you can still support the same number of users in both setups but your 12 hour nightly job will take only 9 hours with the 15K drives.</description>
		<content:encoded><![CDATA[	<p>I would have made the same decision between the 6 and 8 drives as to the maximum sustained output being bottle necked by the rest of the subsytem. But you are forgetting performance when the load is not at the maximum of a the total system like when in a database you are performing a series of transactions which are not running in parallel but are sequential. You are not reaching anywhere near the capacity of the system. What you have essentialy are small data requests and the 50% speed advantage in seek time and latency of each 15K drive makes the difference. The difference is though you can still support the same number of users in both setups but your 12 hour nightly job will take only 9 hours with the 15K drives.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on SAS drive performance by: Tom</title>
		<link>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-51522</link>
		<pubDate>Fri, 27 Apr 2007 12:32:16 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-51522</guid>
					<description>Mike, let me make sure I understand what you're saying...

With six drives on a PCI RAID card you're able to get close to the theoretical max - about 6000 IOPS.  But with those same drives behind an iSCSI controller performance drops to 2200 IOPS.  I guess that makes sense.  Your iSCSI controller must not be doing a very good job of processing the TCP/IP code stack.  This is a ton of code, and the only way to make it faster is with a high-end x86 CPU or a TCP/IP offload engine, i.e., a TOE.

BTW, I assume you're testing with short random reads.  Random writes to a RAID-5 will be a lot slower - about 1/4 the speed - because of the read/modify/writes.

You also mention that you're getting just 1050 IOPS with plain ol' FC drives.  Is that right?  Or is there a RAID controller involved.  That's a very low number.  The FC stack is much more efficient than iSCSI, and it's always offloaded to hardware, so it's hard to imagine why FC would be slower than iSCSI.

Can you give me more info?  Maybe we can work through this to understand where the bottlenecks are.

Thanks,
TT</description>
		<content:encoded><![CDATA[	<p>Mike, let me make sure I understand what you&#8217;re saying&#8230;</p>
	<p>With six drives on a PCI RAID card you&#8217;re able to get close to the theoretical max - about 6000 IOPS.  But with those same drives behind an iSCSI controller performance drops to 2200 IOPS.  I guess that makes sense.  Your iSCSI controller must not be doing a very good job of processing the TCP/IP code stack.  This is a ton of code, and the only way to make it faster is with a high-end x86 CPU or a TCP/IP offload engine, i.e., a TOE.</p>
	<p>BTW, I assume you&#8217;re testing with short random reads.  Random writes to a RAID-5 will be a lot slower - about 1/4 the speed - because of the read/modify/writes.</p>
	<p>You also mention that you&#8217;re getting just 1050 IOPS with plain ol&#8217; FC drives.  Is that right?  Or is there a RAID controller involved.  That&#8217;s a very low number.  The FC stack is much more efficient than iSCSI, and it&#8217;s always offloaded to hardware, so it&#8217;s hard to imagine why FC would be slower than iSCSI.</p>
	<p>Can you give me more info?  Maybe we can work through this to understand where the bottlenecks are.</p>
	<p>Thanks,<br />
TT
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on SAS drive performance by: Mike</title>
		<link>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-50138</link>
		<pubDate>Sat, 21 Apr 2007 18:49:59 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-50138</guid>
					<description>Hi Tom,  
I am working on quantifying the differences between Fiber SCSI and SAS drives and what we can expect when we start using them in conjunction or as a replacement of their bulkier predecessors connected to a SAN.  I was hoping, you might be willing to consider for a moment how a SAN might be able to overcome some of these bottlenecks you mentioned &quot;drive subsystem to the controller, application, OS, etc., &quot; and then equate that to the summary numbers you put together related to the differences between 10k and 15k in how they seem to be really close in IOPS as quoted:

The 15K array would produce 720MB/s and 1050 IOPS, while the 10K array would produce 704MB/s and 1000 IOPS. That’s pretty close, so you’ll probably want to base your buying decision on the price of the drives, the number of drive bays, the total required capacity, etc.

The reason I ask to differenciate is that I have been able to generate on a SAN using iSCSI over 2,200 IOPS with 6 SAS 15k using raid 5 via and zero caching, I get closer to your numbers inside a server connected to a 64bit PCIe card.  The same test via iSCSI on a SAN 6 fiber SCSI 15k drives I get almost exactly 1050 IOPS without utilizing the cache.  I know these numbers or horribly crude, just wanted to give you why I think there might be a big difference between the 2 and to see your reaction to the potential of eliminating the bottlenecks mentioned above.

Thanks,
Mike</description>
		<content:encoded><![CDATA[	<p>Hi Tom,<br />
I am working on quantifying the differences between Fiber SCSI and SAS drives and what we can expect when we start using them in conjunction or as a replacement of their bulkier predecessors connected to a SAN.  I was hoping, you might be willing to consider for a moment how a SAN might be able to overcome some of these bottlenecks you mentioned &#8220;drive subsystem to the controller, application, OS, etc., &#8221; and then equate that to the summary numbers you put together related to the differences between 10k and 15k in how they seem to be really close in IOPS as quoted:</p>
	<p>The 15K array would produce 720MB/s and 1050 IOPS, while the 10K array would produce 704MB/s and 1000 IOPS. That’s pretty close, so you’ll probably want to base your buying decision on the price of the drives, the number of drive bays, the total required capacity, etc.</p>
	<p>The reason I ask to differenciate is that I have been able to generate on a SAN using iSCSI over 2,200 IOPS with 6 SAS 15k using raid 5 via and zero caching, I get closer to your numbers inside a server connected to a 64bit PCIe card.  The same test via iSCSI on a SAN 6 fiber SCSI 15k drives I get almost exactly 1050 IOPS without utilizing the cache.  I know these numbers or horribly crude, just wanted to give you why I think there might be a big difference between the 2 and to see your reaction to the potential of eliminating the bottlenecks mentioned above.</p>
	<p>Thanks,<br />
Mike
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on SAS drive performance by: Tom</title>
		<link>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-12637</link>
		<pubDate>Thu, 14 Sep 2006 20:55:46 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/07/26/sas-drive-performance/#comment-12637</guid>
					<description>Danny, I checked what I wrote.  I said 2.1GB/s, not 2.1Gb/s.  I got to this number by simply multiplying 270MB/s by 8 to get 2160MB/s, and divided that by 1024 to get 2.1GB/s.

Is that right, or did I screw something up?

Thanks for reading!</description>
		<content:encoded><![CDATA[	<p>Danny, I checked what I wrote.  I said 2.1GB/s, not 2.1Gb/s.  I got to this number by simply multiplying 270MB/s by 8 to get 2160MB/s, and divided that by 1024 to get 2.1GB/s.</p>
	<p>Is that right, or did I screw something up?</p>
	<p>Thanks for reading!
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
