Xref: utzoo comp.unix.sysv386:5391 comp.unix.xenix.sco:1781
Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!unixland!bill
From: bill@unixland.uucp (Bill Heiser)
Newsgroups: comp.unix.sysv386,comp.unix.xenix.sco
Subject: Re: high speed drives
Message-ID: <1991Feb22.225505.6510@unixland.uucp>
Date: 22 Feb 91 22:55:05 GMT
References: <1351@icdi10.UUCP> <790@tiamat.fsc.com> <797@tiamat.fsc.com>
Organization: Think_Tank BBS & Public Access Unix
Lines: 53

In article <797@tiamat.fsc.com> jim@tiamat.fsc.com ( IT Manager) writes:
>> 
>> from "time dd if=/dev/XXXX of=/dev/null bs=100k count=10"
>> 
>> for the Miniscribe 3180S
>> 10+0 records in
>> 10+0 records out
>> 
>> real        17.7
>> user         0.0
>> sys          0.4
>
>under Unix:
>real        3.0
>user        0.0
>sys         0.2
>
>From the looks of those numbers, it seems that the data you have on the
>drive (or how it is arranged) can have something to do with the performance
>under this type of test.

This is interesting.  I tried reading several different partitions 
(/dev/dsk/0s0, /dev/dsk/0s1, /dev/dsk/0s3, etc), and all came out about
like this:

Script started on Fri Feb 22 17:49:25 1991
# sh
# time dd if=/dev/dsk/0s3 of=/dev/null bs=100k count=10
10+0 records in
10+0 records out

real        7.6
user        0.0
sys         1.5
# # 
script done on Fri Feb 22 17:49:47 1991

This is on a 386/25 running Esix-D.  /dev/dsk/0s3 is my /usr partition
(where about 100mb worth of Usenet News is sitting).  The disk is
a CDC Wren IV (94171-307).

Your "real time" numbers seemed to vary from 3.0 to 8.0 -- Mine
seemed to stay about the same.  Maybe system loading, different buffer
cache size, or some other factor?

Bill


-- 
home:	...!{uunet,bloom-beacon,esegue}!world!unixland!bill
	bill@unixland.uucp              The Think_Tank BBS & Public Access Unix
508-655-3848 (2400)   508-651-8723 (9600-HST)   508-651-8733 (9600-PEP-V32)
other:	heiser@world.std.com