IOCALL results and problems

[Jan Stubbs]

	IOCALL, A UNIX SYSTEM PERFORMANCE BENCHMARK
The results so far are below. Thanks everybody.
Send your results to me directly. The benchmark is a "C" program
which measures Unix kernel performance. 

time iocall     Send all 3 times (user, system, real)
                I am reporting the system time only.
         
"The opinions expressed herein are those of the author. Your mileage may vary".
 
Problems:

1) As Jeff Makey kindly pointed out, IOCALL unfortunately does cross a
buffer boundary if your buffer size is 512. Older versions of Unix
(Version 7, System III) and their progeny were 512. Berkeley 4.2, 4.3,
System V and their progeny are 1024 or bigger, so no problem with those
numbers. But all the numbers sent to me for the 512 byte buffer unixes
are slower than they should be because they did over 1000 disk writes
which uses lots of cpu cycles in the drivers. I don't know about
Version 8 or 2.9 BSD, can anyone help?

Jeff offered a solution, which adds a seek to keep everything in the
1st 512 bytes. This makes the kernel do a little extra work, but it did
not change the timing on our Pyramid. The new source is below, if you
have a 512 byte buffer version of Unix please rerun with this one.

2) Jeff and others also pointed out that the 2nd argument to lseek
should be a long not an int. Shame on me! See what happens when you
don't lint your programs? The source below also fixes this. Reruns may
be required to get correct results on machines where longs aren't the
same as ints. (PDP's...).

3) I failed to mention that these timings should be run on an otherwise
idle machine. If you can please run them so, it does improve the
timings.

4) Since not everyone is a good sport about benchmarks, and since I
might be a biased source, and since I don't have access to the latest
NCR Unix stuff anyhow (the M68020 based Tower/32) I won't publish any
NCR numbers, unless offered to me by NCR E&M Columbia which is where
the Tower line comes from. I encourage someone else to do so however.


Jan Stubbs ..sdcsvax!ncr-sd!stubbs
              
IOCALL RESULTS:

SYSTEM				UNIX VERSION		SYSTEM TIME SECONDS
-----------			----------------	-------------------
DEC Rainbow100 w/NECV20 	Venix			18.4 *a
DEC Pro-300			Venix 1.1		18.1 *a
MicroVax I			Ultrix V1.1		18.0
Onyx C8002s Z8000		SIII			13.7 *a	
Onyx C8002 Z8000		v7			13.3 *a
TIL NS32016 9MHz No Wait states	Local Port		12.2
ATT 3b2/300			SV			10.3
VAX 11/750			4.2 BSD			10.0
PDP 11/44			ISR 2.9 BSD		9.5
VAX 11/750			SV.2			9.4
VAX 11/750			4.3 BSD			9.0
Sun-2 10MHz 68010		4.2 BSD Rel 2.0		9.0
Sun-2 10MHz 68010		4.2 BSD Rel 3.0 	8.7
PE 3220				V7 Workbench		8.5 *a
VAX 11/750			research version 8	8.1
VAX 11/750			4.1 BSD			7.2
Radio Shack 16A			Xenix (v7)		7.2 *a
PC/AT 				Venix 5.2		6.8
ATT7300 Unix PC 10MHz 68010	SV.2			6.4
Bullet286(PC/XT)		Venix 2.0		6.0 *a
Pyramid 90x w/cache		OSx2.3			5.8
VAX 11/780			4.2 BSD			5.7
Plessey Mantra 12.5Mhz 68000	Uniplus SV Release 0	5.5
MicroVax II			Ultrix 1.1		5.2
HP9000-550 3cpu's		HP-UX 5.01		5.1 *c
PC/AT 7.5 Mhz			Venix286 SV.2		5.1
Convex C-1			4.2 BSD			4.6
VAX 11/785			SV.2			4.4
VAX 11/785			4.3 BSD			3.6
Sun-3/75 16.67Mhz 68020		4.2 BSD			3.6
Sun-3/160M-4 16.67Mhz 68020	4.2 BSD Rel 3.0 Alpha	3.6
GEC 63/40			S 5.1			2.7
Gould PN9080			UTX 1.2			2.5
Sperry 7000/40 (aka CCI 6/32)	4.2 BSD			1.9 *b
VAX 8600			4.3 BSD			1.3
VAX 8600			Ultrix 1.2-1		1.1
IBM 3083			UTS SV			1.0 *b
Amdahl 470/V8			UTS/V (SV Rel 2,3)V1.1+ .98 *b

Notes:

*a 
This result obtained with original version of IOCALL which crosses the 512
512 byte buffer boundary, and this version of Unix has buffers of 512 bytes.
This is believed to be the case with all Version 7 and SIII derived OS's. It
will result in a 1001 writes being done which uses significantly more cpu time 
and makes these results comparable only to others with the same problem. See 
discussion above. 2.9 BSD????

*b 
This result was obtained with a system which probably had other programs runningat the time the result was obtained. Submitter is requested to rerun if possiblewhen system is idle. This will improve the result somewhat.

*c
Multi-cpu system. IOCALL was run single thread, which probably did not
utilize all cpu's. This system probably has considerably more power than
is reflected by the result.





-------cut----cut------cut-------------------------------

/*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<=1000;i++) {
  lseek(fd,0L,0);		/* add this line! */
  count = write(fd,buf,500);
  lseek(fd,0L,0);		/* second argument must be long */

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