Subject: Long jobs history #6 Date: Thu, 08 May 1997 17:47:03 EDT From: "Naomi B. Schmidt" ------- Forwarded Message Received: from SOUTH-STATION-ANNEX.MIT.EDU by po6.MIT.EDU (5.61/4.7) id AA04758; Mon, 28 Aug 95 16:55:47 EDT Received: from MOZART.MIT.EDU by MIT.EDU with SMTP id AA12189; Mon, 28 Aug 95 16:55:41 EDT Received: by mozart.MIT.EDU (5.57/4.7) id AA03934; Mon, 28 Aug 95 16:55:45 -0400 Message-Id: <9508282055.AA03934@mozart.MIT.EDU> To: nschmidt@MIT.EDU Subject: Long Jobs Policies, Statistics Date: Mon, 28 Aug 1995 16:55:44 EDT From: "Naomi B. Schmidt" Proposal for a Long Jobs policy - ------------------------------- There will be two Long_Jobs machines. There will be two classes of users who can use these machines, and to start with they will be assigned to the two different machines. We will adjust if necessary to maintain throughput: Class A users: - ------------- 1. Faculty member will register a subject with the Faculty Liaison Office. 2. A group will be created for that subject, if one doesn't currently exist, and will be added to the password file for PatriotA. 3. The faculty member will be responsible for added usernames to the group. 4. At the end of each semester this group will be purged from the acl, with new registration required. Class B users: - ------------- 1. A user needing to run long jobs will fill out a Web form explaining why she needs that facility and submit it to some mailing list (possibly accounts, f_l, patriot2, ...) This form will explain the rules of use and why this service is being created. 2. This username will be added to the acls for PatriotB. 3. At the end of each [semester, academic year, ?] the list will be purged and a new form will need to be submitted. - ---------------------------------------------------------------------- If it seems to improve throughput, we can consider mixing both types of users on both machines and assign PatriotA or PatrioB randomly (or by some algorithm as per dialup servers.). - ---------------------------------------------------------------------- Statistics that we need to look at - ---------------------------------- Clock time per job CPU time per job Clock/CPU time per user Clock/CPU time per subject Peak simultaneous use as a function of time of day Peak simultaneous use as a function of time of semester Applications that are run: Matlab Adina ProEngineering ...... non of the above (presumably compiled home-grown binaries) What about memory use, disk use, for future growth? ------- End of Forwarded Message