home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / vmsnet / internal / 1703 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  6.4 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  2. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  3. Newsgroups: vmsnet.internals
  4. Subject: Re: Received Bytes Accounting
  5. Date: 19 Dec 1992 10:36:38 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 124
  8. Distribution: world
  9. Message-ID: <1gutvmINNlv7@gap.caltech.edu>
  10. References: <01GSFKS4THCYAFTSR3@accuwx.com>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <01GSFKS4THCYAFTSR3@accuwx.com>, Paladin <GOODMAN@ACCUWX.COM> writes:
  15. >*  CPU-use based accounting over charges users when they run badly
  16. >   written applications that are CPU hogs.
  17.  
  18. Bullshit!  Stupidity has its price.  If someone decides to run code written by
  19. an ignoramus, he deserves to pay for it.
  20.  
  21. >   If users are migrated
  22. >   among Vaxes with different CPU speeds determining a fair rate
  23. >   for CPU use becomes problematical.
  24.  
  25. Take a course in microeconomics to find out why this, too, is bullshit.
  26. >   And on faster Vaxes VMS is
  27. >   extremely inaccurate in recording CPU use; the interval timer
  28. >   interrupt service routine which records what process is using
  29. >   the CPU runs only every .01 seconds; in that interval many I/O
  30. >   bound processes may have briefly used the CPU and then returned
  31. >   to LEF state.
  32.  
  33. You've got a point there.  On the other hand, I notice that you don't seem to
  34. have an alternitive.  Bitching when you can't offer a better suggestion is
  35. rather juvenile, don't you think?  Rather like a child crying when he finds out
  36. there's no Santa Claus.
  37.  
  38. >*  The process direct I/O count (DIOCNT) is, to some degree, a measure
  39. >   of how much work the process did.
  40.  
  41. Again, bullshit!  Unless, of course, you're talking about a word processing
  42. program, or something of the sort.  There are LOTS of applications where DIOCNT
  43. doesn't have a damned thing to do with how much work the process did.  Or don't
  44. the words "Monte Carlo" mean anything to you?
  45.  
  46. >   But again it may often be more of
  47. >   an indication of how well specific applications were designed.
  48.  
  49. Obviously, you've got a very particular sort of application in mind.  Care to
  50. tell us what it might be?
  51.  
  52. >   And
  53. >   it would be difficult for remote users to relate the DIOCNT figure
  54. >   to what they would perceive as the true value of their time-sharing
  55. >   session.
  56.  
  57. How so?  And why the hell should the rates be based solely on what the users
  58. perceive as the value?  Aren't you forgetting that there's a supply curve as
  59. well as a demand curve?  Just because someone wants to drink champagne on a
  60. beer budget doesn't mean that champagne should be priced the same as beer.
  61.  
  62. >  For most users this "perceived session value" would be
  63. >   related to how much data they receive on their terminal.
  64.  
  65. ?????????????????????????  I know some physicists who would prefer to have
  66. the few lines of output from their Monte Carlo simlations to having the VMS
  67. listings displayed on their terminals.  Again, WHAT APPLICATIONS ARE YOU
  68. NATTERING ABOUT?
  69.  
  70. >*  The process buffered I/O count (BIOCNT) counts not just I/O to
  71. >   the user's terminal but also file opens and other miscellaneous
  72. >   I/O types.
  73.  
  74. Bzzzzt!  Wrong answer.  For disk files, you're talking about DIOCNT, *NOT*
  75. BIOCNT.  Or don't you have even the slightest clue to what these terms mean?
  76. I didn't think so.
  77.  
  78. >*  The number of I/Os performed on the user's terminal device could
  79. >   be calculated by storing the I/O count of the device at login and
  80. >   subtracting that from the I/O count at process termination.  This
  81. >   would require an executive rundown routine to perform this and to
  82. >   record the result somewhere.  This is getting closer to being a
  83. >   measure of the "perceived session value" but it still has one flaw:
  84. >   An I/O to the terminal device can vary from being one byte long to
  85. >   being a dump of a "n"K buffer.   A well designed application that
  86. >   uses large buffers would have at least the same perceived value as
  87. >   one that does no terminal I/O buffering, but its device I/O count
  88. >   could be less by orders of magnitude.
  89.  
  90. Let's see.  You want to charge someone who issues the command:
  91.     HELP CC RUN *
  92. more than someone who runs a Monte Carlo simulation that takes 72 CPU hours to
  93. run, just because the former produces thousands of lines of output to his
  94. terminal instead of maybe a dozen from the Monte Carlo simulation?
  95. >------------------------------------------------------------------------
  96. >
  97. >So what is really needed is a count of the bytes written to the user's
  98. >terminal.
  99.  
  100. That might be useful, but it's nowhere near the be-all and end-all you seem to
  101. think it is.
  102.  
  103. >So I am asking all you internal gurus with those source listings by
  104. >your side for help!  How about a patch to the terminal class driver
  105. >that records the total number of bytes from all $QIOs (or just the
  106. >write $QIOs if possible) performed to a terminal device somewhere in
  107. >its UCB where I could access it when the master process of an inter-
  108. >active job logs out.
  109.  
  110. Please, tell us for what applications you think that "number of bytes written
  111. to the terminal" is in any way a useful measure of the usefulness of the
  112. session.  I can't think of any.
  113.  
  114. >Or, alternately, record the total number of bytes written to any terminal
  115. >device by a process, since remote users normally don't use more than one
  116. >terminal device anyway.  If this value could be stored in an under-used
  117. >field that's written to the VMS accounting record for the process, such as
  118. >ACC$L_VOLUMES (remote users never mount volumes) that would be fantastic!
  119. >And if somehow this accounting could be done on job-wide basis instead of
  120. >per process that would be even better!!
  121. >
  122. >A patch for any VMS 5.5 release would be fine.  I will be happy to debug
  123. >it myself.  And I promise not to bug the author for updates for new VMS
  124. >releases.
  125.  
  126.  
  127. Again, I ask:  WHAT THE HELL SORT OF APPLICATION ARE YOU TALKING ABOUT WHERE
  128. NUMBER OF BYTES WRITTEN TO TERMINALS HAS *ANYTHING* TO DO WITH THE USEFULNESS
  129. OF A SESSION?
  130. --------------------------------------------------------------------------------
  131. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  132.  
  133. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  134. understanding of astronomy is purely at the amateur level (or below).  So
  135. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  136. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  137. hold me responsible for it, but my organization had nothing to do with it.
  138.