home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / super / 1199 < prev    next >
Encoding:
Text File  |  1993-01-25  |  2.7 KB  |  51 lines
  1. Newsgroups: comp.sys.super
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!news.oc.com!convex!patrick
  3. From: Patrick F. McGehearty <patrick@convex.COM>
  4. Subject: Re: World's Most Powerful Computing Sites
  5. Originator: patrick@wagner.convex.com
  6. Sender: usenet@news.eng.convex.com (news access account)
  7. Message-ID: <1993Jan25.155123.20107@news.eng.convex.com>
  8. Date: Mon, 25 Jan 1993 15:51:23 GMT
  9. Reply-To: patrick@convex.COM (Patrick F. McGehearty)
  10. References: <1993Jan20.211032.11929@hubcap.clemson.edu> <1993Jan20.232809.29241@nas.nasa.gov> <8699@charon.cwi.nl>
  11. Nntp-Posting-Host: wagner.convex.com
  12. Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
  13. X-Disclaimer: This message was written by a user at CONVEX Computer
  14.               Corp. The opinions expressed are those of the user and
  15.               not necessarily those of CONVEX.
  16. Lines: 33
  17.  
  18. In article <8699@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
  19. ...
  20. >  But than we get at the standard question: what should
  21. >you use?
  22.  
  23. I rather like using Dongarra's Linpack report (either the Best Effort
  24. with n=1000, or for some systems, the Rmax from Table 3 with n selected
  25. by the vendor.  These benchmarks measure actual solution of real problem,
  26. under almost ideal conditions.  They also are widely available and regularly
  27. updated.  Jack makes serious efforts to keep the vendors honest.  There are
  28. very few application/machine combinations which will show higher Gflop
  29. ratings than that provided by these numbers, so that benchmark can be
  30. considered the realistic attainable peak for 64-bit floating point
  31. operations.  Be careful when quoting a higher 32-bit peak to note the 64-bit
  32. performance also.
  33.  
  34. Of course, any careful evaluation of super architecture needs to take
  35. into account peak achievable megaflops (Linpack), memory bandwidth
  36. (McCalpin's Stream), sustainable I/O bandwidth (to disk and high speed
  37. network) as a proportion of peak megaflops, and ease of achieving
  38. significant fractions of these peaks on real application codes.
  39.  
  40. We have already discussed Gflops and memory megabytes/sec.
  41. Any opinions on the amount of I/O bandwidth necessary to support/sustain
  42. a useful Gflop in a production environment?  My intuition is that 10
  43. Mbytes/second is a bit skimpy, while 100 Mbytes/second is ample.  Is that
  44. the right range?  Anyone have actual application performance requirements?
  45.  
  46. By the way, I mean actual, delivered data to an application, not peak
  47. hardware specs of the fastest bus on the system.  Specmanship is really
  48. common in quoting I/O performance, just as peak Mflops is common.  Alertness
  49. on the part of you users, writers, and reviewers is necessary to keep us
  50. vendors from playing spiraling artifical, meaningless number games.
  51.