Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!uwvax!rutgers!lll-crg!nike!ucbcad!ucbvax!RELAY.CS.NET!JOHNSON%nuhub.acs.northeastern.edu
From: JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET ("I am only an egg.")
Newsgroups: mod.computers.vax
Subject: Variable CPU time useage
Message-ID: <8610150801.AA01814@ucbvax.Berkeley.EDU>
Date: Tue, 14-Oct-86 09:23:00 EDT
Article-I.D.: ucbvax.8610150801.AA01814
Posted: Tue Oct 14 09:23:00 1986
Date-Received: Thu, 16-Oct-86 00:01:41 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 40
Approved: info-vax@sri-kl.arpa


     Chris Johnson comments that he gets embarrassed
     when computer science faculty ask why they get
     variable CPU time measures for a given job.  I
     can't figure out if he's embarrassed for DEC or
     for the faculty members! 
     
     I look at the situation in the following way.  The
     higher charges incurred due to overhead while
     running on a loaded system are simply an incentive
     for users to run their programs when the system is
     not so loaded.  This seems to be accepted as a
     "fair" practice since every site I've ever seen
     charges higher rates for peak time computing. 
     
     Peter ------- 


   I'm more embarrassed for the faculty then DEC right now.  The faculty 
*should* know better.  DEC *does* know better but apparently doesn't 
care much.

   As far as any site I've ever worked at was concerned, charging more 
for peak hours was the way to go.  The inability of an operating system 
to accurately distribute cpu time was a happy happenstance.  However as 
I said before, accurate determination of what job owns what cpu time is 
difficult.  Not impossible mind you but very difficult.

   One of the first things you need to know is how fast your machine is. 
The last timing chart for an instruction set I saw in DEC (for a big
computer) was for a KI 10.  I don't know whether or not DEC ever made any
more instruction set timing charts.  Another thing that could be done is 
to have a timer in the hardware that could be used to tell how long 
interrupt time *really* took. etc etc etc ...

   You got me going again.  I could go on all day but I'll stop here and 
save you reading time.

Chris Johnson
Northeatstern University.