home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sgi / misc / 121 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!olivea!sgigate!odin!sgihub!zola!zuni!anchor!olson
  2. From: olson@anchor.esd.sgi.com (Dave Olson)
  3. Newsgroups: comp.sys.sgi.misc
  4. Subject: Re: Where does the CPU go, when its not doing nuthin' (gr_osview)
  5. Message-ID: <u8s7h04@zuni.esd.sgi.com>
  6. Date: 30 Dec 92 21:57:54 GMT
  7. References: <to01eas@zuni.esd.sgi.com> <1hsmkiINNf05@rave.larc.nasa.gov>
  8. Sender: news@zuni.esd.sgi.com (Net News)
  9. Organization: Silicon Graphics, Inc.  Mountain View, CA
  10. Lines: 34
  11.  
  12. In <1hsmkiINNf05@rave.larc.nasa.gov> s.j.scotti@larc.nasa.gov (Stephen J. Scotti) writes:
  13.  
  14.  
  15. | >| When looking at gr_osview, I have a program that uses about 50% of the
  16. | >| cpu (indigo R4000 elan running 4.05F). The CPU wait line in gr_osview
  17. | >| is empty, so if the cpu isn't waiting, why doesn't my program get 100%
  18. | >| of the CPU?
  19. | >| 
  20. | >| I guess the less naive way of putting this is: What factors aren't captured
  21. | >| between the CPU Usage and CPU wait?
  22. | >| 
  23. | >| [The program in question reads in a 16k chunks of stuff off of disk, messes
  24. | >| around with them and writes them out. All to local disk.]
  25. | 
  26. | >It's hard to say just where it is waiting.  Running osview may be
  27. | >helpful, as would 'timex -s yourprog'.  My guess is that it is indeed
  28. | >waiting for the disk part of the time.
  29. | 
  30. | I have been running a structural analysis finite element code on a 4d35 with 
  31. | similar problems.  I was the only user on the machine but could get no more 
  32. | than about 60% of the CPU.  I too attributed this to disk accesses but when 
  33. | we upgraded our memory from 16mb to 48mb, I found that I could get about 95% 
  34. | of the CPU!
  35. | I wonder if Dave Olson could explain that?
  36.  
  37. More buffering of files, and therefore less time spent waiting
  38. for the disk, is my *guess*.  It could also be that you were
  39. doing a lot more paging with less memory.  Both timex -s and
  40. osview would help confirm or deny these theories.  Without
  41. measurements, who knows?
  42. --
  43. Let no one tell me that silence gives consent,  |   Dave Olson
  44. because whoever is silent dissents.             |   Silicon Graphics, Inc.
  45.     Maria Isabel Barreno                        |   olson@sgi.com
  46.