bt455s39@uhccux.uhcc.Hawaii.Edu (Carmen Hardina) (01/17/91)
In article <1991Jan16.094432.21159@eng.ufl.edu> jc@joker.mil.ufl.edu (Jim Castleberry) writes: >As much as I despise benchmark hype, I hate to ask this, but I'm >looking at a throughput problem and need a reference. [....] >controller type, and disk type if you know them. I expect it to take >between 10 seconds and 2 minutes. > >I have 1 MFM drive and 1 SCSI (on separate controllers). Both drives >do only 93k per second out of a possible 400+! Is Xenix really that >slow??? > >Jim Castleberry >jc@joker.mil.ufl.edu On an Everex 3000A (386DX/16MHz) running SCO XENIX 386 2.3.2 with an Adaptec ACB-2372B RLL Hard/Floppy Controller and a Maxtor XT-1140 MFM Hard Disk (1:1 int., 28ms, 1024 Cyl., 15 Hds., 26 Sec./Trk., 183MB) it took 35 seconds. That's approximately 286K per second. The Adaptec is rated at about 900K/Sec. and utilities like The Power Meter under DOS reaffirm that fact. That's a big difference in speed between the two operating systems. BTW, the CPU is rated at 3.4 VAX MIPS has 3MB of RAM. Is dd really a reliable way of judging transfer rate?
stratton@hpcupt1.cup.hp.com (Jim Stratton) (01/18/91)
In comp.unix.xenix.sco, jc@joker.mil.ufl.edu (Jim Castleberry) writes: > Someone with Xenix 386 do me a favor and try the following on your > machine (you'll have to be root to open the device). > dd if=/dev/rhd00 of=/dev/null bs=100k count=100 > It's absolutely harmless - just reading 10 meg into the bit bucket. > I'd like to know how many seconds it took, plus your Xenix version, > controller type, and disk type if you know them. I expect it to take > between 10 seconds and 2 minutes. I timed this test on my system with the following results (averaged over 3 runs): SCO Xenix 2.3.3 SCO Unix/V 3.2.2 Real: 44.0 14.9 User: 0.0 0.0 Sys: 2.1 6.3 Vitals are: 4MB 25Mhz 386; Maxtor XT-4380E 380MB ESDI drive, 1:1 interleave, Adaptec controller. The drive specs claim 18ms avg seek time. I have both Xenix and Unix installed on this drive -- I'm in the process of converting over to Unix. And with these rather illuminating results, I'm going to hasten my conversion! -- Jim Stratton stratton@hpodb02.cup.hp.com Hewlett-Packard Company
kevin@iisat.uucp (Kevin Davies) (01/18/91)
In article <10988@uhccux.uhcc.Hawaii.Edu>, bt455s39@uhccux.uhcc.Hawaii.Edu (Carmen Hardina) writes: > In article <1991Jan16.094432.21159@eng.ufl.edu> jc@joker.mil.ufl.edu (Jim Castleberry) writes: > >As much as I despise benchmark hype, I hate to ask this, but I'm > >looking at a throughput problem and need a reference. > [....] > >controller type, and disk type if you know them. I expect it to take > >between 10 seconds and 2 minutes. > > > >I have 1 MFM drive and 1 SCSI (on separate controllers). Both drives > >do only 93k per second out of a possible 400+! Is Xenix really that > >slow??? > > > ... > ................... That's approximately 286K per second. The Adaptec > is rated at about 900K/Sec. and utilities like The Power Meter under > DOS reaffirm that fact. That's a big difference in speed between the > two operating systems. To make things more accurate to a 'hardware' level, which is what most of these utilities do, you should use /dev/hd00 and not /dev/rhd00 I did just a quickie test of ~2.7MB and got the following : /dev/hd00 -- ~ 13s /dev/rhd00 - ~ 33s I think this accounts for the large difference. hd00 is the block device, which is faster than the character device of rhd00 -- Kevin Davies International Information Service (IIS) UUCP: {uunet,utai,watmath}!dalcs!iisat!kevin Bitnet/Uucp: kevin@iisat.uucp
jfh@rpp386.cactus.org (John F Haugh II) (01/18/91)
In article <N025FC.91Jan17133808@tamuts.tamu.edu> n025fc@tamuts.tamu.edu (Kevin Weller) writes: >In article <1991Jan16.094432.21159@eng.ufl.edu> jc@joker.mil.ufl.edu (Jim Castleberry) writes: > Someone with Xenix 386 do me a favor and try the following on your > machine (you'll have to be root to open the device). > dd if=/dev/rhd00 of=/dev/null bs=100k count=100 > >I did and it took 33 seconds, system load was minimal at the time. I >have version 2.3.3, an IDE controller and a Conner 105 meg drive. I have an old machine, please have pity on my soul and send me new stuff ;-) This is a Wyse 3216 with an old WD controller and a Micropolis 71MB drive. It took 64 seconds :-(. I could hear the heads stepping off and they were going about as fast as I've ever heard them go while actually doing anything, so I feel comfortable that 64 seconds is a fairly minimum amount of time for a 100KB block size on this piece of hardware. I am running 2.2.3 and had to write a little C program because "dd" wouldn't take 100k as the block size. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
bill@bilver.uucp (Bill Vermillion) (01/20/91)
In article <N025FC.91Jan17133808@tamuts.tamu.edu> n025fc@tamuts.tamu.edu (Kevin Weller) writes: > In article <1991Jan16.094432.21159@eng.ufl.edu> jc@joker.mil.ufl.edu (Jim Castleberry) writes: > Someone with Xenix 386 do me a favor and try the following on your > machine (you'll have to be root to open the device). > dd if=/dev/rhd00 of=/dev/null bs=100k count=100 > It's absolutely harmless - just reading 10 meg into the bit bucket. > I'd like to know how many seconds it took, plus your Xenix version, > controller type, and disk type if you know them. I expect it to take > between 10 seconds and 2 minutes. >I did and it took 33 seconds, system load was minimal at the time. I >have version 2.3.3, an IDE controller and a Conner 105 meg drive. Ran this on an IBM 80, 20MHz '386, 2 megs memory, 110 Meg IBM ESDI drive, Xenix 2.2.3, and got 1:48.9 real time using the time command. For comparison on ESIX Unix V.2.D, with a 25 MHz '386, 8megs of memory, 8760E Maxtor ESDI drive with FFS got 0:17.9 real time. I know you didn't ask for the latter but the two machines are about 3 feet apart so I decided, what the heck! That makes the Xenix on IBM ~91K/sec and the Unix on generic give about 558K/sec. -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
src@scuzzy.in-berlin.de (Heiko Blume) (01/23/91)
bill@bilver.uucp (Bill Vermillion) writes: >For comparison on ESIX Unix V.2.D, with a 25 MHz '386, 8megs of memory, >8760E Maxtor ESDI drive with FFS got 0:17.9 real time. just to frustrate you, ISC 2.2.1 on a 33MHz 386, 8MB ram, CDC Wren V SCSI drive hanging off aha-1542: 6.8 seconds real time. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
usenet@carssdf.UUCP (John Watson) (01/23/91)
> > Someone with Xenix 386 do me a favor and try the following on your > > machine (you'll have to be root to open the device). > > dd if=/dev/rhd00 of=/dev/null bs=100k count=100 > > >I did and it took 33 seconds, system load was minimal at the time. I > >have version 2.3.3, an IDE controller and a Conner 105 meg drive. > Ran this on an IBM 80, 20MHz '386, 2 megs memory, 110 Meg IBM ESDI > drive, Xenix 2.2.3, and got 1:48.9 real time using the time command. > For comparison on ESIX Unix V.2.D, with a 25 MHz '386, 8megs of memory, > 8760E Maxtor ESDI drive with FFS got 0:17.9 real time. I have been watching all this intently and wondering if I should switch from Xenix 2.3.3 to SCO UNIX, just for the disk speed. My 486 is not out of gas on CPU, but disk access is limiting us. The 486-25 is generic. The disk controller is Consensys Powerstore, 4Meg Cache on Controller, ESDI Drives, CDC WREN V model 94196-766 (670Meg), & Fujitsu M2263E (687Meg). I got 12.5 & 11.1 Sec. Real Time. One drive is faster than the other, but I don't know which. I repeated several times. CPU time is about 8 sec. John Watson Independent Consultant and Perl Disciple ...!rutgers!carssdf!usenet
macleod@cmllab.rgb.sub.org (Connor MacLeod) (01/23/91)
In article <53430001@hpcupt1.cup.hp.com> stratton@hpcupt1.cup.hp.com (Jim Stratton) wrote: | I timed this test on my system with the following results (averaged over | 3 runs): | | SCO Xenix 2.3.3 SCO Unix/V 3.2.2 | | Real: 44.0 14.9 | User: 0.0 0.0 | Sys: 2.1 6.3 | | Vitals are: 4MB 25Mhz 386; Maxtor XT-4380E 380MB ESDI drive, 1:1 interleave, | Adaptec controller. The drive specs claim 18ms avg seek time. Up to now I only had the chance to run this test under UNIX 3.2v2. That's what I've got: (macleod) 2 / time dd if=/dev/rhd00 of=/dev/null bs=100k count=100 100+0 records in 100+0 records out 0.0u 2.9s 0:13 22% (macleod) 3 / time dd if=/dev/hd00 of=/dev/null bs=100k count=100 100+0 records in 100+0 records out 0.0u 7.6s 0:18 42% My vitals are: 12MB 33MHz 386 (32K Cache); WREN 766MB SCSI drive; Adaptec 1542b at 5MBytes/sec DMA Transfer Speed I hope this is of some help... Rgds -- Connor MacLeod <set _aka = 'Uwe Obst'> -->========- <set _adr = '{connor|macleod}@cmllab.rgb.sub.org'> <set _rem = 'Don't loose your head !'> <set _btw = '"Trust me, I know what I'm doing"--Sledge Hammer'>
horke@rhoen.in-berlin.de (Bernhard Kroenung) (01/24/91)
macleod@cmllab.rgb.sub.org (Connor MacLeod) writes: >0.0u 7.6s 0:18 42% >My vitals are: 12MB 33MHz 386 (32K Cache); WREN 766MB SCSI drive; Adaptec > 1542b at 5MBytes/sec DMA Transfer Speed real : 19.5 user : 0.0 sys : 8.9 8Mb 25MHz 386/387 (no Cache); Conner CP3214 (210Mb IDE-Drive) with Xenix 2.3.3 DOS : 1.5Mb/sec (Core-Test) Ciao Bernhard -- Bernhard Kroenung, Bahnhofstr. 8, D-W6408 Ebersburg/Rhoen, Germany +49 6656 386 horke@rhoen.in-berlin.de X.400 : kronung@jlug-gw.uni-giessen.dbp.de
itkin@mrspoc.Transact.COM (Steven M. List) (01/28/91)
bill@bilver.uucp (Bill Vermillion) writes: >In article <N025FC.91Jan17133808@tamuts.tamu.edu> n025fc@tamuts.tamu.edu (Kevin Weller) writes: >> In article <1991Jan16.094432.21159@eng.ufl.edu> jc@joker.mil.ufl.edu (Jim Castleberry) writes: > >> Someone with Xenix 386 do me a favor and try the following on your >> machine (you'll have to be root to open the device). >> dd if=/dev/rhd00 of=/dev/null bs=100k count=100 >> It's absolutely harmless - just reading 10 meg into the bit bucket. >> I'd like to know how many seconds it took, plus your Xenix version, >> controller type, and disk type if you know them. I expect it to take >> between 10 seconds and 2 minutes. > >>I did and it took 33 seconds, system load was minimal at the time. I >>have version 2.3.3, an IDE controller and a Conner 105 meg drive. > >Ran this on an IBM 80, 20MHz '386, 2 megs memory, 110 Meg IBM ESDI >drive, Xenix 2.2.3, and got 1:48.9 real time using the time command. UCK - I ran this on my Everex Step 25, DPT controller with 12.5MB cache RAM, MAXTOR 650+MB disk, minimal load - 68 SECONDS! I'm astounded. Sigh. This is, as asked, SCO XENIX (v2.3.3). -- +----------------------------------------------------------------------------+ : Steven List @ Transact Software, Inc. :^>~ : : Chairman, Unify User Group of Northern California : : {apple,coherent,limbo,mips,pyramid,ubvax}!itkin@guinan.Transact.COM :
alan@ahmcs.com (Alan Mintz) (02/01/91)
In article <1991Jan16.094432.21159@eng.ufl.edu> jc@joker.mil.ufl.edu (Jim Castleberry) writes: > Someone with Xenix 386 do me a favor and try the following on your > machine (you'll have to be root to open the device). > dd if=/dev/rhd00 of=/dev/null bs=100k count=100 > It's absolutely harmless - just reading 10 meg into the bit bucket. > I'd like to know how many seconds it took, plus your Xenix version, > controller type, and disk type if you know them. I expect it to take > between 10 seconds and 2 minutes. Dell 310 (20Mhz 386DX), 338Mb Micropolis 16ms ESDI with Ultrastor 12F. SCO XENIX 2.3.2(3) 878K buffers: $ time dd if=/dev/rhd00 of=/dev/null bs=100k count=100 real 17.3 user 0.0 sys 3.0 -- < Alan H. Mintz | Voice +1 714 980 1034 > < Micro-Quick Systems, Inc. | FAX +1 714 944 3995 > < 10384 Hillside Road | ...!uunet!ahmcs!alan > < Alta Loma, CA 91701 USA | alan@mq.com >
billbr@xstor.UUCP (Bill Brothers) (02/02/91)
In article <10988@uhccux.uhcc.Hawaii.Edu> bt455s39@uhccux.UUCP (Carmen Hardina) writes:
<blah blah benchmark, etc. etc.>
Something interesting has happened here. Massive insane irrelevant
testing. If you run the dd in question against the block device
(/dev/hd00), then size of disk buffers makes a radical difference
in the outcome, since the actual writes to the disk may occur AFTER
time has completed due to delayed writes. If you run against the
raw device, total mis-information results, since SCO XENIX uses
a single buffer for raw transfers and copies the information into
user space. Voila! a bottleneck. Another problem is if
you are running single user (maintenance mode) or multi-user.
multi-user will change the numbers appreciably. Around here, we
actually do the dd time test under the following conditions.
1. single user mode
2. kernel tuned to 50 buffers (yes thats right, 50!)
This is so that we stress our drivers instead of the
memory :-)
3. time dd if=/dev/hd00 of=/dev/null bs=64k count=100
This is so that the test will be consistent from
UNIX to XENIX.
We use this as a _GROSS_ measurement of performance. There are
still many inaccuracies in doing this.
The results that we have found seem to reflect OS changes as
opposed to disk/controller technology. Sure.. they make a
difference, but not the same factor as OS.
XENIX -> UNIX 3.2.0 = About the same
UNIX 3.2.0 -> 3.2.3 = 2X faster.
What happened? The Acer File System (AFS) seemed to have
gotten fixed in 3.2.2. On a Systempro 386 with 1 processor
we measured 75 Kb/s. Running 3.2.2 yielded 850 Kb/s.
Relieving the disk buffers to 650 pushed the number to
around 1 Mbyte/s. Going to MPX with two processors and a
distributed driver, and 650 disk buffers yields 1034 Kb/s.
Certainly better performance. This is because the driver
gets 8-16K requests instead of 1K requests. The AFS clusters
sequential accesses. This was using SCSI host adapters and
SEAGATE WrenRunner II's.
What we found is that the overhead in the UNIX cacheing scheme
is the bottleneck as it tends to start being processor-bound.
So far, the maximum data rate through the UNIX file system
seems to be 1.5 Mbytes/s.
All tests here were done with Storage Dimensions drivers, but
reflect similar performance in the native drivers.
One other note: Just because one disk goes REAL FAST on a
sequential test, It cannot be concluded that it will perform
better when accessed randomly at high IO rates. In UNIX,
the name of the game is fast access, not high data rate.
This is because most UNIX filesystems are helter-skelter.
Bill Brothers
Engineering Mgr.
Storage Dimensions, Inc.
uunet!xstor!billbr | Information is power. -- Be empowered.