<?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: BYO Supercomputer. Worth It?</title>
	<atom:link href="http://insidehpc.com/2009/02/02/byo-supercomputer-worth-it/feed/" rel="self" type="application/rss+xml" />
	<link>http://insidehpc.com/2009/02/02/byo-supercomputer-worth-it/</link>
	<description>HPC News Without the Noise for Supercomputing Professionals &#124; insideHPC</description>
	<lastBuildDate>Sun, 09 Jun 2013 01:54:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
	<item>
		<title>By: Bruce Allen</title>
		<link>http://insidehpc.com/2009/02/02/byo-supercomputer-worth-it/#comment-145218</link>
		<dc:creator>Bruce Allen</dc:creator>
		<pubDate>Thu, 05 Feb 2009 00:00:30 +0000</pubDate>
		<guid isPermaLink="false">http://insidehpc.com/?p=3639#comment-145218</guid>
		<description>Hi rpl,

It&#039;s easy for me to account for the &#039;hidden labor costs&#039; since they are not at all hidden!  I see every cent of them on my monthly and annual budgets.

I have two full-time professional system administrators (Carsten Aulbert and Henning Fehrmann).  Both have PhDs in physics, and both spent a number of years as graduate students using clusters and helping with their care and feeding.  Carsten and Henning are assisted by a handful of ruthlessly exploited undergraduate assistants.  Total labor costs per unit time are between ten and fifteen percent of the amount that the cluster depreciates in the same period!  They are less than ten percent of the cluster depreciation cost plus the electrical costs.

Note that even a cluster from a BNV would require at least one full-time sysadmin.  And you&#039;d need a backup if that person ever wanted to take a vacation, have some family time, etc.

Cheers,
     Bruce Allen</description>
		<content:encoded><![CDATA[<p>Hi rpl,</p>
<p>It&#8217;s easy for me to account for the &#8216;hidden labor costs&#8217; since they are not at all hidden!  I see every cent of them on my monthly and annual budgets.</p>
<p>I have two full-time professional system administrators (Carsten Aulbert and Henning Fehrmann).  Both have PhDs in physics, and both spent a number of years as graduate students using clusters and helping with their care and feeding.  Carsten and Henning are assisted by a handful of ruthlessly exploited undergraduate assistants.  Total labor costs per unit time are between ten and fifteen percent of the amount that the cluster depreciates in the same period!  They are less than ten percent of the cluster depreciation cost plus the electrical costs.</p>
<p>Note that even a cluster from a BNV would require at least one full-time sysadmin.  And you&#8217;d need a backup if that person ever wanted to take a vacation, have some family time, etc.</p>
<p>Cheers,<br />
     Bruce Allen</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Hahn</title>
		<link>http://insidehpc.com/2009/02/02/byo-supercomputer-worth-it/#comment-144494</link>
		<dc:creator>Mark Hahn</dc:creator>
		<pubDate>Mon, 02 Feb 2009 22:54:20 +0000</pubDate>
		<guid isPermaLink="false">http://insidehpc.com/?p=3639#comment-144494</guid>
		<description>no, it&#039;s not much about labor costs, though the pop media loves to fixate on that (will pay pizza to build my supercomputer!)  the real issues are more subtle - things like how Big Name Vendors (BVNs) only want to build clusters with certain designs or components, or how a BNV&#039;s product lines might be tuned for a different kind of computing than you have.  for instance, big Gb clusters are fairly unusual - people who want big parallel clusters tend to also want fast interconnect.

sure, you don&#039;t want your physicists spending weeks unboxing motherboards, so you get someone to do it for you.  but a local low-overhead whitebox vendor will do as good a job as a BNV.  sure, you want to be careful choosing your parts, and doing so requires some attention.  with a BNV, you don&#039;t get to choose, but can expect them to resolve issues that might arise through a support contract.  but BNVs can&#039;t guarantee that everything will work perfectly either, not much more than a no-name.  heterogeneity is not something inherent to DIY or absent from the BNV approach.

besides more flexibility in config/design, BNVs also tend to lag in time - you&#039;ll usually be able to get a processor, chipset. interconnect or disk earlier on the open market.

if you really want a turnkey cluster, BNV may be a very good idea, since it means you don&#039;t deal with matching your mpi to your driver to your nic to your switch, etc.  or even Small Name Vendors, which tend to specialize in HPC more.  but since the whole stack is open and/or commoditized now, you _can_ DIY and with some care, not spend much time or effort getting it right.  in that sense, the article&#039;s mention of gigabit is right on target: an interconnect that&#039;s by far the most standardized and widely understood, with low support costs, not just upfront prices...</description>
		<content:encoded><![CDATA[<p>no, it&#8217;s not much about labor costs, though the pop media loves to fixate on that (will pay pizza to build my supercomputer!)  the real issues are more subtle &#8211; things like how Big Name Vendors (BVNs) only want to build clusters with certain designs or components, or how a BNV&#8217;s product lines might be tuned for a different kind of computing than you have.  for instance, big Gb clusters are fairly unusual &#8211; people who want big parallel clusters tend to also want fast interconnect.</p>
<p>sure, you don&#8217;t want your physicists spending weeks unboxing motherboards, so you get someone to do it for you.  but a local low-overhead whitebox vendor will do as good a job as a BNV.  sure, you want to be careful choosing your parts, and doing so requires some attention.  with a BNV, you don&#8217;t get to choose, but can expect them to resolve issues that might arise through a support contract.  but BNVs can&#8217;t guarantee that everything will work perfectly either, not much more than a no-name.  heterogeneity is not something inherent to DIY or absent from the BNV approach.</p>
<p>besides more flexibility in config/design, BNVs also tend to lag in time &#8211; you&#8217;ll usually be able to get a processor, chipset. interconnect or disk earlier on the open market.</p>
<p>if you really want a turnkey cluster, BNV may be a very good idea, since it means you don&#8217;t deal with matching your mpi to your driver to your nic to your switch, etc.  or even Small Name Vendors, which tend to specialize in HPC more.  but since the whole stack is open and/or commoditized now, you _can_ DIY and with some care, not spend much time or effort getting it right.  in that sense, the article&#8217;s mention of gigabit is right on target: an interconnect that&#8217;s by far the most standardized and widely understood, with low support costs, not just upfront prices&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rpl</title>
		<link>http://insidehpc.com/2009/02/02/byo-supercomputer-worth-it/#comment-144413</link>
		<dc:creator>rpl</dc:creator>
		<pubDate>Mon, 02 Feb 2009 17:44:37 +0000</pubDate>
		<guid isPermaLink="false">http://insidehpc.com/?p=3639#comment-144413</guid>
		<description>Academics don&#039;t have to account for labor costs when they assess the total cost of their clusters.  If that is your situation, then it makes a lot of sense to shift costs from vendors, who charge actual money and therefore show up in the project budget, to faculty and graduate students, who don&#039;t.  If, on the other hand, you have to charge labor costs against the cluster project, then you see that the time you spend chasing down deals on pricewatch (and dealing with hardware that isn&#039;t *quite* identical between nodes) quickly eats up any savings you might have hoped to gain.

Which method is better?  In effect Allen is hiring astrophysicists to do system integration work, which is likely to be less efficient than farming that work out to people who specialize in it.  Moreover, much of the hidden cost is borne by his graduate students in the form of longer working hours and longer time to graduation, which seems a bit exploitative to me (full disclosure: I&#039;m a PhD in astrophysics who spent his share of time in graduate school scrounging up computing resources).  For those reasons, I lean toward fully accounting for all of the costs involved in building a system, including those that are otherwise hidden in your routine payroll expenses.</description>
		<content:encoded><![CDATA[<p>Academics don&#8217;t have to account for labor costs when they assess the total cost of their clusters.  If that is your situation, then it makes a lot of sense to shift costs from vendors, who charge actual money and therefore show up in the project budget, to faculty and graduate students, who don&#8217;t.  If, on the other hand, you have to charge labor costs against the cluster project, then you see that the time you spend chasing down deals on pricewatch (and dealing with hardware that isn&#8217;t *quite* identical between nodes) quickly eats up any savings you might have hoped to gain.</p>
<p>Which method is better?  In effect Allen is hiring astrophysicists to do system integration work, which is likely to be less efficient than farming that work out to people who specialize in it.  Moreover, much of the hidden cost is borne by his graduate students in the form of longer working hours and longer time to graduation, which seems a bit exploitative to me (full disclosure: I&#8217;m a PhD in astrophysics who spent his share of time in graduate school scrounging up computing resources).  For those reasons, I lean toward fully accounting for all of the costs involved in building a system, including those that are otherwise hidden in your routine payroll expenses.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
