bwong@sundc.UUCP (Brian Wong) (04/16/88)
Perhaps this isn't the most appropriate place for this, but... I have seen many disk drives in my time, but every hard/fixed disk/dasd (whatever) has rotated at 3600 rpm. Given that it seems that many other approaches have been tried in an attempt to speed up disk drives, and that particularly in fixed-head disks, the rotational latency is a significant contributor to the amount of time it takes to make a disk access, why don't we see disks running faster than 3600 rpm? It seems that with disks continually getting smaller (radially, of course, not capacity-wise), it seems like it would be easier to get (and keep) them moving faster. I know that drums went at other speeds. Why not disks? If you feel this goes in some other discussion, follow up to there and mail me where to look.
mangler@cit-vax.Caltech.Edu (Don Speck) (04/18/88)
In article <2746@sundc.UUCP>, bwong@sundc.UUCP (Brian Wong) asks: > why don't we see disks running faster than 3600 rpm? Because that would increase the bit rate, and the controller's can't handle it. (It continually amazes me that the electronics can't keep up with something that is electro-mechanical...) The Fujitsu Eagle M2351 spins at 3961 rpm and transfers at 15 MHz, which made it too fast for any of the controllers available when it was introduced in the early 1980's. Many later high-density disks have instead opted to hold down the rotation rate so they could use existing controllers. The best example is the CDC 9771, which spins at 2160 rpm (also available in a 3600-rpm version, the CDC 9772). Rumor has it that Fujitsu's recent 8-inch disks have a jumper to make them spin faster, but since even the normal transfer rate is at the maximum of many controllers (20 MHz), this is of limited utility. It's probably intended for places where the air is thin, to increase the flying height. What the disk industry needs most are a few good 40 MHz controllers. SCSI and IPI show some promise in this area. Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck
eugene@pioneer.arpa (Eugene N. Miya) (04/18/88)
I read Don's follow up to this as well. I don't think you should get
the impression that it's all the controller's fault. There are
controllers which stripe after all.
You have to look at the history of disk drives. The first ones were
much slower than 3600 RPM. It is after all wall current and gears
("pulleys") which determine these speeds. The three disk companies I'm
familiar with (otherwise 2 if Infomag hasn't gone out of business) all
did studies of magnetic foot prints, etc. All proprietary. 3600 RPM
is only a temporary plateau (a stepping stone) to higher speeds like
32-bit words on processors.
I only worked on the things which crashed into them. ;-)
On a separate note: I saw my first piece of ICL hardware yesterday,
a cash register (I count the DAP as AMT hardware now).
From the Rock of Ages Home for Retired Hackers:
--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA
"You trust the `reply' command with all those different mailers out there?"
"Send mail, avoid follow-ups. If enough, I'll summarize."
{uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugenehenry@utzoo.uucp (Henry Spencer) (04/18/88)
> I have seen many disk drives in my time, but every hard/fixed disk/dasd > (whatever) has rotated at 3600 rpm... Fujitsu Eagles rotate at 3900-odd RPM. I'd expect that a lot of newer drives likewise use higher speeds. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
gillies@uiucdcsp.cs.uiuc.edu (04/19/88)
I want to suggest a possible reason that may be untrue. A 3600 RPM
disk rotates 60 times per second. Thus, the maximum access time to
any SECTOR on such a disk is 16.7ms. The average SECTOR access time
(assuming you start from a random sector) is 8.3ms.
Some of the more sophisticated stepper motors (voice-coil?) in
Winchester disks can do an average TRACK seek in 16.5 ms (CDC Wren).
But why make the disk spin faster, if the head cannot get to the TRACK
quickly? The average TRACK seek time would have to be 8.3ms before it
would be the main bottleneck in disk random-access performance.
Also, maybe the economics don't make sense. After all, nearly all the
money in Winchester disks is in the high-volume low-performance
devices.
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@p.cs.uiuc.edu}chris@mimsy.UUCP (Chris Torek) (04/19/88)
In article <76700012@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: >... A 3600 RPM disk rotates 60 times per second. Thus, the maximum >access time to any SECTOR on such a disk is 16.7ms. The average >SECTOR access time (assuming you start from a random sector) is 8.3ms. [keep that assumption in mind!] >Some of the more sophisticated stepper motors (voice-coil?) in >Winchester disks can do an average TRACK seek in 16.5 ms (CDC Wren). >But why make the disk spin faster, if the head cannot get to the TRACK >quickly? The average TRACK seek time would have to be 8.3ms before it >would be the main bottleneck in disk random-access performance. The `average access time' is not necessarily the average access time. Each of these averages assumes you are starting from a random place. The whole point of the 4.2BSD `fast file system' (and any other optimised allocation scheme) is to eliminate that assumption. The 4.2BSD block allocator tends (somewhat) to allocate out of a single cylinder, allocating rotationlly-optimal sectors. (`Rotationally- optimal' to an approximation, at least.) It also tends (more than somewhat) to allocate out of a single cylinder group (reducing average track seek time). Large contiguous block allocators (`extent systems') have the same sort of effect (possibly moreso). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bwong@sundc.UUCP (Brian Wong) (04/19/88)
A while back I asked about disk speeds -- I've gotten a bunch of responses, mostly in email. Summarized, here they are: 1) some disks do run faster than 3600 rpm (notably the Fujitsu Eagle and its successors). 2) the rate at which data can be recorded/read seems to be a limitation. this surprises me, but then i don't know much about this technology. 3) the rate at which the data can be transmitted through the controller also seems to be a limitation; again, this surprises me. OK, here's the $64k question: why is it that a mechanical speed is being bottled up by an electrical speed? Is this some sort of architectural feature of current disk controllers and/or heads?
jk3k+@andrew.cmu.edu (Joe Keane) (04/20/88)
> But why make the disk spin faster, if the head cannot get to the TRACK > quickly?Because every OS i've heard of tries to make keep logically adjacent blocks in the same track. So only a small fraction of block reads are accompanied by track seeks. --Joe
bartlett@encore.UUCP (John Bartlett) (04/21/88)
In article <76700012@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: > >Some of the more sophisticated stepper motors (voice-coil?) in >Winchester disks can do an average TRACK seek in 16.5 ms (CDC Wren). >But why make the disk spin faster, if the head cannot get to the TRACK >quickly? The average TRACK seek time would have to be 8.3ms before it >would be the main bottleneck in disk random-access performance. The issue here is (of course) an applications dependent one. If you have a file system making random accesses to a disk in relatively small hunks (<8Kish) then the data transfer time does in fact become a relatively small amount of the total I/O time. If, however, you are transferring much larger blocks, as is the case in scientific applications (big ones) and may be the case in swap space, depending on how your flavor of O.S. works, the data transfer time can be significant. The I/O's in our system look something like this: 8 ms average seek time (under load - good seek ordering queues) 8.33 ms average rotational latency 5 ms data transfer time (15 MHz) 1 ms controller overhead 22.33 ms per i/o or 45 i/o per second max. The SCSI overhead tends to reduce this as well. We use as a rule of thumb about 40 I/Os per second per spindle max, and then derate from there based on how many spindles are on a SCSI cable. The above numbers show that radically improving data transfer rates for this application does not buy much. We should spend our time on cacheing algorithms, seek algorithms and the like, and figure out how to do larger blocks of I/O, better seek queuing, and the like. However, if data transfers were much bigger, data transfer would indeed have a very direct effect. John Bartlett {ihnp4,necntc,talcott,decvax,allegra,linus}!encore!bartlett Encore Computer Corp. 257 Ceder Hill Street Marlboro, Mass. 01752 (617) 460-0500 Opinions are not necessarily those of Encore Computer Corp.
farren@gethen.UUCP (Michael J. Farren) (04/22/88)
In article <2759@sundc.UUCP> bwong@sundc.UUCP (Brian Wong) writes: > >OK, here's the $64k question: why is it that a mechanical speed is being >bottled up by an electrical speed? It's not, really. The data rate coming off of the disk is a function of two things: the rate of speed of rotation of the disk, and the density of the bit packing on the media. You could have the same data rates on a disk turning at 1 RPM, if you could pack the bits in there tighter. There's a couple of things operating here. First, most disk controllers are limited in bandwidth. This has to do, as much as anything, with the corresponding limitations in the I/O channel they are working with. Second, recording technology is also limited in bandwidth - this has to do with the fact that it takes time to cause a flux change in a magnetic medium. While this can be improved, there are limits there. I don't see that the 3600 RPM speed is cast in stone, but it does seem to fit quite well with the current state of the art in magnetic recording and data processing (less well with the latter). Personally, I'd always assumed that the disks rotated at 3600 RPM because it was easier to design to that speed - 3600 RPM equates to 60 RP/second, which happens to be the line frequency most common in countries which manufacture disk drives (read: USA). Don't know if this is just computer folk etymology or not, though. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (04/27/88)
In article <887@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >In article <2759@sundc.UUCP> bwong@sundc.UUCP (Brian Wong) writes: >magnetic medium. While this can be improved, there are limits there. >I don't see that the 3600 RPM speed is cast in stone, but it does It isn't, it's cast into the interface specifications e.g. the st-506 interface used by all smaller systems (pc's). With SCSI interfaces being built onto disks drive manufacturers only present an ordered set of blocks from 0..n. This allows them to do weird and wonderful things to achieve n which just wouldn't be possible if they had to stick to the st-506 interface. At least one manufacturer (Rodime) spins the platter a little slower to pack more data onto the surface to achieve a higher storage capacity at the expense of a slightly slower average access time (increased rotational delay). -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532
rbl@nitrex.UUCP ( Dr. Robin Lake ) (05/06/88)
In article <887@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >In article <2759@sundc.UUCP> bwong@sundc.UUCP (Brian Wong) writes: >> >>OK, here's the $64k question: why is it that a mechanical speed is being >>bottled up by an electrical speed? > >It's not, really. The data rate coming off of the disk is a function >of two things: the rate of speed of rotation of the disk, and the >density of the bit packing on the media. You could have the same data >rates on a disk turning at 1 RPM, if you could pack the bits in there >tighter. > >There's a couple of things operating here. First, most disk controllers >are limited in bandwidth. This has to do, as much as anything, with >the corresponding limitations in the I/O channel they are working with. >Second, recording technology is also limited in bandwidth - this has >to do with the fact that it takes time to cause a flux change in a >magnetic medium. While this can be improved, there are limits there. As the co-designer of a solid-state disk product (Monolithic Systems EMU), I've got some real data (courtesy of Sugit Kumar's Ph.D. dissertation). 1. The controllers can keep up with any computer bus. 2. Because almost all operating systems are designed for rotating disks (vs. solid-state disks), the device drivers are the system I/O bottleneck for very high speed devices. Even tho the "EMU" had 1/17000 the rotational latency of the DEC RF/RS-11 it replaced, the 1,000 microseconds or so that each call to the device driver took reduced the effective I/O performance to about 17 times the rotating equivalent. Note that both RF/RS-11 and EMU are Word-Addressable, so blocking wasn't an issue. 3. There appear to be systems under development that move the I/O overhead into the memory management unit and device controllers, letting the CPU use very simple 1 - 5 instruction I/O commands. This can result in a uniform "Name Space" for the entire system, from main memory through disk, tape and networks. With RISC and cache taking essentially all delays out of the CPU, and (for the sake of an acryonym "Uniform Name Space") taking essentially all delays out of the I/O, performance should be OUTSTANDING! DISCLAIMER: This information has nothing to do with my employer. In fact, this work is a decade old and I haven't been here that long! ----- -- Rob Lake BP America Research and Development decvax!mandrill!nitrex!rbl mandrill.CWRU.EDU!nitrex!rbl
david@daisy.UUCP (David Schachter) (05/10/88)
In article <740@nitrex.UUCP> rbl@nitrex.UUCP ( Dr. Robin Lake ) writes: >There appear to be systems under development that move the I/O >overhead into the memory management unit and device controllers, letting >the CPU use very simple 1 - 5 instruction I/O commands. This can result >in a uniform "Name Space" for the entire system, from main memory through >disk, tape and networks. With RISC and cache taking essentially all delays >out of the CPU, and (for the sake of an acryonym "Uniform Name Space") >taking essentially all delays out of the I/O, performance should be >OUTSTANDING! Your last point sounds interesting-- please tell us more.