🚀 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:

Why don't you just make all your interactive users go through a 
program that you hack up that goes through a PTY?

Hack up a version of one of those session logging programs to
add whatever perceived-value resource intelligence you feel like
using.

> For most users this "perceived session value" would be
> related to how much data they receive on their terminal.


Or perhaps most users connect to your system via TELNET?
Just hack up the telnet server to record the info you want to record.


-gjc

In article <01GSFKS4THCYAFTSR3@accuwx.com>, GOODMAN@ACCUWX.COM (Paladin) 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

That all depends on how you define fair and accurate.

<description of why some accounting data is not fair or accurate>

>So what is really needed is a count of the bytes written to the user's
>terminal.

So what you're saying is that a person who logs on, reads 10K worth
of mail messages, then logs off should be charged for 10K bytes, while
someone who logs in and does the following...

$ SAS HUGEANALYSIS.SAS
<pause while CPU uses 17:30:15.31 in CPU time>
$ LO

Should only be charged for 26 bytes!?

--
--------------------------------------------------------------------------------
William P. Bame                    | sneakernet: William P. Bame
internet: bill@bill.ab.umd.edu     |             M.I.E.M.S.S.
          bbame@achi1.ab.umd.edu   |             22 South Greene Street
AT&T    : [Work] (410) 328-3062    |             Baltimore, MD 21201
CIS     : 71620,425                |             Room: T1R55
--------------------------------------------------------------------------------

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

In article <01GSFKS4THCYAFTSR3@accuwx.com>, Paladin <GOODMAN@ACCUWX.COM> writes:
>*  CPU-use based accounting over charges users when they run badly
>   written applications that are CPU hogs.

Bullshit!  Stupidity has its price.  If someone decides to run code written by
an ignoramus, he deserves to pay for it.

>   If users are migrated
>   among Vaxes with different CPU speeds determining a fair rate
>   for CPU use becomes problematical.

Take a course in microeconomics to find out why this, too, is bullshit.
>   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.

You've got a point there.  On the other hand, I notice that you don't seem to
have an alternitive.  Bitching when you can't offer a better suggestion is
rather juvenile, don't you think?  Rather like a child crying when he finds out
there's no Santa Claus.

>*  The process direct I/O count (DIOCNT) is, to some degree, a measure
>   of how much work the process did.

Again, bullshit!  Unless, of course, you're talking about a word processing
program, or something of the sort.  There are LOTS of applications where DIOCNT
doesn't have a damned thing to do with how much work the process did.  Or don't
the words "Monte Carlo" mean anything to you?

>   But again it may often be more of
>   an indication of how well specific applications were designed.

Obviously, you've got a very particular sort of application in mind.  Care to
tell us what it might be?

>   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.

How so?  And why the hell should the rates be based solely on what the users
perceive as the value?  Aren't you forgetting that there's a supply curve as
well as a demand curve?  Just because someone wants to drink champagne on a
beer budget doesn't mean that champagne should be priced the same as beer.

>  For most users this "perceived session value" would be
>   related to how much data they receive on their terminal.

?????????????????????????  I know some physicists who would prefer to have
the few lines of output from their Monte Carlo simlations to having the VMS
listings displayed on their terminals.  Again, WHAT APPLICATIONS ARE YOU
NATTERING ABOUT?

>*  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.

Bzzzzt!  Wrong answer.  For disk files, you're talking about DIOCNT, *NOT*
BIOCNT.  Or don't you have even the slightest clue to what these terms mean?
I didn't think so.

>*  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.

Let's see.  You want to charge someone who issues the command:
	HELP CC RUN *
more than someone who runs a Monte Carlo simulation that takes 72 CPU hours to
run, just because the former produces thousands of lines of output to his
terminal instead of maybe a dozen from the Monte Carlo simulation?
>------------------------------------------------------------------------
>
>So what is really needed is a count of the bytes written to the user's
>terminal.

That might be useful, but it's nowhere near the be-all and end-all you seem to
think it is.

>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.

Please, tell us for what applications you think that "number of bytes written
to the terminal" is in any way a useful measure of the usefulness of the
session.  I can't think of any.

>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.


Again, I ask:  WHAT THE HELL SORT OF APPLICATION ARE YOU TALKING ABOUT WHERE
NUMBER OF BYTES WRITTEN TO TERMINALS HAS *ANYTHING* TO DO WITH THE USEFULNESS
OF A SESSION?
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.

I am surprised at the amount of aggression that this query has generated.
There is no general `ideal' model for charging usage -- it all depends on
what type of service you are providing.

> Please, tell us for what applications you think that "number of bytes written
> to the terminal" is in any way a useful measure of the usefulness of the
> session.  I can't think of any.

If the service you provide is information, then this is a pretty good model.
For example, consider a service that provides various bulletin board type
services (News, conferencing etc).  A reasonable approximation is charging
by elapsed time.  The problem here is that one user will get his information
interactively, and another will do the equivalent of EXTRACT/UNSEEN/ALL
to a file, and download it with Kermit.  He will be charged a fraction of
the first person's charge, but he gets the same `service' (the same
information).  Of course, you could argue that by using the machine longer,
the first user is consuming more resources and should pay more, but this
might be easier on your machine than a short CPU and I/O intensive session.
You might wish to charge for the amount of data received, irrespective of
whether it is TYPEd, FTP'ed, MAILed or Kermited.

The counterexample of the physicist with the 8 hour batch job that produces
1 line of output is valid, but not relevent *if you don't provide this type
of service*.

It is possible to use combined CPU, elapsed time and I/O count to approximate
this, but my point is that there are scenarios where charging by volume of
data (irrespective of how it is downloaded) is a good charging model.  The
original query was perfectly reasonable.

As a first cut, what about replacing the Start I/O routine with your own, which
notes the byte count and PID from the IRP, adds the count to a field that
ACCOUNTING will save, and invokes the original Start I/O ?  Anyone care to
pinpoint the flaws/pitfalls in this approach ?

Incidentally, the code to do this is already written.  Login sessions using
VAX PSI (over X25 networks) are logged to the PSIACCOUNTING file including
the volume of data sent and received.  This is presumably because most public
X25 networks charge by volume.

------------------------------------------------------------------------------
Tom Wade        | Internet: T.Wade@vms.eurokom.ie  (all domain mailers).
Network Manager | DEC Enet: DECWRL::"t.wade@vms.eurokom.ie"  (VMS Mail)
EuroKom         | PSI-Mail: PSI%272431001992::_T_WADE
UCD Belfield    | JANET:    t.wade%ie.eurokom.vms@UK.AC.EARN-RELAY
Dublin 4        | X400:     g=tom;s=wade;o=eurokom;p=eurokom;a=eirmail400;c=ie
Ireland         | Telex:       (0500) 91178 UCD EI  ("TO: WADE" at start)
-------------------+----------------------------------------------------------
Tel: +353-1-2830555|  Official Disclaimer:  "This is not a disclaimer"
Fax: +353-1-2838605|          Unix  ....  Just say No !

In article <1992Dec22.122330.12171@vms.eurokom.ie>, t_wade@vms.eurokom.ie writes:
>If the service you provide is information, then this is a pretty good model.
>For example, consider a service that provides various bulletin board type
>services (News, conferencing etc).

Then you could put the accounting in the application software and have it write
user data to the accounting file.  An advantage of doing it this way is that
you can then charge different amounts for different types of information (e.g., 
if you're providing NEWS access, then you could charge one rate for most news,
and a higher rate for the (proprietary) clari. heirarchy.

>A reasonable approximation is charging by elapsed time.  The problem here is
>that one user will get his information interactively, and another will do the
>equivalent of EXTRACT/UNSEEN/ALL to a file, and download it with Kermit.  He
>will be charged a fraction of the first person's charge, but he gets the same
>`service' (the same information).

Also, there's the fact that not all people read at the same speed.  By and
large, the lower your reading rate, the lower your comprehension, so the person
who reads more slowly (and hence uses more connect time) is likely to be
getting less out of what he's reading.

And again, not all information is of equal value, so a simple byte count
doesn't give us much information of the value of the session.

>Of course, you could argue that by using the machine longer,
>the first user is consuming more resources and should pay more, but this
>might be easier on your machine than a short CPU and I/O intensive session.

And, of course the CPU overhead is not a simple function of the number of bytes
transferred:  Transferring lots of short records incurs more CPU usage (via I/O
pre- and post- processing) than transferring the same number of bytes of data
via fewer long records.

>You might wish to charge for the amount of data received, irrespective of
>whether it is TYPEd, FTP'ed, MAILed or Kermited.

>The counterexample of the physicist with the 8 hour batch job that produces
>1 line of output is valid, but not relevent *if you don't provide this type
>of service*.

>It is possible to use combined CPU, elapsed time and I/O count to approximate
>this, but my point is that there are scenarios where charging by volume of
>data (irrespective of how it is downloaded) is a good charging model.  The
>original query was perfectly reasonable.

In the case of a BBS, this would imply that, e.g., someone who's browsing
through a long list of articles looking for one particular piece of information
actually gets more benefit than someone who finds what he's looking for in the
first article.  Seems rather strange to me.

>As a first cut, what about replacing the Start I/O routine with your own, which
>notes the byte count and PID from the IRP, adds the count to a field that
>ACCOUNTING will save, and invokes the original Start I/O ?  Anyone care to
>pinpoint the flaws/pitfalls in this approach ?

Well, for starters, this means either:
	1)  You're going to write an accounting record for every I/O operation;
or	2)  You're going to have to hack either LOGINOUT.EXE or the image
	    rundown code to look for this field and write an accounting record.
The former can be extremely resource intensive and the latter would require
lots of modifications to the system (e.g., what happens if a process is STOPped
instead of logged out?  What happens if the process is simply deleted when the
user types MCR DCL?).

All in all, if you want to charge based on number of bytes transferred, it
seems to me that the place to do that accounting is in the application, not in
the device drivers.

>Incidentally, the code to do this is already written.  Login sessions using
>VAX PSI (over X25 networks) are logged to the PSIACCOUNTING file including
>the volume of data sent and received.  This is presumably because most public
>X25 networks charge by volume.

Sorry, but the code to do that isn't anything at all like the code that would
be required to do the same thing for an actual terminal line.  If I recall
correctly, it's the X29 ACP (or equivalent thereof) that keeps track of the
accounting information, and it handles the entire session, and operates in its
own context.

I suppose you could modify the terminal driver to keep track of the number of
bytes transferred, then signal for this to be written to an accounting file
whenever it detects a terminal hangup.	
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.