🚀 go-pugleaf

Elite 47: A Powerful Capacity Point
With the introduction of the Elite 47, Seagate's sixth generation of Elite
drives continue their far-reaching standard of providing ultimate capacity,
superior performance and proven reliability. Indeed, the 47 Gbyte Elite 47
represents the industry's highest-capacity disc drive, providing more than
two times the capacity of the next-largest generation disc drive available
today. The 5.25-inch Elite 47 makes it ideal for storage-hungry mainframe
applications, enterprise and department servers and digital A/V
applications.

Performance
Seagate has designed the Elite 47 to top the performance charts. Its low
latency (5.56 msec) and rapid seek time (13 msec) translate to it phenomenal
ability to process I/O requests. The 5,400-RPM Elite 47 provides a sustained
formatted data-transfer rate ranging from 15.6 to 23 Mbytes per second,
which is equal to that of the 7,200-RPM Barracuda� 9. The Elite 47 Ultra
SCSI provides staggering burst data-transfer rates of 20 Mbytes per second
for an 8-bit -wide parallel interface and 40 Mbytes per second for
16-bit-wide parallel interface.

Two key factors enter into the Elite 47's performance: a 4096-Kbyte
multisegmented adaptive cache for accelerated performance and embedded-servo
technology. Embedded-servo technology ensures fast, accurate seek
performance for uninterrupted data streaming under all temperature
conditions.

The innovative Elite 47 has leveraged all of the proven technologies,
components and designs built into the highly reliable Elite 23, which has
demonstrated over 1,000,000 hours MTBF. These technologies include
magnetoresistive (MR) heads, partial-response, maximum likelihood (PRML)
channel and Seagate's Advanced SCSI Architecture II (ASAII) interface.

To further increase throughput enhancements, the Elite 47 uses a
full-function read-ahead cache that can be divided into as many as 16
segments. The data in these blocks is available to the host with no
additional access to the disc and the various data blocks can be cached
simultaneously so that subsequent commands will have a higher probability of
a cache hit.

The Elite 47 features command queuing, which allows the host to send
multiple-tagged commands to the drive. Command queuing enables the drive to
reorder commands and complete operations in the shortest time possible.

Chris Kennington - newshound wrote in message
<881949844snz@inf-eden.demon.co.ux>...
|In article <pLMYl5dhX7hK-pn2-bmRtSYdnH0CM@ALEX>
|           krw@ibm.net "Keith R. Williams" writes:
|
|">     I've been reading the part of this thread to do with access
|">  rather than EIDE/SCSI in a somewhat bemused fashion.  Let's skip
|">  the parts that are to do with stand-alone systems (most of the
|">  posters are discussing servers),
|"
|"I believe this is your mistake.  I thought we were talking client
|"or stand'alone systems when we were discussing the lack of merit
|"of SCSI.  I don't believe anyone questioned SCSI's usefulness in
|"a server.
|
|    Umph.  I've read (or at least skimmed) about 100 posts.  Most
| of the pro-EIDE ones failed to restrict themselves to clients
| And big servers, including eg RAIDs and other multi-drive
| topologies, have featured quite a lot.
|
|">  and think about the dominant
|">  factors in a network data transfer.  All this work was done in
|">  CompSci departments in the 1970s (if not 1960s).
|"
|"Things have changed, with cost being the primary change.
|
|    "Things", ie the logical activities involved in pulling data
| off a disk, buffering it, sending it down a MAC (ethernet-type) cable,
| buffering it at the other end and transferring to another disk
| have not changed in the least (though the commercial offerings
| have).  The 1970s computer science is perfectly valid, provided
| that the new (?) techniques of sequencing and buffering are
| factored in.  Cost is not an element of such equations.
|
|">     It is really not safe to say that any one factor is dominant
|">  in determining average transfer-rates, except in tightly defined
|">  circumstances.  I have not noticed a single post discussing the
|">  effect of two simultaneous transfers (of different data), or of
|">  network bandwidth limitations, etc.
|"
|"You haven't followed this discussion long then.  My argument is
|"that on a client workstation SCSI is useless, with one (as I
|"noted) or two exceptions.
|
|    See comment above.  You may well be right.  The point I am
| making is that it is by no means obvious that the raw disk/RAM
| data-rate on the disks is the dominant factor in a networking
| situation, or for that matter in any multi-threading or multi
| access situation.  Even if the network, ie the MAC-cable
| problems, are factored out, there will undoubtedly be a stage of
| multi-activity on a single-user multiple-simultaneous-process
| computer where the required disk access becomes so chaotic and
| the buffering requirements so large that seek times will be the
| dominant factor.  Whether any current activities even approach
| this point, I do not know.  (I'm tempted to think that Grim95
| would actually become the limiting factor long before <g>).
|
|">  (Frinstance, in the early days of classroom networks, where a
|">  single pupil could download the software in 20 seconds, it could
|">  take 30 minutes for a class of 10 to do so if all started
|">  simultaneously.)
|"
|"This must be the limiting case of a poorly designed network.
|
|    Design was well optimized.  Hardware supported only a slow rate
| on the MAC-cable, and the disks involved (pre-MFM) were dead
| slow.  Z80s were not good at using extra store for buffering.  So
| if more than one or perhaps two pupils tried to download the
| software at once, there was a shocking combination of disk-thrash
| and packet-collisions.  (And this was, I think, before CSMA had
| replaced the early MAC logic.)  But it is still a good example of
| the necessity of locating the limiting factor of performance
| correctly.
|
|    Perhaps it is a pity not to start new threads when several
| rather different subjects come up.  And the number of posts and
| subjects (also, for that matter, opinions) has been large.
|
|                                    Chris K.
|--
|Chris Kennington (newshound)                        01491 574065
|  You can mail me with suitable modifications to header-addresses,
|   or to "chris <at> inf-eden.demon.co.uk", replacing the <at>.
|