home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / unix_c / bnchmrks / iocall.c < prev    next >
Encoding:
C/C++ Source or Header  |  1989-03-21  |  3.2 KB  |  83 lines
  1.  3-Dec-85 04:27:29-MST,3288;000000000001
  2. Return-Path: <unix-sources-request@BRL.ARPA>
  3. Received: from BRL-TGR.ARPA by SIMTEL20.ARPA with TCP; Tue 3 Dec 85 04:27:25-MST
  4. Received: from usenet by TGR.BRL.ARPA id a014973; 3 Dec 85 5:42 EST
  5. From: Jan Stubbs <stubbs@ncr-sd.uucp>
  6. Newsgroups: net.sources
  7. Subject: IOCALL, a Unix sytem performance benchmark
  8. Message-ID: <346@ncr-sd.UUCP>
  9. Date: 2 Dec 85 19:59:24 GMT
  10. Keywords: benchmark
  11. To:       unix-sources@BRL-TGR.ARPA
  12.  
  13. "IOCALL, A UNIX SYSTEM PERFORMANCE BENCHMARK"
  14.  
  15. We have found the dhrystone benchmark to be very useful in predicting
  16. the performance of systems software written in 'C'.  Mr. Richardson
  17. points out several deficiencies in it however, which IOCALL, the following easy
  18. to run benchmark corrects:
  19.  
  20. > 1. Dhrystone does not do IO. Typical programs do but we'd open up a whole can > of worms. 
  21.  
  22. We aren't going to open this can completely, IOCALL does invoke UNIX system     calls to open, read write and close a file, but only the cpu cycles to do so aremeasured. Thus we avoid measuring the physical characteristics of the actual 
  23. disk device used on the system. Also, since we are really careful not to cross 
  24. the buffer boundary, UNIX won't do physical IO, it merely moves bytes to and 
  25. from the buffer cache, a function that is done much more often than physical IO,and therefore more important.
  26.  
  27. Also, many of the so-called IO throughput tests I have seen for UNIX
  28. are very sensitive to the size of the buffer cache on the system being
  29. measured. In many cases a sequence of writes followed by reads will do
  30. much physical IO on one system, but very little on another depending on
  31. the file size compared to buffer cache size which is an installation
  32. option for most unixes. IOCALL only uses one buffer (over and over) so
  33. it does not have this problem.
  34.  
  35. > 2. Dhrystone does not measure OS performance as it avoids calling the OS.
  36.  
  37. IOCALL measures OS performance, in fact that is nearly all it measures. It also concentrates on system call interface efficiency, and especially read()
  38. system call performance, the most used system call on most systems. IOCALL
  39. is intended for UNIX systems only. 
  40.  
  41. To create it, save in iocall.c, cut off the top, cc -o iocall.
  42. The way to time it is simply type:
  43. time iocall
  44.  
  45. The time to report is system time (normally output with accuracy to
  46. 10ths of a second), not real or user time. This introduces a new
  47. deficiency of course, namely trusting the OS to correctly report the
  48. system time.
  49.  
  50. VAX 11/780 times on BSD 4.2 are around 6 system seconds.
  51.  
  52. Please send results, comments, complaints, etc. directly to me and I will post  them to the net.
  53.                          
  54. "The opinions expressed herein are those of the author".
  55.  
  56. Jan Stubbs
  57. NCR Corp.
  58. San Diego, CA
  59. 619 485-3052
  60. ..sdcsvax!ncr-sd!stubbs
  61.  
  62. ------cut here------cut here-------------------------------
  63. /*This benchmark tests speed of Unix system call interface
  64.   and speed of cpu doing common Unix io system calls. */
  65.  
  66. char buf[512];
  67. int fd,count,i,j;
  68.  
  69. main()
  70. {
  71.  fd = creat("/tmp/testfile",0777);
  72.  close(fd);
  73.   fd = open("/tmp/testfile",2);
  74.   unlink("/tmp/testfile");
  75. for (i=0;i<=1000;i++) {
  76.   count = write(fd,buf,500);
  77.   lseek(fd,0,0);
  78.  
  79.   for (j=0;j<=3;j++) 
  80.       count = read(fd,buf,100);
  81.   }
  82. }
  83.