usenet@mcdchg.UUCP (06/18/87)
My last posting inadvertently left out the results for which we have
a new winner. Also several people sent me results which don't appear here
because of an accidental stroke of a key which deleted them. Please
send them again if you don't see yours here.
IOCALL RESULTS 10,001 Iteration Version, 6/7/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
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
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
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
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:
General: Times with fractional parts of a second are from the
latest (10,000) iterations version of the benchmark, except for the Cray.
The times from the 1000 iteration previous version have been multiplied
by ten.
*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.
IOCALL, A UNIX SYSTEM PERFORMANCE BENCHMARK
Results as of 5/20/87.
This version of the benchmark does 10,000 iterations instead of
1000. Unix machines are getting so fast that 1000 was too quick
to measure accurately on some CPU's.
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 is usually insignificant.
"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. 92127stubbs%ncr-sd.SanDiego.NCR.COM@sdcsvax.ucsd.edu (Jan Stubbs) (06/30/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