references 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186
  1. %z Article
  2. %K Saavedra95
  3. %A R.H. Saavedra
  4. %A A.J. Smith
  5. %T Measuring cache and TLB performance and their effect on benchmark runtimes
  6. %J IEEE Transactions on Computers
  7. %V 44
  8. %N 10
  9. %D October 1995
  10. %P 1223-1235
  11. %z Article
  12. %K Wolman89
  13. %A Barry L. Wolman
  14. %A Thomas M. Olson
  15. %T IOBENCH: a system independent IO benchmark
  16. %J Computer Architecture News
  17. %V 17
  18. %N 5
  19. %D September 1989
  20. %P 55-70
  21. %x IOBENCH is an operating system and processor independent synthetic
  22. %x input/output (IO) benchmark designed to put a configurable IO and
  23. %x processor (CP) load on the system under test. This paper discusses
  24. %x the UNIX versions.
  25. %k IOBENCH, synthetic I/O benchmark, UNIX workload
  26. %s vinton%cello@hplabs.hp.com (Fri Sep 20 12:55:58 PDT 1991)
  27. %z Book
  28. %K Hennessy96
  29. %A John L. Hennessy
  30. %A David A. Patterson
  31. %T Computer Architecture A Quantitative Approach, 2nd Edition
  32. %I Morgan Kaufman
  33. %D 1996
  34. %z Article
  35. %K Chen94a
  36. %A P. M. Chen
  37. %A D. A. Patterson
  38. %T A new approach to I/O performance evaluation \- self-scaling I/O benchmarks, predicted I/O performance
  39. %D November 1994
  40. %J Transactions on Computer Systems
  41. %V 12
  42. %N 4
  43. %P 308-339
  44. %x Current I/O benchmarks suffer from several chronic problems: they
  45. %x quickly become obsolete; they do not stress the I/O system; and they
  46. %x do not help much in undelsi;anding I/O system performance. We
  47. %x propose a new approach to I/O performance analysis. First, we
  48. %x propose a self-scaling benchmark that dynamically adjusts aspects of
  49. %x its workload according to the performance characteristic of the
  50. %x system being measured. By doing so, the benchmark automatically
  51. %x scales across current and future systems. The evaluation aids in
  52. %x understanding system performance by reporting how performance varies
  53. %x according to each of five workload parameters. Second, we propose
  54. %x predicted performance, a technique for using the results from the
  55. %x self-scaling evaluation to estimate quickly the performance for
  56. %x workloads that have not been measured. We show that this technique
  57. %x yields reasonably accurate performance estimates and argue that this
  58. %x method gives a far more accurate comparative performance evaluation
  59. %x than traditional single-point benchmarks. We apply our new
  60. %x evaluation technique by measuring a SPARCstation 1+ with one SCSI
  61. %x disk, an HP 730 with one SCSI-II disk, a DECstation 5000/200 running
  62. %x the Sprite LFS operating system with a three-disk disk array, a
  63. %x Convex C240 minisupercomputer with a four-disk disk array, and a
  64. %x Solbourne 5E/905 fileserver with a two-disk disk array.
  65. %s toc@hpl.hp.com (Mon Mar 13 10:57:38 1995)
  66. %s wilkes%hplajw@hpl.hp.com (Sun Mar 19 12:38:01 PST 1995)
  67. %s wilkes%cello@hpl.hp.com (Sun Mar 19 12:38:53 PST 1995)
  68. %z InProceedings
  69. %K Ousterhout90
  70. %s wilkes%cello@hplabs.hp.com (Fri Jun 29 20:46:08 PDT 1990)
  71. %A John K. Ousterhout
  72. %T Why aren't operating systems getting faster as fast as hardware?
  73. %C Proceedings USENIX Summer Conference
  74. %c Anaheim, CA
  75. %D June 1990
  76. %P 247-256
  77. %x This paper evaluates several hardware pplatforms and operating systems using
  78. %x a set of benchmarks that stress kernel entry/exit, file systems, and
  79. %x other things related to operating systems. The overall conclusion is that
  80. %x operating system performance is not improving at the same rate as the base speed of the
  81. %x underlying hardware. The most obvious ways to remedy this situation
  82. %x are to improve memory bandwidth and reduce operating systems'
  83. %x tendency to wait for disk operations to complete.
  84. %o Typical performance of 10-20 MIPS cpus is only 0.4 times what
  85. %o their raw hardware performance would suggest. HP-UX is
  86. %o particularly bad on the HP 9000/835, at about 0.2x. (Although
  87. %o this measurement discounted a highly-tuned getpid call.)
  88. %k OS performance, RISC machines, HP9000 Series 835 system calls
  89. %z InProceedings
  90. %K McVoy91
  91. %A L. W. McVoy
  92. %A S. R. Kleiman
  93. %T Extent-like Performance from a Unix File System
  94. %C Proceedings USENIX Winter Conference
  95. %c Dallas, TX
  96. %D January 1991
  97. %P 33-43
  98. %z Article
  99. %K Chen93d
  100. %A Peter M. Chen
  101. %A David Patterson
  102. %T Storage performance \- metrics and benchmarks
  103. %J Proceedings of the IEEE
  104. %V 81
  105. %N 8
  106. %D August 1993
  107. %P 1151-1165
  108. %x Discusses metrics and benchmarks used in storage performance evaluation.
  109. %x Describes, reviews, and runs popular I/O benchmarks on three systems. Also
  110. %x describes two new approaches to storage benchmarks: LADDIS and a Self-Scaling
  111. %x benchmark with predicted performance.
  112. %k I/O, storage, benchmark, workload, self-scaling benchmark,
  113. %k predicted performance, disk, performance evaluation
  114. %s staelin%cello@hpl.hp.com (Wed Sep 27 16:21:11 PDT 1995)
  115. %z Article
  116. %K Park90a
  117. %A Arvin Park
  118. %A J. C. Becker
  119. %T IOStone: a synthetic file system benchmark
  120. %J Computer Architecture News
  121. %V 18
  122. %N 2
  123. %D June 1990
  124. %P 45-52
  125. %o this benchmark is useless for all modern systems; it fits
  126. %o completely inside the file system buffer cache. Soon it may even
  127. %o fit inside the processor cache!
  128. %k IOStone, I/O, benchmarks
  129. %s staelin%cello@hpl.hp.com (Wed Sep 27 16:37:26 PDT 1995)
  130. %z Article
  131. %K Fenwick95
  132. %A David M. Fenwick
  133. %A Denis J. Foley
  134. %A William B. Gist
  135. %A Stephen R. VanDoren
  136. %A Danial Wissell
  137. %T The AlphaServer 8000 series: high-end server platform development
  138. %J Digital Technical Journal
  139. %V 7
  140. %N 1
  141. %D August 1995
  142. %P 43-65
  143. %x The AlphaServer 8400 and the AlphaServer 8200 are Digital's newest high-end
  144. %x server products. Both servers are based on the 300Mhz Alpha 21164
  145. %x microprocessor and on the AlphaServer 8000-series platform architecture.
  146. %x The AlphaServer 8000 platform development team set aggressive system data
  147. %x bandwidth and memory read latency targets in order to achieve high-performance
  148. %x goals. The low-latency criterion was factored into design decisions made at
  149. %x each of the seven layers of platform development. The combination of
  150. %x industry-leading microprocessor technology and a system platform focused
  151. %x on low latency has resulted in a 12-processor server implementation ---
  152. %x the AlphaServer 8400 --- capable of supercomputer levels of performance.
  153. %k DEC Alpha server, performance, memory latency
  154. %s staelin%cello@hpl.hp.com (Wed Sep 27 17:27:23 PDT 1995)
  155. %z Book
  156. %K Toshiba94
  157. %A Toshiba
  158. %T DRAM Components and Modules
  159. %I Toshiba America Electronic Components, Inc.
  160. %P A59-A77,C37-C42
  161. %D 1994
  162. %z Article
  163. %K McCalpin95
  164. %A John D. McCalpin
  165. %T Memory bandwidth and machine balance in current high performance computers
  166. %J IEEE Technical Committee on Computer Architecture newsletter
  167. %V to appear
  168. %D December 1995
  169. %z Article
  170. %K FSF89
  171. %A Richard Stallman
  172. %Q Free Software Foundation
  173. %T General Public License
  174. %D 1989
  175. %O Included with \*[lmbench]