home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / vmsnet / internal / 1813 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  1.5 KB
  1. Path: sparky!uunet!stanford.edu!rutgers!gvls1!udel!bogus.sura.net!howland.reston.ans.net!usc!sol.ctr.columbia.edu!hamblin.math.byu.edu!arizona.edu!mvb.saic.com!macro32
  2. From: DWING@UH01.Colorado.EDU (Dan Wing)
  3. Newsgroups: vmsnet.internals
  4. Subject: Re: How to force a process into one CPU on a 6640?
  5. Message-ID: <01GU0MN0NAN6001HZW@VAXF.COLORADO.EDU>
  6. Date: 27 Jan 93 21:52:40 GMT
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. Lines: 24
  9. X-Gateway-Source-Info: Mailing List
  10.  
  11. Derek S. Haining, DEREK@MAX.U.WASHINGTON.EDU, writes:
  12.  
  13. >YES!  We have.  Now, although I haven't looked in the solution provided by
  14. >Pekka, I did look into this technology quite a lot back in earlier versions
  15. >of VMS (T5.2 and some before this.)  My thought was to be able to restrict
  16. >CPU-hogging batch jobs to a subset of the available CPUs, thus providing
  17. >better response time to the interactive users.   (See, we could raise QUANTUM
  18. >up (good for a vector CPU) and not feel the effects of multiple batch jobs
  19. >so much.)
  20.  
  21. I'm really looking forward to see how VMS V6.0's implementation of class
  22. scheduling is going to work with ideas like this.  We could certainly take
  23. good advantage of it here.  And in combined academic/administrative settings
  24. you could "allow" the students 10% of the CPU and all those administrative
  25. people the rest!!  ;-)
  26.  
  27. >Anyone read this far?   :)
  28.  
  29. ("It's the right one, baby.")
  30.  
  31. "Uh-huh."
  32.  
  33. -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
  34.  Systems Administrator, University Hospital, Denver
  35.