Xref: utzoo news.sysadmin:2290 comp.misc:5799
Path: utzoo!utgpu!jarvis.csri.toronto.edu!me!radio.astro!helios!root
From: root@helios.toronto.edu (Operator)
Newsgroups: news.sysadmin,comp.misc
Subject: Re: computer charge back (long)
Message-ID: <780@helios.toronto.edu>
Date: 20 Apr 89 23:05:54 GMT
References: <512@laic.UUCP>
Reply-To: sysruth@helios.physics.utoronto.ca (Ruth Milner)
Organization: University of Toronto Physics/Astronomy/CITA
Lines: 48

In article <512@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes:
>either system cpu, io overhead, or connect time was being charged.

VMS doesn't have the same distinction of system time vs. user time, in
the sense that whatever CPU the system uses on your behalf which your
process doesn't actually use itself, isn't kept track of (e.g. time used
by SWAPPER, JOB_CONTROL, print symbionts, I/O interrupt servicing, etc.)
so there is nothing analogous to the "0.3u 0.1s". 

>The result was that if you were logged in at noon, you ended up paying
>about 25% more than if you did the same thing at midnight (we tested
>this).  These machines were VERY overloaded, such that the connect
>time for these two times were 1 hour vs. about 10 minutes.  Of course

In some sense this is actually desirable. Many sites (particularly IBM)
do charge less for off-peak hours. However you wouldn't notice any
significant amount except on very heavily-loaded systems such as the ones
you describe.

As everyone knows, there are always going to be slight variations in precisely 
how much CPU and wall-clock time it takes to execute a given command. Factors 
include memory limitations (i.e. how many others are you sharing it with, 
which affects the amount of pagefaulting you do), CPU limitations (ditto, 
affecting how much context switching you do and what fraction of every CPU 
second you wind up getting), disk accesses (ditto plus, in VMS, fragmentation 
delays), etc. etc. etc. There is no such thing as the perfect accounting 
system, so we just limp along with what's provided :-). The only exception to 
the above is on a single-user machine, and in most cases people don't keep 
accounting statistics for those systems. If it's yours, it's free; if it's 
not, a flat fee is by far the simplest.

I think it's perfectly reasonable to recover for system overhead where it's
possible. After all, the time the system spends doing things for you is time
unavailable to anyone else. Even during the day most of our systems are not
totally saturated, although that's only become the case during the last year
when people started buying desktop workstations, thus offloading much of the
general functions such as mail and editing. It's impossible to be completely
fair, so I just hope to manage to be unfair as little as is possible.

I'd be interested in hearing more about what other people are doing in
this vein. Anyone out there care to contribute their attempts and
experiences?

-- 
 Ruth Milner          UUCP - {uunet,pyramid}!utai!helios.physics!sysruth
 Systems Manager      BITNET - sysruth@utorphys
 U. of Toronto        INTERNET - sysruth@helios.physics.utoronto.ca
  Physics/Astronomy/CITA Computing Consortium