home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / vmsnet / internal / 1695 < prev    next >
Encoding:
Internet Message Format  |  1992-12-20  |  4.1 KB
  1. Path: sparky!uunet!usc!news.service.uci.edu!unogate!mvb.saic.com!macro32
  2. From: Paladin <GOODMAN@ACCUWX.COM>
  3. Newsgroups: vmsnet.internals
  4. Subject: Received Bytes Accounting
  5. Message-ID: <01GSFKS4THCYAFTSR3@accuwx.com>
  6. Date: 17 Dec 1992 21:28:07 +0000 (GMT)
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 71
  10.  
  11. None of the process accounting data that VMS records is a fair
  12. and accurate way to charge a user for use of a time-shared Vax:
  13.  
  14. *  For a session where the user is retrieving a fixed amount of
  15.    data, the elapsed process time is really a measure of how slow
  16.    the system is at the time of that session.  Why should a user
  17.    be charged *more* when he has to wait longer to get his data?
  18.  
  19. *  CPU-use based accounting over charges users when they run badly
  20.    written applications that are CPU hogs.  If users are migrated
  21.    among Vaxes with different CPU speeds determining a fair rate
  22.    for CPU use becomes problematical.   And on faster Vaxes VMS is
  23.    extremely inaccurate in recording CPU use; the interval timer
  24.    interrupt service routine which records what process is using
  25.    the CPU runs only every .01 seconds; in that interval many I/O
  26.    bound processes may have briefly used the CPU and then returned
  27.    to LEF state.
  28.  
  29. *  The process direct I/O count (DIOCNT) is, to some degree, a measure
  30.    of how much work the process did.  But again it may often be more of
  31.    an indication of how well specific applications were designed.  And
  32.    it would be difficult for remote users to relate the DIOCNT figure
  33.    to what they would perceive as the true value of their time-sharing
  34.    session.  For most users this "perceived session value" would be
  35.    related to how much data they receive on their terminal.
  36.  
  37. *  The process buffered I/O count (BIOCNT) counts not just I/O to
  38.    the user's terminal but also file opens and other miscellaneous
  39.    I/O types.
  40.  
  41. *  The number of I/Os performed on the user's terminal device could
  42.    be calculated by storing the I/O count of the device at login and
  43.    subtracting that from the I/O count at process termination.  This
  44.    would require an executive rundown routine to perform this and to
  45.    record the result somewhere.  This is getting closer to being a
  46.    measure of the "perceived session value" but it still has one flaw:
  47.    An I/O to the terminal device can vary from being one byte long to
  48.    being a dump of a "n"K buffer.   A well designed application that
  49.    uses large buffers would have at least the same perceived value as
  50.    one that does no terminal I/O buffering, but its device I/O count
  51.    could be less by orders of magnitude.
  52.  
  53. ------------------------------------------------------------------------
  54.  
  55. So what is really needed is a count of the bytes written to the user's
  56. terminal.  Unfortunately VMS does not record any statistics on the
  57. number of bytes written to a device.
  58.  
  59. So I am asking all you internal gurus with those source listings by
  60. your side for help!  How about a patch to the terminal class driver
  61. that records the total number of bytes from all $QIOs (or just the
  62. write $QIOs if possible) performed to a terminal device somewhere in
  63. its UCB where I could access it when the master process of an inter-
  64. active job logs out.
  65.  
  66. Or, alternately, record the total number of bytes written to any terminal
  67. device by a process, since remote users normally don't use more than one
  68. terminal device anyway.  If this value could be stored in an under-used
  69. field that's written to the VMS accounting record for the process, such as
  70. ACC$L_VOLUMES (remote users never mount volumes) that would be fantastic!
  71. And if somehow this accounting could be done on job-wide basis instead of
  72. per process that would be even better!!
  73.  
  74. A patch for any VMS 5.5 release would be fine.  I will be happy to debug
  75. it myself.  And I promise not to bug the author for updates for new VMS
  76. releases.
  77.  
  78. ---------------------------------------------------------------------
  79.                                                         Jess C. Goodman
  80.                                                         814 238-2811
  81.                                                         GOODMAN@ACCUWX.COM
  82.