call for iocall times (REPOST)

[Michael Lodman]

{ As my good buddy Jan Stubbs at NCR hasn't had time to handle this lately,
(what with them fighting off Ma Bell and all) and I am extremely interested 
in the results, I am posting a request for people to run and report the times 
for the iocall benchmarks for various systems. I will compile and post the 
results. Thanks in advance for the help. } - Mike

Send your results to me directly. The benchmark is a "C" program
which measures Unix kernel performance. 

To run it put the source below in iocall.c, then:
cc iocall.c -o iocall
time iocall     

Send all 3 times (user, system, real), but I am reporting the system
time only. The user time for this benchmark should be insignificant.
The real time should be about equal to system time plus user time, if not
you aren't running a real Unix, or your Unix has a bug. (Some people have
reported finding a bug in their port after running IOCALL). On BSD systems,
which report the number of IO's from TIME command, the number of IO's should
be 2 or 3 for the open, and a few paging io's to read in the program.

Please also send:
1)Type of machine and model #. 
2) Brand, model and clock rate of Microprocessor if any.
3) Version and name of OS, and its ancestry (e.g. SV2 or BSD 4.2)
         
The opinions expressed herein are those of the author. Your mileage may vary.
The times herein are obtained from unreliable sources, rely on them at 
your peril.
 
Benchmark should be run on an otherwise idle machine. If you can please 
run them so, it does improve the timings.

COMMENTARY:
What does this benchmark measure? It attempts to simulate a typical mix
of reading, writing and seeking. The cpu time used in the Unix kernel is
reported by the kernel.

It exercises the system call interface in a way less trivial than the 
getpid benchmark. It does not measure and is independent of, your IO hardware, 
and drivers. It does seem to show differences in Unix kernel efficiency on 
the same hardware.  It will exercise heavily your caches, and perhaps 
your block move bandwidth.

NO BENCHMARK IS PERFECT, (except your application),
but this one shows what a very IO intensive workload with good buffer
cache hit rates runs like on your cpu. 

Many synthetic benchmarks are criticized for giving unrealistic
results when run through optimizers that may throw out stuff that
does nothing useful. This is NOT a problem with IOCALL. If your
compiler finds something in the UNIX kernel that does nothing useful
and throws it out, MORE POWER TO IT!


-------cut----cut------cut-------------------------------
/* iocall.c by Jan P. Stubbs */

/*This benchmark tests speed of Unix system call interface
  and speed of cpu doing common Unix io system calls. */

char buf[512];
int fd,count,i,j;

main()
{
 fd = creat("/tmp/testfile",0777);
 close(fd);
 fd = open("/tmp/testfile",2);
 unlink("/tmp/testfile");
 for (i=0;i<=10000;i++) {
  	/*do seek, write, seek, read, read, read. */
 	lseek(fd,0L,0);		
 	count = write(fd,buf,500);
 	lseek(fd,0L,0);

 	for (j=0;j<=3;j++) 
	 	count = read(fd,buf,100);
  }
}
-----cut---cut---cut---cut-----------------------------------------

-- 
Michael Lodman	Department of Computer Science Engineering
	University of California, San Diego
jlodman at cs.ucsd.edu			(619) 672-1673


-- 
Michael Lodman	Department of Computer Science Engineering
	University of California, San Diego
jlodman at cs.ucsd.edu			(619) 672-1673