[Beowulf] RE: Capitalization Rates - How often should you replace a cluster? (resent - 1st sending wasn't posted ).

Nifty Tom Mitchell niftyompi at niftyegg.com
Sat Jan 17 17:57:17 PST 2009

On Thu, Jan 15, 2009 at 04:26:00PM -0500, Lechner, David A. wrote:
> Hello Again to all you Beowulf users!
> Similar to Doug Edline's poll....
> I was a subscriber in the late 1990s, but had to sign off the list for several years as my job changed.
> I used to follow many of your posts with such interest, and hope you oldtimers (and newer subscribers as well) are all doing well !!
> I'm working on a study on computer system recapitalization and thought this might make an excellent topic to engage on the Beowulf list.
> We expect the results to have broad implications for US Federal Government IT planning as well.
> I am researching the optimal life expectancy for a military program to plan for 

The rules may differ from the public to the private sector.

In the public sector there is an issue with write down for tax purposes
that comes to play.   These schedules are set by various tax rules and
decisions often made at purchase time.   Once written down to zero it
can make sense to invest in more hardware.  If you must operate with a
five year tax write down then you are effectively paying for the hardware
over a five year life and an upgrade three years later become much more
expensive than it would if a three year schedule was established at the
onset (and accepted by the tax man).

A federal contractor may have to factor in both public and private aspects.

In all cases there is a 'growth' need.   i.e. the demand for the cluster
resources will likely increase.   A computer room, with fixed air
conditioning and AC power  is much harder to upgrade than the machines
in the room.  i.e. It is hard to write down a building in three years
to justify an expansion.   This alone can justify a computer hardware
refresh in the same space.

Some military programs have very long contractual obligations that
involve qualification and acceptance cycles.   These obligations can
dominate any schedule so read or write this fine print with care.

It should be possible to mine the history of the top 500 computer system hardware to
draw some graphs that will establish key expectations.

Moore's law comes to play.   

Warranty is key..  fast disks tend to have a 3 year warranty.   Same for CPUs motherboards
and other stuff.   In my limited experience the warranty is set by product factory
and market life not so much by operating life time.   When hardware comes out of warranty
any analysis must 'spike' service and repair costs at the end of warranty.

An end user might purchase hardware with a five year purchase cycle.
A developer organization that needs to stay current and Moore's law is
often able to justify a yearly 50% hardware refresh cycle.

But "computer system recapitalization" is a financial phrase/ decision and has
financial accounting rules at its core i.e. financial and legal not
computational science.

Some grant money limits and bounds the life of hardware, some releases it at the
end of the grant to a 'pool'.

In terms of hardware, a cluster purchased today will do tomorrow what
it does today.  Thus some attention must be made to changes in care,
feeding, problem sets, competition, data sets and algorithms over time.
A company that has double the transactions and inventory after two
years of growth may need four (N=?) times the computation resource because
the algorithms to process future data sets are non linear.

A contractor would do well to have a staged hardware plan such that
development is done on hardware as current as you can get followed by
deployment, operation and refresh on much more slower and deliberate
schedules.  The agency may set a number of constraints that have
consequences.  One example is the FAA computer system upgrade plans.
By the time hardware is qualified it is all but impossible to purchase
and deploy.  The problems with the FAA air traffic control system problems
are well documented as are some of the homeland security computer system

In the next couple of years I also expect to see Green clauses in
federal contracts and laws that mandate or reward the replacement of hardware
when a sufficiently green alternative is available and deployed.  Yet another
constraint... that may constipate things even more.

	T o m  M i t c h e l l 
	Found me a new hat, now what?

More information about the Beowulf mailing list