🚀 go-pugleaf

In article <01GSFKS4THCYAFTSR3@accuwx.com>, Paladin 
<GOODMAN@ACCUWX.COM> writes:

| None of the process accounting data that VMS records is a fair
| and accurate way to charge a user for use of a time-shared Vax:

Bull.  Connect time is a perfectly good measure of resource 
consumption, because it directly relates to usage of real 
physical hardware: a terminal, a serial line, a modem, a
terminal server port, etc.

| *  For a session where the user is retrieving a fixed amount of
|    data, the elapsed process time is really a measure of how slow
|    the system is at the time of that session.  Why should a user
|    be charged *more* when he has to wait longer to get his data?

Because a given amount of CPU time is a scarcer resource, and
hence more valuable, during times of heavy load.  It makes sense
to charge a user more for n CPU ticks at 2 p.m. than at 2 a.m., just
as it makes sense to charge water customers more per acre-foot
at 2 p.m. in July than at 2 a.m. in December.  The maximum capacity
of systems like VAXen and water plants needs to be configured to
cover peak loads, so it makes perfect sense to discourage consumption
at overload times via variable pricing.

| *  CPU-use based accounting over charges users when they run badly
|    written applications that are CPU hogs.

Just as per-gallon gas prices "over charge" people who drive 1971 
Eldorados.  If you don't charge users for using wastefully designed
and implemented products, then where is their incentive for 
purchasing more efficient products?

|  If users are migrated
|    among Vaxes with different CPU speeds determining a fair rate
|    for CPU use becomes problematical.   And on faster Vaxes VMS is
|    extremely inaccurate in recording CPU use; the interval timer
|    interrupt service routine which records what process is using
|    the CPU runs only every .01 seconds; in that interval many I/O
|    bound processes may have briefly used the CPU and then returned
|    to LEF state.

Ten years ago, some fools at an august southwestern land-grant
university decided to "account" for every jot and tittle of usage on
their large and expensive DECsystem-10 mainframes.  After several
man-years of labor, the end result was that 70% of the disk space
on these mainframes were consumed by accounting data, vs. 10%
given over to user files.  While these beancounters had failed to collect
anything in fees, because their charging algorithm was so byzantine
as to be utterly incomprehensible and unenforceable.

It would appear that you wish to replicate their efforts in the realm
of CPU usage.

| *  The process direct I/O count (DIOCNT) is, to some degree, a measure
|    of how much work the process did.  But again it may often be more of
|    an indication of how well specific applications were designed.  And
|    it would be difficult for remote users to relate the DIOCNT figure
|    to what they would perceive as the true value of their time-sharing
|    session.  For most users this "perceived session value" would be
|    related to how much data they receive on their terminal.

Doubtful.  A Usenet reader perusing alt.sex.bondage may receive 
megabytes of "information" sent to his screen during a single terminal
session.  A physicist running a simulation may receive one line of
terminal output following an eight-CPU-hour run.  I am skeptical
that the Usenet browser would be willing to spend one hundred
thousand times more money on his session than the physicist would
on his.

| *  The process buffered I/O count (BIOCNT) counts not just I/O to
|    the user's terminal but also file opens and other miscellaneous
|    I/O types.
| 
| *  The number of I/Os performed on the user's terminal device could
|    be calculated by storing the I/O count of the device at login and
|    subtracting that from the I/O count at process termination.  This
|    would require an executive rundown routine to perform this and to
|    record the result somewhere.  This is getting closer to being a
|    measure of the "perceived session value" but it still has one flaw:
|    An I/O to the terminal device can vary from being one byte long to
|    being a dump of a "n"K buffer.   A well designed application that
|    uses large buffers would have at least the same perceived value as
|    one that does no terminal I/O buffering, but its device I/O count
|    could be less by orders of magnitude.
| 
| ------------------------------------------------------------------------
| 
| So what is really needed is a count of the bytes written to the user's
| terminal.  Unfortunately VMS does not record any statistics on the
| number of bytes written to a device.

I would contend that providing "usage information" in endless 
granularity and myriad detail would be overall harmful, because
it would further encourage myopic beancounters to spend enormous
amounts of time grovelling over infinitesimal particles of data, just
as SHOW MEMORY/POOL has caused man-centuries of somewhat
valuable system manager time to be squandered twiddling IRPCOUNT.
(Although it could well be argued that people so inclined are better
occupied entangled in makework than what they might be doing
otherwise, e.g. incompetently creating unmaintainable software.

| So I am asking all you internal gurus with those source listings by
| your side for help!  How about a patch to the terminal class driver
| that records the total number of bytes from all $QIOs (or just the
| write $QIOs if possible) performed to a terminal device somewhere in
| its UCB where I could access it when the master process of an inter-
| active job logs out.

I will defer to any actual internal guru who would care to reflect on
the loss in efficiency that requiring all silo'd RMS writes to be 
byte-counted would entail.

| Or, alternately, record the total number of bytes written to any terminal
| device by a process, since remote users normally don't use more than one
| terminal device anyway.  If this value could be stored in an under-used
| field that's written to the VMS accounting record for the process, such as
| ACC$L_VOLUMES (remote users never mount volumes) that would be fantastic!
| And if somehow this accounting could be done on job-wide basis instead of
| per process that would be even better!!
| 
| A patch for any VMS 5.5 release would be fine.  I will be happy to debug
| it myself.  And I promise not to bug the author for updates for new VMS
| releases.

Now, for the $64 question: even assuming you were oblivious to the
drop in performance that implementing your supposed improvement
would entail, I would like to know how much cash money you would
be willing to fork over for someone to do the work.  

A little thought experiment: let's say that someone rewrote TTDRIVER
and RTDRIVER to make $QIO count bytes and update UCBs or PHDs or
whatever.  Let's say you hired someone good (because you don't want
to crash your system), so you're paying $100 an hour for only 40 hours
of work rather than $25 an hour for 500 hours of work.  

So you'll have to plunk down four grand to get your little "improvement".
I suppose you'll have to recoup your "investment" in increased rates on
all of your customers.  If you want a two-year payback, then you'll
have to charge raise your rates enough to gain $2K per year, or $6 per
day across your user base.

Now, I assume that you are in competition with other VMS timesharing
providers.  (If you have no competition, then I don't imagine you would
be so worried about coming up with a "fair" rate ... you'd just pull some
egregious number out of some occluded place and inflict it upon your 
captive audience.)  Your competitors have $6/day lower costs than
you do, and so will be able to charge significantly lower rates than 
you can.  We are to believe that your customers will be glad to pay 
your higher rates because they will get terminal bytecounts on their
bills rather than I/O counts.

Doubtful.  Actually, if your users are charged on a per-character
basis, they will SET MESS/NOFACIL/NOIDENT/NOSEVER/NOTEXT in
their LOGIN.COMs and then spend their time and yours trying to 
figure out why they can't figure out why things don't work.

In my humble opinion, usage-based accounting for host computing 
is an utter crock.  Back when a 780 cost half a million dollars, it may
have made sense to expend resources charging back for usage.
Nowadays, when you can get a 5-MIP VAX for $3000, it is ludicrous
to squander expensive people-time beancounting for usage of an
almost free resource.  If your bills actually cover the cost of your
billing, you will be forced to charge so much that your customers
will be inspired to buy their own systems, which will enable them
to get actual work done without worrying about every miserable
byte that comes thru their terminal line.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
  "It's not a bug, it's a form of flow control."
  - Jerry Leichter on why crash-prone Unix is a suitable
    platform for NSFNET core routers