From: sim@cory.Berkeley.EDU (Peng-Toh Sim) Subject: Re: IDE faster than Mips SCSI disk Date: Sat, 7 Nov 1992 21:20:03 GMT
In article <MAD.92Nov7220823@amber.math.keio.ac.jp> mad@math.keio.ac.jp writes:
>In article <1992Nov6.033942.21194@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
[deleted]
>[deleted]
> >IOZONE performance measurements:
> > 367586 bytes/second for writing the file
> > 499942 bytes/second for reading the file
>
>The PC result looks reasonable. But mips result seem to be too slow
>for SCSI-2 disks. Maybe because (as Phillip Fayers written in
><13481.9211061131@thor.cf.ac.uk>) poor I/O performance of Ultrix. But
>I think larger buffer size (e.g. 8192 bytes) would be better for
>testing disk drive/interface performance, while smaller buffer size
>test can measure total I/O performance including OS/library overhead.
>
>On SparcStation1+ with SCSI drive, running SunOS 4.1.1, I get:
>
>32M file, 512bytes buffer:
>IOZONE performance measurements:
> 204348 bytes/second for writing the file
> 556120 bytes/second for reading the file
>
>32M file, 8192bytes buffer:
>IOZONE performance measurements:
> 653760 bytes/second for writing the file
> 1207012 bytes/second for reading the file
>
>Hmm... SunOs, too, seems to have significant overhead with small buffers.
>Is this figure mean ISA machine running 386bsd beats SparcStation1+ in I/O?
>PCs are widely believed to be "comparable to WS in CPU speed, but far
>more slower in I/O".
>
>I'm very interested in the result of EISA SCSI-2 with large file size
>& large buffer size, if it's available.
>
>;;; Keio University
>;;; Faculty of Science and Technology
>;;; Department of Math
>;;; MAEDA Atusi (In Japan we write our family names first.)
>;;; mad@math.keio.ac.jp
Hi
Here is the set up of 386BSD system:
486/33 ISA, 16M RAM, BusTek 542B, 0.1 kernel with patchkit alpha 2,
using default as0 SCSI driver (not Julian's new driver).
The disk is a CDC WREN VI 94191-766 with a disk platter
transfer rate of about 1.5Mbyte/s (by dd'ing the whole disk
through the raw partition with a HUGE buffer or you calculate
it with the various disk parameters.) This is NOT a SCSI II drive.
The filesystem is formatted with 8k blocksize and 1k fragment size
(I think this makes a difference.)
The iozone results:
(Other processes includes 4 xterms and a 2 emacs and gofer interpreter
eating up 12megs of virtual memory but all these does not matter because
they are all sleeping and I get the SAME result when I repeated the test
in the default text console.)
libra 74 % iozone 32
IOZONE: Performance Test of Sequential File I/O -- V1.15 (5/1/92)
By Bill Norcott
Operating System: POSIX 1003.1-1988
Send comments to: norcott_bill@tandem.com
IOZONE writes a 32 Megabyte sequential file consisting of
65536 records which are each 512 bytes in length.
It then reads the file. It prints the bytes-per-second
rate at which the computer can read and write files.
Writing the 32 Megabyte file, 'iozone.tmp'...44.116667 seconds
Reading the file...43.433333 seconds
IOZONE performance measurements:
760584 bytes/second for writing the file
772550 bytes/second for reading the file
libra 75 % iozone 32 8192
[deleted]
IOZONE writes a 32 Megabyte sequential file consisting of
4096 records which are each 8192 bytes in length.
Writing the 32 Megabyte file, 'iozone.tmp'...43.966667 seconds
Reading the file...43.516667 seconds
IOZONE performance measurements:
763179 bytes/second for writing the file
771071 bytes/second for reading the file
libra 82 % df .
Filesystem 1024-blocks used available capacity Mounted on
/dev/as0h 388575 204896 144821 59% /local
[deleted]
libra 61 # disklabel as0
# /dev//ras0c:
type: SCSI
disk: CDC94191-766
label: Ha
flags:
bytes/sector: 512
sectors/track: 54
tracks/cylinder: 15
sectors/cylinder: 805 # 54*15 - 5 alt sectors per cylinder
cylinders: 1632
rpm: 3600
interleave: 1
trackskew: 0 # doesn't seem to be used by the kernel at all
cylinderskew: 0 # doesn't seem to be used by the kernel at all
headswitch: 0 # milliseconds
track-to-track seek: 4 # milliseconds
drivedata: 0
8 partitions:
# size offset fstype [fsize bsize cpg]
a: 32200 0 4.2BSD 1024 8192 0 # (Cyl. 0 - 39)
b: 64400 32200 swap # (Cyl. 40 - 119)
c: 1312150 0 unused 0 0 # (Cyl. 0 - 1629)
g: 412160 96600 4.2BSD 1024 8192 0 # (Cyl. 120 - 631)
h: 803390 508760 4.2BSD 1024 8192 0 # (Cyl. 632 - 1629)
I think this figures compares favourably with the IDE numbers :)
But I don't understand why reads are not faster than writes.
Well, I've to say I'm fairly pleased since this system is for a
single user. Large make's are quite fast because the only major
disk traffic are the *.[chso] files as most of gcc/cpp/make/as
remains in memory. How do I know? I can hear the disk accesses :)
(unless there is some other way to measure the amount of paging.)
PT
sim@cory.berkeley.edu