home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / vmsnet / internal / 1812 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.6 KB
  1. Path: sparky!uunet!stanford.edu!agate!spool.mu.edu!howland.reston.ans.net!sol.ctr.columbia.edu!hamblin.math.byu.edu!arizona.edu!mvb.saic.com!macro32
  2. Newsgroups: vmsnet.internals
  3. Subject: Re: How to force a process into one CPU on a 6640?
  4. Message-ID: <8C41AD70BA9F23FF7A@MAX.U.WASHINGTON.EDU>
  5. From: DEREK@U.WASHINGTON.EDU
  6. Date: Wed, 27 Jan 93 11:26 PST
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 46
  10.  
  11. Tom O'Toole (ecf_stbo@jhuvms.hcf.jhu.edu) writes:
  12.  
  13. >Pekka.Savolainen@Salcom.Fi writes...
  14. >>Included, please find sys$examples:bind_read_me.txt
  15. >
  16. >I'm curious if anyone has explored the license implications of this.
  17.  
  18. YES!  We have.  Now, although I haven't looked in the solution provided by
  19. Pekka, I did look into this technology quite a lot back in earlier versions
  20. of VMS (T5.2 and some before this.)  My thought was to be able to restrict
  21. CPU-hogging batch jobs to a subset of the available CPUs, thus providing
  22. better response time to the interactive users.   (See, we could raise QUANTUM
  23. up (good for a vector CPU) and not feel the effects of multiple batch jobs
  24. so much.)  Anyway, VMS Engineering kept changing the scheduler on me, so
  25. we waited until the activity died down.   (At one point, I was given
  26. information on how to call a system routine to restrict a process to a
  27. CPU.  It only crashed the system.  I didn't use that routine after that.) :)
  28.  
  29. Now that this seems fairly stable (we are at V5.5-1), we are using this to
  30. our advantage.  Specifically, we had an 6000-420 which we wanted to upgrade
  31. to a 6000-440.  The vendors of S1032 (I don't remember their name) wanted
  32. big bucks for a new license.  We worked out a deal where we restrict the
  33. users of S1032 to a single CPU, and now we can move S1032 from (I believe)
  34. a 6000-420 up to a 6000-530 with no additional charge.
  35.  
  36. How did we implement this?  First, we restrict access to the S1032 files
  37. and images.  In order to run S1032, you first invoke a set up procedure
  38. which: 1) raises your base priority to 5, 2) restricts you to a subset of
  39. the available CPUs, and 3) grants you the identifiers needed to run S1032.
  40.  
  41. The priority 5 business help ensure that these users get scheduled "fairly".
  42. (Otherwise, they would only get to run 50% of the time.  2 out of 4 CPUs.)
  43. Since they can only run on 2 of the 4 CPUs, the priority 4 users don't feel
  44. much of an impact.  Note: the non-S1032 users may be scheduled on ANY
  45. available CPU.
  46.  
  47. Questions?  Comments?  Flames?  Anyone read this far?   :)
  48.  
  49. -Derek S. Haining
  50.  University Computing Services
  51.  University of Washington
  52.  Seattle, Washington  98195
  53.  (206) 543-5579
  54.  
  55.  DEREK@MAX.BITNET
  56.  DEREK@MAX.U.WASHINGTON.EDU
  57.