[Beowulf] Re: bonic projects on a cluster

[Robert G. Brown]

On Fri, 21 Mar 2008, David Mathog wrote:

> Carsten Aulbert wrote
>> Robert G. Brown wrote:
>>> What exactly is bonic/boinc?
>>
>> First hit with Google:
>>
>> http://boinc.berkeley.edu/
>
> I have a nit to pick with them.  Their web site implies (but does not
> explicitly state) that giving them access to your wasted computing
> resources costs you nothing, that everybody wins and nobody loses.  That
> is simply not true and is one reason why some sites ban the installation
> of these sorts of programs.  For some rough cost numbers (it was for a
> desktop, but the difference does not matter much here) see:
>
> http://saf.bio.caltech.edu/saving_power.html#costs
>
> My point being, with respect to the original poster, letting something
> like boinc run on a cluster for outside use could easily end up costing
> the cluster's owner many thousands of dollars a year.

I typically estimate $1/watt/year because in generaly you have to pay to
remove those watts once you release them into the wild of a server room,
and it adds anywhere from 20% to 40% to the cost of the power alone
depending on the COP of your AC unit and the outside temperature and so
on.  In the case of cluster users, one rarely turns off the nodes so the
issue is much more idle consumption vs non-idle consumption, a marginal
cost on the order of the $20-30 or so differential between his case 2
and his case 3, at my slightly higher power cost estimate because
cluster nodes would definitely require cooling.

As far as CRT vs flatpanel monitors, I'm not sure that I agree with this
site's conclusions, if one does NOT turn off the monitors, a running CRT
costs more like the full $85-90/year vs $30-35 (according to MY
kill-a-watt readings) for a CRT.  However, this is really a tricky
question as "green" monitors and computers may -- as noted -- really
turn off the monitor IF the monitor supports it.  Most flatpanels do.
Older CRTs do not.  CRTs are much more likely to draw at least a trickle
even when "off" to reduce the time lag for the electron gun to start
working.  When I replaced my OLD CRT monitors several years ago, I
assumed a 3-5 year payoff (not 20) and still feel that that is about
right, although flatpanels have gotten cheaper since then (the CRTs
they're replacing are also probably more efficient as well).  And at
this point the question is moot because you'd have to be crazy to buy a
CRT >>over<< a flatpanel when you have to replace a monitor -- the
differential marginal cost at my payoff rate of $50-$60/year will pay
for the difference in a very short time, and CRTs eat desktop, weigh a
ton, and are full of lead (where yes, the flatpanels have mercury and
both have arsenic so it is a matter of choosing your toxin).  Overall
the environmental kindness of flatpanels beats that of CRTs, I would
judge.

The final issue is that IF one signs up one's cluster AND one has an
application to contribute to the application pool, one can obtain the
usual dual advantage of sharing a large resource.  True, you pay for
somebody else's computation and energy and any heat related maintenance
and the risk associated with third parties running unknown applications
on your machines inside what might otherwise be a sound firewall.  If
that application turns out to be "an encryption engine for securely
distributing kiddie porn" -- overcoming the barriers that I'm sure are
there to this sort of thing being so distributed -- that latter risk my
not seem as trivial as otherwise it might.  Still, you in principle can
access far greater PEAK performance for your embarrassingly parallel
application in exchange for contributing your otherwise idle cycles --
an efficiency that many big cluster centers rely on today.  At fixed
maintenance and human costs, increasing duty cycle is pure return, and
it doesn't take much access to time to compensate for the additional
modest cost in energy relative to idle IF your work flow has the
appropriate pattern.

For example, if you run a simulation that requires 100 node-months to
complete, and then need to spend at least a month writing it up and
analyzing results before starting the next one, then contributing your
50 nodes in exchange for access to the boincweb (or whatever they call
it) MIGHT let you run for two weeks on 200 nodes and let others use your
50 nodes for six weeks.  You complete a work cycle in two months, able
to take a two week vacation in there.  Otherwise it takes you two months
to run your application and a third one to write it up.  There is plenty
of room for a win-win here.

So while I agree that the docs are misleading, that doesn't mean that a
real cost-benefit analysis will show that it is always a bad idea to
share resources.  Many grids and shared clusters do.  Aside from the
difficult-to-quantify risk factor, I'd argue that even the BOINC cluster
might be a worthwhile thing for CLUSTER people to participate in (just
as are many grids that do exactly the same thing without the SETI at Home
flavor).  Individual systems belonging to private individuals, well,
there I agree.  Even at a marginal differential cost of $30/year, they
should be upfront about this (and note that it might be much higher if
you DO turn off your systems at home every night -- I don't).

To me the real question is, what is the risk?  How much bandwidth does
it consume (a very definitely scarce resource on thin-pipe home ADSL
links)?  Do I trust a third party being granted access to my compute
resources inside a firewall?  What happens if that permits "bad things"
to happen inside my trusted domain, and who pays for fixing them or gets
fired for being stupid?  It's one thing to put an application up on my
kids probably already-virus-ridden WinXX boxes used primary for gaming,
another to put it on a system that might have passwords or other data
stored as "encrypted" data for a browser (encrypted in quotes as it is
trivial to decrypt), or that I use to access my bank.  If trolls take
over a system, they can read every keystroke.

I'd have to REALLY TRUST the maker of a sandbox before I let just anyone
play in it...

    rgb

>
> Regards,
>
> David Mathog
> mathog at caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>

-- 
Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977