<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Architecting Internet Data Centers &#8211; Pt. I</title>
	<atom:link href="http://storagemojo.com/2006/07/24/architecting-internet-data-centers-pt-i/feed/" rel="self" type="application/rss+xml" />
	<link>http://storagemojo.com/2006/07/24/architecting-internet-data-centers-pt-i/</link>
	<description>Data storage info &#38; analysis</description>
	<lastBuildDate>Tue, 07 Sep 2010 17:31:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Robin Harris</title>
		<link>http://storagemojo.com/2006/07/24/architecting-internet-data-centers-pt-i/comment-page-1/#comment-4371</link>
		<dc:creator>Robin Harris</dc:creator>
		<pubDate>Thu, 27 Jul 2006 05:11:30 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=201#comment-4371</guid>
		<description>Ah, the clock vs instruction set issue so simple when you explain it. Thanks. 

Specialized hardware is, in my view, like aspirin: good for temporary relief. If it isn&#039;t going to go into volume production, it will rarely either get the price/performance or the management support that makes it usuable for the &quot;many-small&quot; environment I&#039;ll be writing about next - despite what I said in Pt II.</description>
		<content:encoded><![CDATA[<p>Ah, the clock vs instruction set issue so simple when you explain it. Thanks. </p>
<p>Specialized hardware is, in my view, like aspirin: good for temporary relief. If it isn&#8217;t going to go into volume production, it will rarely either get the price/performance or the management support that makes it usuable for the &#8220;many-small&#8221; environment I&#8217;ll be writing about next &#8211; despite what I said in Pt II.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim Gray</title>
		<link>http://storagemojo.com/2006/07/24/architecting-internet-data-centers-pt-i/comment-page-1/#comment-4369</link>
		<dc:creator>Jim Gray</dc:creator>
		<pubDate>Thu, 27 Jul 2006 04:52:46 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=201#comment-4369</guid>
		<description>The reason we switched from instructions to clocks was explained somewehere  in there -- Amdahl did it in terms of instructiosn, but with super-scalear piplelined machines the only thing you can easily measure is clocks (and CPI varies from 1-4 in modern processors for vaious workloads and clock speeds). 
The complication is that FC and now iSCSI have TOE (tcp offload engines) that move the instrucitons to the adapter (much as SCSI controllers do) so the real downside of SAN is cost of specialize hardware (low volume hardware compared to Direct Attach Disk) and management complexity of SAN.</description>
		<content:encoded><![CDATA[<p>The reason we switched from instructions to clocks was explained somewehere  in there &#8212; Amdahl did it in terms of instructiosn, but with super-scalear piplelined machines the only thing you can easily measure is clocks (and CPI varies from 1-4 in modern processors for vaious workloads and clock speeds).<br />
The complication is that FC and now iSCSI have TOE (tcp offload engines) that move the instrucitons to the adapter (much as SCSI controllers do) so the real downside of SAN is cost of specialize hardware (low volume hardware compared to Direct Attach Disk) and management complexity of SAN.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
