Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!uokmax!d.cs.okstate.edu!norman From: norman@d.cs.okstate.edu (Norman Graham) Newsgroups: comp.arch Subject: Re: CD-ROM documents (was Paperless Office) Message-ID: <1990Dec6.154348.5206@d.cs.okstate.edu> Date: 6 Dec 90 15:43:48 GMT References: <1990Dec5.105743.25693@actrix.gen.nz> Organization: Oklahoma State University Lines: 74 From article <1990Dec5.105743.25693@actrix.gen.nz>, by Bruce.Hoult@bbs.actrix.gen.nz: > In article <1990Dec4.224107.6589@d.cs.okstate.edu> norman@d.cs.okstate.edu (Norman Graham) writes: > >> this scheme, the disk must spin with a constant tangential velocity at >> the point of the read head. >> >> What all this means is that when seeking the drive must move the read >> head to the proper location _and_ change the rotation speed. > > Not necessarily so. There's no reason that a drive with a fast seek movement > but slow rotational speed adjustment (or constant speed) couldn't just read > at odd speeds and buffer the data. I've seen a couple of postings like this, so I'll try to clarify things a bit. CD-ROM drives vary the rotation speed (AV) so they can _read_ the disk. This has nothing to do with the drive trying to maintain a constant data rate. Let me explain: CD-ROMs don't actually store bits--they store transitions between bit runs. So the bit stream 00110000101110 has six transitions. Transitions are recorded so that the _distance_ between transitions indicates how many bits are in the bit run. Well, how do you measure the distance between transitions? With constant tangential velocity (or constant linear velocity (CLV)), the distance between transition A and transition B is a simple function of the time between transition A and transition B and the tangential velocity (which is a constant--remember?). Does the equation distance = rate * time sound familiar? But suppose we reverse the situation and use a constant rotation speed (i.e. constant angular velocity (CAV)). Then the distance between transition A and transition B becomes a more complex problem. Remember that because of CAV, the tangential velocity is increasing from transition A to transition B (points on the inside of the disk are spinning slower than points on the outside of the disk); thus we now have acceleration to worry about. [I've not reasoned through this (heck, it's just a USENET posting) but I believe the acceleration is non-linear.] So, what _do_ we have to work with to determine the distance between two transitions? Well, we still know the time between the transitions. And I suppose someone could come up with a way to measure the tangential velocity at transition A and transition B. If we assume a linear acceleration then things fall out at this point. If we assume the worst case [which is probable]--nonlinear acceleration that can't be predicted between disks or maybe not even on the same disk if the spiral doesn't conform to some mathematical function--then we'll have a much harder time trying to calculate the distance between transitions. All-in-all, I believe the best bet for decreasing seek times for CD-ROM drives is to keep the constant tangential velocity and to concentrate on speeding up the change of angular velocity. It's doubtful that CD-ROM drives will match the seek times of magnetic disks any time soon. But a 20ms seek time is _not_ necessary for good performance from CD-ROMs. I believe we can get reasonable performance from 100ms seeks--IF some intelligence is used when laying out the CD-ROM. Remember, CD-ROM is a _read-only_ medium. This means you should put a lot of time up front to choose a data layout that minimizes seeks. This means putting information that is used together close together; or perhaps putting the same information in several places on the disk; or perhaps interleaving certain files; etc. NOTE: Again, I believe we can overcome the problems hindering the reduction of seek times on CD-ROM. I'm just pointing out that the problem is not as easy as some think. -- Norman Graham {cbosgd,rutgers}!okstate!norman The opinions expressed herein do not necessarily reflect the views of the state of Oklahoma, Oklahoma State University, OSU's Department of Computer Science, or of the writer himself.