Article View: vmsnet.internals
Article #490Re: Received Bytes Accounting
From: t_wade
Date: Tue, 22 Dec 1992 11:23
Date: Tue, 22 Dec 1992 11:23
50 lines
3343 bytes
3343 bytes
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 !
Technical Details
Message-ID:
<1992Dec22.122330.12171@vms.eurokom.ie>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!ieunet!vms.eurokom.ie!t_wadeReferences:
<01GSFKS4THCYAFTSR3@accuwx.com> <1gutvmINNlv7@gap.caltech.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!ieunet!vms.eurokom.ie!t_wade From: t_wade@vms.eurokom.ie Newsgroups: vmsnet.internals Subject: Re: Received Bytes Accounting Message-ID: <1992Dec22.122330.12171@vms.eurokom.ie> Date: 22 Dec 92 12:23:30 CET References: <01GSFKS4THCYAFTSR3@accuwx.com> <1gutvmINNlv7@gap.caltech.edu> Organization: EuroKom Conferencing Service Lines: 50