[8014] in Release_7.7_team
Re: Summary of past concerns about using idle cycles?
daemon@ATHENA.MIT.EDU (Anders Kaseorg)
Mon Apr 7 22:26:47 2014
Date: Mon, 7 Apr 2014 22:26:38 -0400 (EDT)
From: Anders Kaseorg <andersk@MIT.EDU>
To: Jonathan D Reed <jdreed@MIT.EDU>
cc: "release-team@mit.edu" <release-team@MIT.EDU>
In-Reply-To: <89CE415D-A9DD-4A90-AB64-0DF295703789@mit.edu>
Message-ID: <alpine.DEB.2.02.1404072219260.52840@all-night-tool.MIT.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Tue, 8 Apr 2014, Jonathan D Reed wrote:
> Can someone remind me of the historical objections to making use of idle
> cycles on cluster workstations? I’ve gotten a proposal from some 6.824
> students to make use of idle workstations for a distributed cluster, and
> I want to make sure I fully understand the concerns to see how we might
> address them all.
>
> Things I can think of off the top of my head:
> - security concerns (in both directions — i.e. public root permits
> sketching on memory and processes; also ensuring the job can’t
> compromise the integrity of the workstation)
> - nodes gracefully going online/offline
> - console users always taking priority
> - ensuring desync’d updates still occur in a timely manner
> - allowing some machines to opt-out (e.g. podium machines should not go
> into full jet-engine mode during lecture because is attempting to find
> MD5 collisions)
Also worth considering:
- energy consumption
- extra heat
- fan noise (If you think one jet engine in a lecture hall is bad, imagine
sixty jet engines in a cluster…)
- Is someone in charge of deciding that finding MD5 collisions for a class
project is okay, while mining bitcoins isn’t?
Anders