[comp.arch] IOCALL Benchmark Results Summary and Source

stubbs@ncr-sd.SanDiego.NCR.COM (Jan Stubbs) (06/20/87)

My last posting inadvertently left out the results for which we have
a new alltime winner:

IOCALL RESULTS  10,001 Iteration Version, 6/17/87

SYSTEM				UNIX VERSION		SYSTEM TIME SECONDS
-----------			----------------	-------------------
Dec Pro-380			2.9 BSD			184
MicroVax I			Ultrix V1.1		180
Altos 68000			SIII, Altos v2.0a	178.6
Dec Rainbow			Venix/86 v2.0		177.5
DEC Rainbow100 w/NECV20 	Venix/86		148 *d
Onyx C8002s Z8000		SIII			137 *a	
Onyx C8002 Z8000		v7			130
Symmetric 375 10MHz NS32016	4.2BSD			128.7
TIL NS32016 9MHz No Wait states	Local Port		122
PC/AT w/Sritek M68000		SV/68 Rel2 V1.0		114
Sequent Balance 21000 6 CPU				110.5 *c
PC Limited 286-6 6MHz 80286	SCO Xenix SV/286 V2.1.3	100.5
Tandy 6000 8Mhz M68000		Xenix 3.0		109 
ATT 3b2/300			SV			103
VAX 11/750			4.2 BSD			100
8 MHz 80286, 1 wait state	Microport SV/AT286 2.2u	98.5
PLexus P35 12.5 MHz M68000	SIII			98
ICM-3216 10 MHz NS 32016	SV.2			98
PDP 11/44			ISR 2.9 BSD		95
Motorola S2000 10MHz M68000	SV/68 Rel1		94
Concurrent XF/200 (PE7350A)	?			93
VAX 11/750			4.3 BSD			90
Sun-2 10MHz 68010		4.2 BSD Rel 2.0		90
Sun-2				4.2BSD Rel 3.2		88
VAX 11/750			SV.2			88
Sun-2 10MHz 68010		4.2 BSD Rel 3.0 	87
Plexus P60 M68000		SIII			87
PE 3220				V7 Workbench		85 *a
ATT 3b2/400			SV.2			83
VAX 11/750			research version 8	81
NCR PC-8 8MHz 80286		SCO Xenix-286 SV R2.0.4	72.7
VAX 11/750			4.1 BSD			72
Radio Shack 16A			Xenix (v7)		72 
Sperry IT 8MHz 80286		Xenix 5.0		71
VAX 11/750			4.1BSD (lightly hacked)	70
PC/AT 				Venix 5.2		68
Arete 1100 M680?0		SV.2			65 *c
ATT7300 Unix PC 10MHz 68010	SV.2			64
IBM PC/RT 170MHz		4.2BSD			64
Concurrent 3230			Xelos Rel R01 (SV)	64 
Gould PN6080			UTX 1.1C		62 
Pyramid 90x w/cache		OSx2.5			61
Apollo DN300 10 MHz M68000	Domain/IX		60 *e
IBM PC/RT 170MHz		?			60
Pyramid 90x w/cache		OSx2.3			58
Plessey Mantra 12.5Mhz 68000	Uniplus SV Release 0	55
MicroVax II			Ultrix/32-m V1.2	53.4
VAX 11/780			4.2 BSD			53
Concurrent 3250XP		Xelos Rel R01 (SV)	52 
MicroVax II			Ultrix 1.1		52
HP9000-550 3cpu's		HP-UX 5.01		51 *c 
PC/AT 7.5 Mhz			Venix286 SV.2		51
Sun 3/52 16MHz 68020					50.1
VAX 11/780			SV.2			50 
Convex C-1			4.2 BSD			46
Alliant FX/8 2 IPs, 4 CEs	Concentrix 2.0 (4.2BSD)	43.3 *c
IBM 4341 II			UTS 2.4(V7 on VM)	42   
Gould PN 6040			UTX/32 1.2		39.7
VAX 11/785			4.3 BSD			36
Sun-3/75 16.67Mhz 68020		4.2 BSD			36
Sun-3/160M-4 16.67Mhz 68020	4.2 BSD Rel 3.0 Alpha	36
DG MV10000			DG/UX 3.00		33
CT MightyFrame S/320 68020	CTIX (SV.2)		32.1
Apollo Dn330 12Mhz M68020	Domain/IX		30  *e
VAX 11/785			SV.2			30
Celerity 1230 Accel/32 (NCR/32)	4.2 BSD			30  
Gould Concept/97		UTX/32 1.2 (4.3BSD/SV2)	28
GEC 63/40			S 5.1			27
Gould PN9080			UTX 1.2	(4.3BSD)	25
Sperry 7000/40 aka CCI 6/32	4.2 BSD			19
VAX 8600			4.3 BSD			12
VAX 8600			Ultrix 1.2-1		11
IBM 3083			UTS SV			10  
Amdahl 470/V8			UTS/V (SV Rel 2,3)V1.1+ 9  
Cray X/MP-24			SysV (Pre release 8)    3.8
Amdahl 5890			UTS SV.2		3.63


Notes:
*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. A better measurement of this system's capability
is to run as many copies of IOCALL as there are processors, in a script
with unique file names, and report half the sum of the resulting system times, 
which should be about the same on each processor, but slightly longer than 
the single copy time.

*e
Real time reported because system time appeared to be unreasonable.
Some implementations of Unix kernel don't charge for CPU time to
do IO properly.

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).

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".
 
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.

I have had some criticism of this benchmark to whit:
It unfairly penalizes machines which do not have CPU data cacheing on the
Unix buffer pool.

My Response:
It does penalize such machines, because it heavily emphasizes the function
of copying data from the buffer pool and back again. No benchmark is
perfect, but this one shows what a very IO intensive workload might
be like on your machine.

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-------------------------------

/*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++) {
  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);
  }
}
-----cut---cut---cut---cut-----------------------------------------
"There are lies, damn lies, and benchmarks."

Jan Stubbs    ....sdcsvax!ncr-sd!stubbs
619 485-3052
NCR Corporation Advanced Development
16550 W. Bernardo Drive MS4010
San Diego, CA. 92127

markb@mitisft.Convergent.COM (Mark Beyer) (06/22/87)

In article <1594@ncr-sd.SanDiego.NCR.COM>, stubbs@ncr-sd.SanDiego.NCR.COM (Jan Stubbs) writes:
> Send your results to me directly. 

Jan,
My email couldn't get to you so I'm posting this instead.

Here's the results for our new machine:

Machine:	Convergent Server/PC
CPU:		20MHZ 80386
OS:		Unix System V.3

The times are:

real:	20.41
user:	1.21
sys:	19.0

Mark Beyer