pvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) (01/23/90)
OK. Here's an /etc/disktab entry for a factory-formatted Wren V 94181-702.
See below to determine if this is the same formatting you have.
I hope this is applicable and helpful -- use at your own risk!!
-----------------------------------------------------------------
#
# 16 jan 89
# Paul O'Neill -- Coastal Imaging Lab -- OSU -- Corvallis, OR
#
# Wren V 94181-702 w/ 512 byte sectors, 1 spare sector/track, 2 spare cylinders
#
CDC 94181-15:\
:ty=fixed_rw_scsi:nc#1505:nt#15:ns#26:ss#1024:rm#3600:\
:fp#160:bp#0:ng#0:gs#0:ga#0:ao#0:\
:os=sdmach:z0#32:z1#96:\
:pa#0:sa#456300:ba#8192:fa#1024:ca#32:da#4096:ra#10:oa=time:\
:ia:ta=4.3BSD:\
:pb#456300:sb#130260:bb#8192:fb#1024:cb#32:db#8192:rb#10:ob=time:\
:ib:tb=4.3BSD:
#
#
-----------------------------------------------------------------
The first step is to determine your drive's name, geometry and available
sectors. Right? So, you call your vendor, order the product specification
manual, call the manufacturer. Right? Wrong. This got me nowhere.
The NeXT comes with a cute little program (/etc/scsimodes) that tells you
all you need to know. Disconnect your 40 MB accelerator drive (if you have
one) and plug in your Wren V jumpered for SCSI target 0. Boot off the
optical drive. Execute scsimodes (no disktab entry is required for scsimodes.)
----------------------------------------------
localhost# scsimodes /dev/rsd0a
SCSI information for /dev/rsd0a
Drive type: CDC 94181-15
512 bytes per sector
52 sectors per track
15 tracks per cylinder
1546 cylinder per volume (including spare cylinders)
1 spare sectors per track
30 alternate tracks per volume
1173929 usable sectors on volume
-------------------------------------------------
Voila! Everything you need to know. The disktab entry must have the
appropriate name (CDC 94181-15). Twiddle with nc, nt, ns to get as close
as possible to "sectors on volume". (Or just use mine.)
With this entry in /etc/disktab you are ready to do a builddisk. The
NextStep builddisk utility ran fine.
Notice that my partition sizes are an integral number of cylinders each,
thus avoiding the "..... xxx sectors unallocated in last cylinder group ..."
message from newfs.
My raw partitions add up to 586MB, which boil down to 573MB once the inodes
are allocated by newfs, which leaves 518MB with a 10% minfree. I don't have
any programs to reformat this pup with 1KB sectors, although I suppose an
expert with Sun's format program could have gotten some more space by
reformatting at 512B/sector and fewer spare sectors. (Imprimis claims
maximum raw formatted size is 639MB with 1KB sectors and no spares.)
Partition sizes + front porch <= usable sectors on volume (I think, ...what is
front porch?)
For comparison, the Maxtor 8760S gives the following:
-----------------------------------------------
localhost# scsimodes /dev/rsd0a
SCSI information for /dev/rsd0a
Drive type: MAXTOR XT-8760S
1024 bytes per sector
28 sectors per track
15 tracks per cylinder
1632 cylinder per volume (including spare cylinders)
4 spare sectors per cylinder
45 alternate tracks per volume
676415 usable sectors on volume
----------------------------------------------
Sequential reads with the disk program shows the Maxtor to be slightly
faster:
MAXTOR
disk> read
starting block? 0
# sectors per transfer? 16
number of transfers? 1000
sector increment? 16
16384000 bytes in 51996 ms = 315137 bytes/s <<<<<<<<<<<<<<<
disk> read
starting block? 0
# sectors per transfer? 16
number of transfers? 1000
sector increment? 16
16384000 bytes in 51190 ms = 320062 bytes/s <<<<<<<<<<<<<<<<
WREN V
disk> read
starting block? 0
# sectors per transfer? 16
number of transfers? 1000
sector increment? 16
16384000 bytes in 63871 ms = 256521 bytes/s <<<<<<<<<<<<<<<<
disk> read
starting block? 0
# sectors per transfer? 16
number of transfers? 1000
sector increment? 16
16384000 bytes in 63471 ms = 258137 bytes/s <<<<<<<<<<<<<<
Random seeks with the disk program show the Wren to be slightly faster.
(Sorry, no way to show you the graph of seek times.)
The Wren is significantly louder during seeking.
I've a hunch that the system is not accessing the Wren V optimally. This
drive has a 32KB internal data buffer, and sequential reads should really
scream. Anyone who can shed light on the cryptic "tuning the file system
rotational latency parameter" phrase at the beginning of /etc/disktab;
please elucidate.
Keep in mind -- the Wren V is 13% smaller than the Maxtor, and 52% cheaper.
The hardest part of the whole job was peeling off the Wren's front panel.
It's held on with double sided sticky foam. Don't try to undo the folds
in the NeXT's SCSI cable. The glue they use is stronger than the flat cable.
The cable splits before the glue lets go.
Paul O'Neill pvo@oce.orst.edu
Coastal Imaging Lab
OSU--Oceanography
Corvallis, OR 97331 503-754-3251logic@wet.UUCP (Henry Kwan) (02/03/90)
In article <5059@franz.Franz.COM> jdi@sparky.UUCP (John Irwin) writes: > >Your numbers are interesting. We have two cubes here with both Maxtor >and Wren drives installed. We get the same numbers you do for the Wren, >but for the Maxtor we get: > 16384000 bytes in 27515 ms = 595565 bytes/s > >which means the Maxtor we have is almost twice as fast as yours. Ours >are formatted as 512 byte sectors; I wonder if that makes the difference. > > -- John Irwin > Franz Inc. That's even more interesting, considering that Wren V full height drives are rated at 12-16 Mbit/sec (depending on which "zone" you are on). It's a real screamer compared to most other SCSI drives. What is the Maxtor 8760S rated at? The only Maxtor that I've personally played with extensively is the LXT-200SA, which is rated at 9-15 Mbit/sec (divided into three zones of 9, 13, and 15 Mbit/sec). Not bad, but not nearly as fast as the Wren V FH. -- Henry Kwan | AppleLink: D0690 FWB, Inc. | CompuServe: 71320,1034 2040 Polk St. Ste 215 | Internet: claris!wet!logic@ames.arc.nasa.gov San Francisco, CA 94109 | UUCP: {claris,hoptoad,lamc,ucsfcca}!wet!logic
nevai@function.mps.ohio-state.edu (Paul Nevai) (02/03/90)
In article <5059@franz.Franz.COM> jdi@sparky.UUCP (John Irwin) writes: > >Your numbers are interesting. We have two cubes here with both Maxtor >and Wren drives installed. We get the same numbers you do for the Wren, >but for the Maxtor we get: > 16384000 bytes in 27515 ms = 595565 bytes/s What is the test? How to do it? Paul Nevai nevai@mps.ohio-state.edu (Internet) Department of Mathematics nevai@ohstpy (BITNET) The Ohio State University 1-(614)-292-5310.office@ans.machine 231 West Eighteenth Avenue 1-(614)-292-4975.department Columbus, OH 43210-1174 1-(614)-292-3317.secretary The United States of America 1-(614)-459-5615.fax
pvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) (02/04/90)
In article <957@wet.UUCP> logic@wet.UUCP (Henry Kwan) writes: > >That's even more interesting, considering that Wren V full height drives are >rated at 12-16 Mbit/sec (depending on which "zone" you are on). It's a real >screamer compared to most other SCSI drives. > Agreed. This is puzzling. I'm guessing that the operating system is not telling the Wren V to use its 32k cache buffer. Anyone know how to do this? HINT: from the WREN V SCSI MODEL 94181 Product Specification: This feature may be selected by issuing a Mode Select Command with the Enable/Disable Cache bit set in the Cache Control page. Thanks. Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU--Oceanography Corvallis, OR 97331 503-754-3251
edwardm@hpcuhc.HP.COM (Edward McClanahan) (02/06/90)
Henry Kwan writes: > > > >Your numbers are interesting. We have two cubes here with both Maxtor > >and Wren drives installed. We get the same numbers you do for the Wren, > >but for the Maxtor we get: > > 16384000 bytes in 27515 ms = 595565 bytes/s > > > That's even more interesting, considering that Wren V full height drives are > rated at 12-16 Mbit/sec (depending on which "zone" you are on). It's a real > screamer compared to most other SCSI drives. I was under the impression that this very respectable speed is well beyond the (current) capabilities of SCSI (-1). Is anyone seeing this performance across SCSI? Ed "in search of high/sustained disk i/o throughput" McClanahan