[8013] in Release_7.7_team
Re: Summary of past concerns about using idle cycles?
daemon@ATHENA.MIT.EDU (Alex Chernyakhovsky)
Mon Apr 7 22:21:12 2014
MIME-Version: 1.0
In-Reply-To: <89CE415D-A9DD-4A90-AB64-0DF295703789@mit.edu>
Date: Mon, 7 Apr 2014 22:21:01 -0400
Message-ID: <CAB18ysrLqVG_uaazKMosvFDMUTUrDp+U+Npo5=7BKZ0G75XxRQ@mail.gmail.com>
From: Alex Chernyakhovsky <achernya@MIT.EDU>
To: Jonathan D Reed <jdreed@MIT.EDU>
Cc: "release-team@mit.edu" <release-team@MIT.EDU>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
If the cluster system is properly designed, everything on that last
should be easily doable. Condor, to quote Wikipedia, is designed "to
manage workload on a dedicated cluster of computers, and/or to farm
out work to idle desktop computers - so-called cycle scavenging". So
as long as any proposal uses Condor (well, HTCondor, now, they've
renamed themselves) or a similar system, we should be able to put the
cluster machines to work.
Sincerely,
-Alex
On Mon, Apr 7, 2014 at 10:05 PM, Jonathan D Reed <jdreed@mit.edu> 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)
>
> -Jon
