home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18220 < prev    next >
Encoding:
Text File  |  1992-11-19  |  3.4 KB  |  70 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!jsue
  3. From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
  4. Subject: Re: TUNING - QUANTUM SYSGEM parameter
  5. References: <27A0322A_00174E60.00963CCA9D4FA020$626_2@UK.AC.KCL.PH.IPG>
  6. Message-ID: <1992Nov19.134754.25572@ncsa.uiuc.edu>
  7. Originator: jsue@troon.ncsa.uiuc.edu
  8. Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  9. Organization: The Dow Chemical Company
  10. Date: Thu, 19 Nov 1992 13:47:54 GMT
  11. Lines: 57
  12.  
  13. In article <27A0322A_00174E60.00963CCA9D4FA020$626_2@UK.AC.KCL.PH.IPG> SYSMGR@IPG.PH.KCL.AC.UK writes:
  14. >Slightly provocative reply:
  15. >
  16. >If QUANTUM=20 is OK on a microVAX-II (less than 1 VUP) (and it is!), then
  17. >logically QUANTUM=1 on anything rated at more than 20VUP should be OK,
  18. >maybe even optimal.
  19. >
  20.  
  21. Maybe this information has already been posted.  If so, I pologize.
  22.  
  23. I have been to courses, and many DECUS sessions where Patrick O'Malley
  24. discusses tuning quantum.  What should be kept in mind when reducing
  25. QUANTUM is that it may seemd to improve *trivial* performance, it reduces
  26. "throughput".  This means that in the same amount of wall-clock time,
  27. you get less "total" work completed.  This is a trade-off.
  28.  
  29. Other factors to consider are:  whenever a context switch takes place,
  30. the on-cpu instruction cache is invalidated.  Thus the more often you
  31. context switch (smaller quantum), the more often the cache will become
  32. invalidated.  Therefore your job will get less done because it must rebuild
  33. the cpu's instruction cache everytime it becomes the CUR processes, and it
  34. is doing this more often.  (note:  the CPU cache is a hardware cache, not
  35. one of the XQP (ACP_*) caches - which are for the file system.)
  36.  
  37. I have played with quantum and found that on the smaller processors it
  38. made a big difference in the performance of "trivial" response, like for
  39. MAIL, DIRECTORY, DELETE, TYPE, etc..  However, on the faster processors
  40. today, rarely do these activities even use a quantum before they give up
  41. the cpu voluntarily for a wait-state (I/O completion, LEF, etc.).  Also,
  42. in the cases where I lowered quantum,  the longer-running operations tended
  43. to take more time - my guess is this happens because the scheduler must stop
  44. processing more often to determine "who's next" to run... even if there is
  45. only one job on the system.
  46.  
  47. I eventually settled back to DEC's default of 20 for quantum.  In the
  48. evenings I set quantum to 100 (1 full second) so that the long, 
  49. number-crunching jobs can actually get more time in the cpu before the
  50. scheduler stops the processing to do a context switch.  This can cause 
  51. longer delays for interactive processing, and trivial response.
  52.  
  53. Much of the decision on whether to reduce quantum depends on who/what
  54. you're trying to tune for.  In my case I have a mix of trivial, and non-trivial
  55. processing going on at the same time.  Thus I don't want to context-switch
  56. too often.  I hesitate to say that, merely because today's processors are
  57. much faster than a uVAX II, you can lower quantum.  One of the reasons we
  58. pay for the faster processors is to get more work completed.  Throttling
  59. it all back to a uVAX II speed would miss this point.  We could get the
  60. same affect by merely buy a lot more uVAX II's, distribute the load, and
  61. spend a lot less money than a VAX 6610.
  62.  
  63. Hope this doesn't confuse the issue too much.
  64.  
  65. Jeff
  66. -- 
  67. -----
  68. Jeff Sue   
  69.  - All opinions are mine -       (and you can't have any, nya nya nya)
  70.