🚀 go-pugleaf

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.