🚀 go-pugleaf

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.