home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8252 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  3.9 KB
  1. Xref: sparky comp.arch:8252 comp.benchmarks:1184
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!mips!sdd.hp.com!caen!hellgate.utah.edu!dog.ee.lbl.gov!nosc!rigel!wolfgang
  3. From: wolfgang@code-541 (Lewis E. Wolfgang)
  4. Newsgroups: comp.arch,comp.benchmarks
  5. Subject: Re: Sun 600MP Benchmark Anomaly
  6. Message-ID: <5652@nosc.NOSC.MIL>
  7. Date: 24 Jul 92 00:51:18 GMT
  8. References: <19190001@hpcss01.cup.hp.com>
  9. Sender: nobody@nosc.NOSC.MIL
  10. Reply-To: wolfgang@code-541
  11. Organization: NCCOSC, NRaD Division
  12. Lines: 71
  13.  
  14. In article 19190001@hpcss01.cup.hp.com, markw@hpcss01.cup.hp.com (Mark Williams) writes:
  15. >wolfgang wrote:
  16. >> There is a known problem with SunOs 4.1.2 and the MP machines
  17. >> that is fixed with Sun patch 100575-02.  Symptoms included poor
  18. >> performance (worse than a 490) under certain conditions.  One
  19. >> wonders if Workstation Labs had this patch installed.
  20. >
  21. >> We have a 690MP with 4 processors and are of the opinion that
  22. >> it is the best thing since cotton sheets!  It is a win for us
  23. >> as a computational server, nfs server and three segment network
  24. >> router.
  25. >
  26. >Since the patch came out in May and the article was in the June issue,
  27. >it was probably done without the patch.  My own guess is that the patch 
  28. >was done in response to the article, but it's just a guess.
  29.  
  30. I think the patch was available earlier, but I might be wrong.  Some
  31. Sun people e-mailed me after my post and indicated that they did NOT
  32. have the patch, and also aparently didn't ask for any help from Sun.
  33.  
  34. >
  35. >But the patch didn't really fix the anomaly.  It helped two processor
  36. >performance, but did not change the fact that 4-processor system ran no
  37. >faster than a two processor system, at least in all the benchmarks I've
  38. >seen.  The two processor systems ran only slightly faster than a system with 
  39. >one processor stopped (20%).  This is pre-Solaris 2.0.  I don't know what
  40.                ^^^^^^^
  41. Hm, how do you "stop" a processor?
  42.  
  43. >2.0 will do, but I think software might not be the only culprit.  MBus
  44. >may be saturated or the I/O system may be too slow.  It's interesting that
  45. >future Sun Dragon servers do not seem to use MBus, according to published
  46. >reports.
  47. >
  48. >Bottom line:  the 600MP (with SunOS 4 and the May patch) performs poorly as
  49. >an MP system, but it is a fine uniprocessor with better I/O than a workstation.
  50.  
  51. I recall running benchmarks four times simultaneously (in background) and
  52. having each invocation perform only slightly slower than running it once on
  53. a 490.  Running it once on the 690 yielded better results than a 490.  I wish
  54. I had documented the execution times, but I was doing this only for my own curiosity.
  55. The system is in continuous heavy use right now, when things cool off a bit
  56. I will rerun the programs and document the performance.
  57.  
  58. At the moment, the system has 5 users and two computationally intensive
  59. programs running all the time.  At the same time it is serving 18 SparcStations
  60. and routing between 3 ethernet segments.  I ran one benchmark that ran in 6.55
  61. seconds on the 690, 7.09 seconds on a lightly loaded 490.  Another large
  62. acoustic modeling program just ran in 27 seconds on the 690, it runs in 28
  63. seconds on the 490.  Looking at the perfmeter, idle times never got below 25%,
  64. indicating that it still had plenty of poop left.  Hm, let me try running the big
  65. one twice in background (simultaneously), back in a moment...  ok, I'm back.  Each
  66. one ran in 36 seconds, versus 28 on the 490.  Moreover, the system was still
  67. responsive, running 4 big jobs in background while serving and routing would really
  68. bog down a 490.  Yup, it is a win for us.
  69.  
  70. Could it be that you are thinking that one running job will utilize all available
  71. processors simultaneously?  This system is coarse-grained, in that one process
  72. runs on only one processor.  It may be swapped around to different processors, but
  73. is running only on one at any one instant in time.
  74.  
  75.                     Luck
  76.                     Lewie
  77.                     wolfgang@nosc.mil
  78.  
  79.                     NCCOSC, NRaD Division, Code 541
  80.  
  81.  
  82.  
  83.  
  84.  
  85.