det@hawkmoon.MN.ORG (Derek E. Terveer) (04/12/89)
We, (one of) the Operations Support groups at Unisys, are in the process of implementing a charge back scheme for the Sun workstations that several of our projects are using. However, we (=i) don't have much experience at the kinds of rates to charge for the following resources: cpu time cpu seconds connect time connect hours disk space Megabyte-days Does anyone out there have any suggestions and/or numbers that they use for any charge back scheme that they currently implement or have implement? VERY ROUGH guestimates of rates that we have looked at so far: $0.0015 .. $0.0070 per cpu second $0.90 .. $0.015 per connect hour $0.14 .. $0.28 per Mb-day What are the typical utilizations that you have experienced on your projects for these resources? Obviously, the rates depend on the stated/assumed goal of recovery. We wish to break even. Comments? Flames will be accepted if they are warm flames, please direct HOT flames elsewhere.... (:-) -- Derek Terveer det@hawkmoon.MN.ORG || ..!uunet!rosevax!elric!hawkmoon!det w(612)681-6986 h(612)688-0667 "A proper king is crowned" -- Thomas B. Costain
schow@bnr-public.uucp (Stanley Chow) (04/15/89)
In article <885@hawkmoon.MN.ORG> det@hawkmoon.MN.ORG (Derek E. Terveer) writes: > > $0.0015 .. $0.0070 per cpu second > > $0.90 .. $0.015 per connect hour > > $0.14 .. $0.28 per Mb-day > Just a somewhat silly question: Has it become totally entrenched for cpu time to be accounted in cpu seconds? Even when cpu minutes make the numbers nicer? Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public (613) 763-2831 If you think anyone else could have such a silly question, I like to sell you some land in Florida!
henry@utzoo.uucp (Henry Spencer) (04/16/89)
In article <885@hawkmoon.MN.ORG> det@hawkmoon.MN.ORG (Derek E. Terveer) writes: >... However, we (=i) don't have much experience at the kinds >of rates to charge for the following resources: > > cpu time cpu seconds You might want to consider not charging for CPU time at all, provided it does not exceed some fraction of connect time. Do you know how much CPU time you used in your editor to prepare your message? Do your users have any idea how much CPU time they use in normal interactive work? Almost certainly not. What you'll be presenting them with is a "mystery charge": they won't have any idea of how to minimize it or how much a specific activity costs them. This is distinctly user-hostile. Obviously, people who leave background number crunching going after they sign off, or spend hours in a compute-intensive interactive statistics package, are a slightly different story. That's why I suggest putting an upper bound on free CPU time, as a fraction of connect time. That way the normal interactive user sees only charges he understands, but the cruncher is still paying for his CPU time. The same comments apply to charging for memory use and character i/o. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
blarson@skat.usc.edu (Bob Larson) (04/17/89)
In article <1989Apr16.020150.1083@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >You might want to consider not charging for CPU time at all, provided it >does not exceed some fraction of connect time. >What you'll be presenting them with is a "mystery >charge": they won't have any idea of how to minimize it or how much >a specific activity costs them. This is distinctly user-hostile. >The same comments apply to charging for memory use and character i/o. I have the exact oposite complaint about a large commercial bbs I use. The slower it goes, the more they charge me! (They charge for connect time only, at two different rates. ("free" time is $.25/hour -- strange definition of free.)) If they had some resoable charging scheme, perhaps they would have some motivation to fix their kermit file transfer so it didn't increase the number of characters transfered by 50%, decrease their network delays, etc. Not all users are as unaware of resorce usage as Henry seems to assume, and charging them for real resorces used tends to make them more aware. (When they notice GNU emacs is more expensive to run than mg, they may find mg does everything they need.) -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
honey@mailrus.cc.umich.edu (peter honeyman) (04/17/89)
MTS is a local operating system for mainframes. Here are the rates
for university people. The complete rates file is in pub/mtsrates
on citi.umich.edu. (Former MTS-ers will note the absence of virtual
memory integral charges.)
Rate Group
Normal Low Defer Minimum
Non-Batch Connect Time (per hour) 2.50 1.00 0.80 1.00
IBM 3090 Processing (per minute) 41.05 22.17 14.37 8.21
Page Printer Images Printed (per 1000) 44.00 31.00 15.00 15.00
Page Printer Sheets Printed (per 1000) 6.00 ------------------->
Line Printer Lines Printed (per 1000) 0.88 0.62 0.30 0.30
Line Printer Pages Printed (per 1000) 8.15 ------------------->
Phototypesetter Media (per square-foot) 7.20 ------------------->
Cards Punched (per 1000) 3.34 3.18 3.10 3.02
Cards Read (per 1000) 0.40 0.24 0.16 0.08
Disk Storage (per page-day) 0.00128 ---------------->
CALCOMP Plotting (per hour) 6.15 ------------------->
CALCOMP Paper (per foot) 0.10 ------------------->
Magnetic Tape Drive Use (per hour) 7.00 4.20 2.80 1.40
Magnetic Tape Mounts (per mount) 0.90 0.72 0.72 0.54
Non Magnetic Tape Drive Use (per hour) 5.00 3.00 2.00 1.00
Non Magnetic Tape Mounts (per mount) 0.65 0.39 0.26 0.13
Paper Tape Punched (per 1000 feet) 1.80 ------------------->
Programs See *SOFTWARECHARGESmangler@cit-vax.Caltech.Edu (Don Speck) (04/17/89)
In article <885@hawkmoon.MN.ORG>, det@hawkmoon.MN.ORG (Derek E. Terveer)
asks what rates to charge on their Sun workstations to recover costs.
For consumables (such as paper), charge what the consumable costs.
However, computers are mostly fixed costs, independent of utilization.
For those resources that somebody has to themselves all the time, such
as a personal workstation or terminal in an office, or a disk dedicated
to one project/account, charge a flat rent (reflecting the fixed cost
of this dedicated resource). Administrators often like this, since
then their costs are not subject to the whims of users who typically
never see the bills. It also means that nobody gets yelled at for
soaking up idle cycles. (If they want to resell the idle cycles,
let them).
For pooled resources, such as public terminals/PC's, terminal-switch
ports, public disks, and timesharing CPU time, where increasing the
supply entails permanent cost increases, charge a usage rate proportional
to the demand (high when demand is high, cheap or free when there's
plenty to spare). If it's prioritizable, like CPU or printer scheduling,
charge by priority. The idea is to discourage overcrowding but
encourage utilization so that average rates stay low.
CPU time should not carry a usage charge unless the CPU is timeshared
with other users (typically not the case on PC's and workstations).
Don't charge for connect time on pty's when you can create more pty's
very cheaply.night@pawl.rpi.edu (Trip Martin) (04/17/89)
In article <1989Apr16.020150.1083@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >You might want to consider not charging for CPU time at all, provided it >does not exceed some fraction of connect time. Do you know how much >CPU time you used in your editor to prepare your message? Do your users >have any idea how much CPU time they use in normal interactive work? >Almost certainly not. What you'll be presenting them with is a "mystery >charge": they won't have any idea of how to minimize it or how much >a specific activity costs them. This is distinctly user-hostile. They can learn easily enough. The default .cshrc (assuming csh is available) could be set up to display cpu usage after every command in an understandable format. Users could be strongly encouraged to leave that feature enabled. One thing that would be quite useful is a program which would show resource usage in terms of real money, and to have it cumulative over the billing period. That way users would quickly see what the real cost of their computing is. Trip Martin night@pawl.rpi.edu night@uruguay.acm.rpi.edu
henry@utzoo.uucp (Henry Spencer) (04/17/89)
In article <1318@rpi.edu> night@pawl.rpi.edu (Trip Martin) writes: >>... Do your users >>have any idea how much CPU time they use in normal interactive work? >>Almost certainly not... > >They can learn easily enough. The default .cshrc (assuming csh is available) >could be set up to display cpu usage after every command in an understandable >format. Users could be strongly encouraged to leave that feature enabled.... Well, apart from the fact that there is a standard shell and its name does *not* begin with 'c', the usual result of something like that is that the numbers are soon ignored as noise. It takes careful study to develop an intuition for something like that, and most users have work to do instead. >One thing that would be quite useful is a program which would show resource >usage in terms of real money... Agreed. Example: how many sites have an equivalent of "du" that shows the sizes in dollars rather than mysterious "blocks"? We do, and it's made a considerable difference in user behavior. (And yes, we did this after a long period of persistently explaining the conversion factor, and having the lesson, and the "du" command, largely ignored.) For those who are interested, I enclose the shell file that does it at the end of this posting; we call it "costperday". The bit of code it uses to find out the charging rate is system-specific, but the rest is portable. It tidies up the du output format a bit as well, to avoid having to explain to users why (e.g.) there's a "./" on the beginning of all the names. >... and to have it cumulative over the billing >period. That way users would quickly see what the real cost of their >computing is. I would observe that they already see what the real costs are, when they get the bills. What is needed is to develop intuition about costs, so people understand how to *change* the bills. It's not the same thing. Providing cumulative bill reporting is not too useful for developing intuition, because few users can be bothered with the constant inquiries needed to get real-time feedback on their activities. It's much easier to develop intuition for charges if you base your charges on things people already understand. (Radical notion, this: systems and policies should be adapted to human convenience rather than vice-versa!) People understand connect time. They fairly easily grasp the notion of storage space. They understand number of pages printed. They do not -- unless they're Computer Science students -- understand CPU time or memory use particularly well. Here's costperday: ------------- PATH=/bin:/usr/bin ; export PATH args="$*" set -- ''`awk '/^$/{exit} /^disk / { print $2, $3 }' /usr/adm/rates | sed 's/\\$//'` case $# in 2) ;; *) echo "$0: cannot locate rates information" >&2 exit 1 ;; esac cost="$1" per="$2" du $args | awk '{ cost = ($1/'$per')*'$cost' if ($2 == ".") place = "(total)" else if ($2 ~ /^\.\//) place = substr($2, 3) else place = $2 printf "$%.2f\t%s\n", cost, place }' ------------- -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
root@helios.toronto.edu (Operator) (04/18/89)
The Computing Consortium here raises all of its operating money through
chargeback, to cover the whole budget (<$250K/yr). We recently went from
a simple algorithm based only on CPU time, connect time, and pages printed,
to a more complicated one which more accurately reflects where our real
costs are. Actual charging rates on CPU time were cut in half, and we began
to charge fees for overhead items such as:
- terminal lines in one's office (we buy the server, install the line, and
make sure the server keeps working); $150/yr,
- a billing group (i.e. the person who gets the bills - intended to cover
administrative costs such as running the accounting, totalling all the
different items, invoicing and attendant hassles, etc.); $200/yr,
- an account (creation, quota adjustments, password adjustments, answering
questions for the user, backup, cleanup after deletion); $50/yr,
- administration & serving of a diskless workstation; $500/yr,
- locating a system in the main machine room (so that we become responsible
for shutdown, booting, configuration, and all administration); $5000/yr
for server-size systems and microVAXes,
- attaching a device such as a printer or disk (covers installation time,
software setup, arranging and supervising service when necessary, and
the intangibles (to the user) such as taking up a slot in the backplane);
$300/yr.
All of the above are flat annual fees. We also have variable costs, which
depend on usage. These are:
- CPU time (charged per CPU hour, varies somewhat depending on CPU power
and priority of the job); interactive priority range is $35/hr to $140/hr,
- connect time (very low, ~0.15/hour, meant partly to discourage people
from leaving themselves logged on all the time),
- tape mounts (VMS only - currently no enforceable way under UNIX to
monitor this; intended to cover the substantial time required to make
sure the drives are in working order, and the service costs), $2 ea.,
- pages printed; .05/page line printer, .10/page laser/Versatec (private
printers we don't keep statistics on)
- pagefaults (used as an indicator of memory usage, and because pagefaulting
is usually expensive in terms of system overhead); $.03/1000
- I/O operation (bus usage, interrupts; on VMS the CPU used in servicing
interrupts is not accounted to the process); $.03/1000
Of the above, CPU usage, pagefaults and I/O are subject to a further reduction
depending on whether a group is a Consortium member with/without own disk, at
U of T but not a Consortium member, or outside U of T (full rate).
The bottom part may sound complicated, but it's easy to do because we have
an accounting program which totals all of this for us and takes all the
various factors such as priority, Consortium membership, etc. into account.
These are the easy things. It's the top group, the flat-rate fees, which
are the real administrative headache. It can be a real pain to keep track
of who has how many terminal lines (especially with graduate students who
often share lines in an office and may not all have the same supervisor).
Then you get the people who say "but this user was only here for 9 months,
why should I pay the full $50?" and try to quibble over $12.50 out of a total
bill of several thousand dollars. Annual costs range from the minimum $500
(for those who really only use the system for electronic mail) to over
$20,000 for the really high-usage groups (the ones with a dozen accounts,
whose jobs run for days).
I guess, besides giving you an example of what levels some costs are at,
I'm trying to make sure you realise that implementing chargeback will itself
increase your costs and workload. Not to the point where it isn't worth
doing it, but it does take both CPU time and your own time.
Basically, try as much as possible to charge for things that the computer
can keep track of, and for which you have a program to produce totals and
adjust rates depending on the desired total and changes in charges. Where
possible, avoid the items which have to be verified "by hand" (e.g. doing
a survey to see who's using terminal lines; given half a chance, people
will move them) or those which don't easily lend themselves to monitoring
by the computer. Sometimes these can't be avoided, but often they can.
You'll notice we don't charge for disk space (at least not directly; those
who have their own disk are given a reduction on their CPU charge rate).
This is because is can be a major expense to keep track of. Many people's
usage fluctuates greatly over the course of a day, depending what they are
doing, and to take a snapshot of usage a few times a day, and process all
that data, adds up.
My apologies for the length of this posting; but chargeback schemes are
rarely simple if they try to be fair. I hope this gives you some ideas on
what kinds of things might actually be costing the administration money.
--
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 Consortiumhenry@utzoo.uucp (Henry Spencer) (04/18/89)
In article <16570@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >Not all users are as unaware of resorce usage as Henry seems to assume, Uh, it's not an assumption, it's an observation. Utzoo is a "production" system serving a mostly-computer-naive population. Please remember one important distinction: Computer Science types, even undergrads, understand much more about what's going on than other users. A shop full of CS types is atypical and behaves atypically. >(When they notice GNU emacs is more expensive to run than mg, they may >find mg does everything they need.) How do they notice this? -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
darin@nova.laic.uucp (Darin Johnson) (04/19/89)
You might want to check that the algorithm you use for CPU charge back is reasonable. Back at school, we had these systems on UNIX and VMS, and students in a class automatically got a $100 account. On UNIX, the chargeback seemed pretty much what I expected (eg, if I did more compiles, I got charged more...). However, on the VMS machines, the algorithm used initially had some problems (later fixed). Apparently, either system cpu, io overhead, or connect time was being charged. 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 we didn't care since it wasn't our money, but when we worked at night, we were that much less stressed to get things to work right the first time (compared to the other people yelling "I only have $4.15 left, I'll never make it!"). Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) Can you "Spot the Looney"?
braun@drivax.UUCP (Kral) (04/20/89)
In article <1989Apr18.004953.10427@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: :In article <16570@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: :Uh, it's not an assumption, it's an observation. Utzoo is a "production" :system serving a mostly-computer-naive population. Please remember one :important distinction: Computer Science types, even undergrads, understand :much more about what's going on than other users. A shop full of CS types :is atypical and behaves atypically. I'll say. We have two types of users here. We can't get engineering staff to call us when they need a new cable, or new wiring strung, or something fixed on their PC. They'll just do it themselves. But our F&A staff, well they don't know the difference between their VT200 and the Vax it talks to; it's all just "the Vax" to them. -- kral 408/647-6112 ...amdahl!drivax!braun "To surrender is to remain in the hands of barbarians for the rest of my life; To fight is to leave my bones exposed in the desert waste" - ancient chinese poem
root@helios.toronto.edu (Operator) (04/21/89)
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
dan@ccnysci.UUCP (Dan Schlitt) (04/21/89)
In article <1989Apr18.004953.10427@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <16570@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >>Not all users are as unaware of resorce usage as Henry seems to assume, > >Uh, it's not an assumption, it's an observation. Utzoo is a "production" >system serving a mostly-computer-naive population. Please remember one >important distinction: Computer Science types, even undergrads, understand >much more about what's going on than other users. A shop full of CS types >is atypical and behaves atypically. > All the same old arguments. YUK!! We are being afflicted by creeping IBMism. This subject of charging for computer resources is a confused swamp. A lot of the cause is that most people learned about the subject because they used "large" batch oriented computer systems that used JCL. I thought I got away from it when I changed to unix. Alas, I was wrong. Bad ideas have a way of persisting. The first thing that you must decide is what you want to accomplish by this accounting. I thought that the original question was directed toward recovery of costs. That is a reasonable goal. A second kind of thing that you may want to do with charges is to allocate (scarce) resources. This is also a reasonable goal. The result is usually the university computer center funny money system. However, this goal is different from the first and will frequently conflict with it. While both of these kinds of charging will alter user behavior to some extent, the second has that as a primary goal. This discussion has drifted off in this direction as the quoted material shows. My experience over yea many years is that it doesn't work well. There are other, better ways to do the resource allocation. (They don't work all that well either if what you want is modified user behavior.) I suggest that the important thing to consider in designing the charging system is that it not inhibit the productive use of the computer system. When you start talking about charging for something you induce an accountant mentality which completely loses sight of this. If what you want to do is recover costs then there have been some good suggestions in previous articles. Among the important ideas -- CPU cycles are a parishable commodity so the CPU is really a capital cost to be shared -- consumables like paper should be paid for on the basis of actual use. For interactive use connect time may be a very reasonable way to measure relative use of a shared CPU. If resource allocation is your goal, user education is your only real tool. It is as effective as education of any kind :-). It is my opinion that the BSD disk quota and resource limit facilities are about as good as anything for protecting against the consequences of over use. You can force students to endure all sorts of nonsense (although you shouldn't), but in other parts of the world there are real costs to be taken into account which are ignored in the computer charging stuff. For the computer user all time is real time. If your charging methods reduce the productivity of your programming staff or discourage the computer shy from taking advantage of computer facilities then you have failed to include an important cost. -- Dan Schlitt Manager, Science Division Computer Facility dan@ccnysci City College of New York dan@ccnysci.bitnet New York, NY 10031 (212)690-6868
roy@phri.UUCP (Roy Smith) (04/22/89)
braun@drivax.UUCP (Kral) writes: > our F&A staff, well they don't know the difference between their VT200 > and the Vax it talks to; it's all just "the Vax" to them. Sounds familiar. I've given up trying to correct people around here when they talk about having a Vax on their desks. On the other hand, we've got people with Sun-3/50's that talk about having Sun terminals. You just can't win. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network"
schow@bnr-public.uucp (Stanley Chow) (04/25/89)
In article <1674@ccnysci.UUCP> dan@ccnysci.UUCP (Dan Schlitt) writes: > >You can force students to endure all sorts of nonsense (although you >shouldn't), but in other parts of the world there are real costs to be >taken into account which are ignored in the computer charging stuff. >For the computer user all time is real time. If your charging methods >reduce the productivity of your programming staff or discourage the >computer shy from taking advantage of computer facilities then you >have failed to include an important cost. > But Dan, maximizing computer usage is not necessarily optimal. It may be that supplying enough computing power is too expensive and fical reality forces a company (or an university) to cut back. The overall allocation of resources (be it computer, human or whatever) is what counts. Modifying user behaviour is certainly usefull. Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public I would consider representing other people for a large fee, no one has paid, ergo, I don't represent anyone.
wcs) (04/26/89)
In article <1674@ccnysci.UUCP> dan@ccnysci.UUCP (Dan Schlitt) writes: } The first thing that you must decide is what you want to accomplish by } this accounting. I thought that the original question was directed } toward recovery of costs. That is a reasonable goal. } A second kind of thing that you may want to do with charges is to } allocate (scarce) resources. This is also a reasonable goal. ***YES***! This is critical, because even in organizations with funny-money budgets, there's often never enough. Your objectives for an accounting system in a business are often radically different from your objectives in a university. For instance, in a university, you typically want to encourage students to log off, because terminals are (typically) a scarce resource - you're trying to minimize the cost of providing adequate services to support education, and make sure the people who need services most can get and afford them. But in a business, you want to maximize profits, which you do by maximizing the productivity of the workers subject to the limitations of your equipment. For instance, you want to encourage people to stay "connected", so that when they have mail they know right away, rather than when they wonder if they might have mail - so you shouldn't charge for connect time unless you have a serious resource shortage. (In these days of networking, you *shouldn't* have a port shortage!) Besides, what does "connect time" mean in a client-server environment - if I want to use a central DBMS, I should be doing remote execution / RPC queries instead of logging on and telling my workstation to pretend it's an antique 3270! Don't let your accounting system lock you into old technology! (On the other hand, don't let your accounting system make you always discard the old technology for new stuff - there's enough of that tendency anyhow.) Similarly, in both environments, you probably don't want to charge people for CPU time on their workstations - not only does it let them use CPU-intensive user interfaces which (hopefully) will increase their productivity, it lets you offload work from the central servers. (Workstation CPU power is essentially a sunk-cost resource, while central servers are much more like variable costs.) Depending on the incremental costs to you, you may want to juggle the cost ratios between workstations and central resources to encourage one or the other - it's probably more cost-effective to do large-volume printing on central printers than on everybody's laserwriter, but small print jobs should probably be handled locally. With disk drives, you may want to charge a lot to use central servers, but on the other hand you should be provided easily-accessed archives of useful stuff like "comp.sources.*" so people don't all keep their own copies, and archive services should be cheap and well-supported because you want people to move stuff to tape instead of leaving it on the disk. If you have *any* control over this at all, set the prices so people will buy large-enough local disks. Disclaimer: I can say all this stuff with no biases whatsoever, because I've mostly retired from administration and gone back to engineering, so I know that providing free services to users is the ideal :-) The last time I had to deal with cost-allocation from the administrator's side, the managers of the two main projects on the machines decided who had more money which month, and I juggled CPU vs. connect time charges to divide up the 100% fixed cost however they wanted, while the users did their best to get the job done with a 1 MIPS VAX and a Cray-sized appetite. Because it was a friendly-manager environment, we were able to manage the accounting in a way that didn't interfere with our work, and the lab was small enough that we could do scarce-resource-allocation by talking with the users when we needed extra cooperation. In a standard comp-center environment, we oculdn't have done the same job - Mario really *needed* 200 MB of disk (back when that was a big number), and he really did need 90% CPU for a couple of days per week, and any normal cost-accounting procedure would have amortized the VAX in a month. -- # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # also found at 201-271-4712 tarpon.att.com!wcs
rsn@mtuxo.att.com (XMRH2-S.NAGARAJ) (04/27/89)
I have been having some problem understanding the following output to
the "acctcom -ursn ~/pacct" command:
=======================================================================
COMMAND START END REAL CPU MEAN
NAME USER TTYNAME TIME TIME (SECS) (SECS) SIZE(K)
(first session): ->
vnews rsn ttyd306 05:50:20 06:00:19 599.20 1.23 348.00
ksh rsn ttyd306 06:00:22 06:00:22 0.15 0.02 0.00
vi rsn ttyd306 06:00:35 06:00:56 21.53 0.15 580.00
ksh rsn ttyd306 06:00:35 06:00:56 21.68 0.02 0.00
pg rsn ttyd306 06:07:40 06:07:56 16.73 0.03 132.00
ps rsn ttyd306 06:07:58 06:07:58 0.72 0.68 160.00
acctcom rsn ttyd306 06:08:34 06:08:39 5.35 0.40 164.00
ksh rsn ttyd306 05:39:37 06:09:02 1765.33 0.67 172.00
#ksh rsn ttyd306 23:16:33 06:09:08 24755.20 0.82 180.00
^^^^^^^^
(second session): ->
date rsn ttyd307 06:09:19 06:09:19 0.02 0.02 0.00
uname rsn ttyd307 06:09:19 06:09:19 0.02 0.02 0.00
=======================================================================
I logged into the system at about 5:45 AM. And logged out at 6:09 AM.
When I exit the session, however, the start time for ksh is shown to
have been from 23:16 PM of the previous evening. I cannot understand that.
Is this normal? Will the charge-back be based on the CPU utilization
from this hour on?
Can anyone out there explain?
Thanks
Raj Nagaraj