gnu@hoptoad.uucp (John Gilmore) (11/04/86)
In article <2474@peora.UUCP>, joel@peora.UUCP (Joel Upchurch) writes: > ...WORM optical disk... > ...would not make good > paging devices because of the awful seek times and rather anemic > transfer rates associated with these devices. Has anyone seen > any optical disks with numbers in these categories comparable > to good magnetic disks? Part of the problem is the same thing that makes Mac floppies slow. CD optical disks are specified to have a constant linear velocity of material passing under the heads. This means that the disk must spin faster and slower as the head seeks in and out. While they could make the heads seek as fast as magnetic disks, they just can't spin the disk twice as fast, or brake to half the speed, in a reasonable time. I don't know if WORM disks are done this way. Traditional magnetic disks are spec'd at a constant rotational velocity (e.g. 3600 RPM), which makes the spinning and the seeking independent. This causes the bits on the outside of the disk to be "wider" than the bits on the inside, since more material zips under the head in the same amount of time. Since it must be able to read and write bits anywhere on the disk, it has to be good enough to do it on the inner tracks where the bits are smaller. But when on the outer tracks, all that precision goes to waste. I don't understand why nobody has built magnetic disks that spin at a constant speed, but vary the clocking of data to the disk so that all the bits end up the same width on the media. This means that you might get 30,000 bytes per track on the inside and 90,000 on the outside -- but who cares? On a SCSI interface, the system doesn't know where the tracks and cylinders are anyway. I don't know how to figure it out exactly, but I suspect that this simple change (to a disk and its controller) could double the amount of stuff you could put on the same disk with the same heads and almost the same electronics. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NRO. The above is food for the NSA line eater. Add it to your .signature and you too can help overflow the NSA's ability to scan all traffic going in or out of the USA looking for "significant" words. (This is not a joke, sadly.)
phil@amdcad.UUCP (Phil Ngai) (11/05/86)
In article <1256@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > >I don't understand why nobody has built magnetic disks that spin at >a constant speed, but vary the clocking of data to the disk so that >all the bits end up the same width on the media. This means that you >might get 30,000 bytes per track on the inside and 90,000 on the >outside -- but who cares? This is an interesting idea to consider. One possible challenge is that of extracting the clock from the bits stored from the media. Usually the clock is encoded with the data and there is no separate clock source. The more you constrain the frequency that the clock might be at, the easier and faster it is to acquire the clock. If you let it vary over a factor of three, it might be more difficult, especially with effects like peak shift, wherein flux reversals written on the disk tend to repel one another. Because of this, the flux reversals appear displaced from where they were written. It's not necessarily impossible, just more difficult. Perhaps the clock separation circuit would then become the limit on seek time instead of head settling time. Just some speculations on my part. -- The VT220 keyboard is an <iS<o standard. That means the French can hate it as well as the Americans. <phil <ngai +1 408 749 5720 <u<uC<p: <[ucbvax,decwrl,ihnp4,allegra<]!amdcad!phil AR<pA<; amdcad!phil@decwrl.dec.com
ccplumb@watnot.UUCP (Colin Plumb) (11/05/86)
In article <1256@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > >I don't understand why nobody has built magnetic disks that spin at >a constant speed, but vary the clocking of data to the disk so that >all the bits end up the same width on the media. This means that you >might get 30,000 bytes per track on the inside and 90,000 on the >outside -- but who cares? On a SCSI interface, the system doesn't know >where the tracks and cylinders are anyway. > >I don't know how to figure it out exactly, but I suspect that this >simple change (to a disk and its controller) could double the amount of >stuff you could put on the same disk with the same heads and almost the >same electronics. >-- >John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa >terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NRO. > The above is food for the NSA line eater. Add it to your .signature and > you too can help overflow the NSA's ability to scan all traffic going in or > out of the USA looking for "significant" words. (This is not a joke, sadly.) They didn't carry it as far as possible, but Commodore varied the clock rates on their 5-1/4" drives for the PETs and C-64s. The difference was, I believe, between 17 sectors on the inner tracks and 21 on the outer ones (don't quote me on those figures). You could do the same thing on an optical disk, since data-storage applications don't require constant bit-rates, the way real-time audio output does. Is there an expert out there who could shed more light on the subject? -Colin Plumb (ccplumb@watnot.UUCP) "You do have one slim chance for survival. This illness is so fatal it's been known to kill itself by accident." -Sillier than Silly
nather@ut-sally.UUCP (Ed Nather) (11/05/86)
In article <13645@amdcad.UUCP>, phil@amdcad.UUCP (Phil Ngai) writes: > In article <1256@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > > > >I don't understand why nobody has built magnetic disks that spin at > >a constant speed, but vary the clocking of data to the disk so that > >all the bits end up the same width on the media. > > This is an interesting idea to consider. One possible challenge is > that of extracting the clock from the bits stored from the media. Alternatively, just extract a synchronizing signal, and let the clock frequency by determined by what track is being accessed. A simple servo should be able to set the required clock frequency close enough, but it would have to get in step. -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.AS.UTEXAS.EDU
peters@cubsvax.UUCP (Peter S. Shenkin) (11/05/86)
In article <watnot.12152> ccplumb@watnot.UUCP (Colin Plumb) writes: >They didn't carry it as far as possible, but Commodore varied the clock rates >on their 5-1/4" drives for the PETs and C-64s. The difference was, I believe, >between 17 sectors on the inner tracks and 21 on the outer ones (don't quote me >on those figures). > >You could do the same thing on an optical disk, since data-storage applications >don't require constant bit-rates, the way real-time audio output does. Real-time audio output probably doesn't require constant bit-rates either. I believe that CD players read bits into a buffer asynchronously, and then put the bits out to the D-to-A at a precisely clocked rate. At least that's how I would do it. That would avoid the need for an extremely accurate drive motor. Variable bit density on the disk would only affect the rate at which program material enters the buffer. As other contributors to this discussion have noted, variable bit rates would involve some computational overhead, and it's not clear how much this would slow things down. In addition, it may be that for audio CD's the nominal bit-rate on the rotating medium is closely tuned to the bandwidth of the channel to the buffer, so that doubling the bit-rate might require some redesign. For audio applications there's no incentive for anyone to do this. (If you could double the amount of program material on a CD, do you think people would be willing to pay $30 each instead of $15? Most people think CD's are overpriced anyway.) For information storage there probably would be; if for a relatively small additional cost an optical drive could store 2Gbyte instead of 1Gbyte per platter, I'd buy that machine.. For audio applications the bucks are in selling disks; for data processing, the bucks are in selling machines. Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA
ccplumb@watnot.UUCP (Colin Plumb) (11/06/86)
In article <573@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes: > [Quotes of earlier articles deleted] > >Real-time audio output probably doesn't require constant bit-rates either. >I believe that CD players read bits into a buffer asynchronously, and then >put the bits out to the D-to-A at a precisely clocked rate. At least that's >how I would do it. That would avoid the need for an extremely accurate drive >motor. Variable bit density on the disk would only affect the rate at which >program material enters the buffer. As other contributors to this discussion >have noted, variable bit rates would involve some computational overhead, and >it's not clear how much this would slow things down. In addition, it may be >that for audio CD's the nominal bit-rate on the rotating medium is closely >tuned to the bandwidth of the channel to the buffer, so that doubling the >bit-rate might require some redesign. For audio applications there's no >incentive for anyone to do this. (If you could double the amount of program >material on a CD, do you think people would be willing to pay $30 each instead >of $15? Most people think CD's are overpriced anyway.) For information >storage there probably would be; if for a relatively small additional cost an >optical drive could store 2Gbyte instead of 1Gbyte per platter, I'd buy that >machine.. For audio applications the bucks are in selling disks; for data >processing, the bucks are in selling machines. > >Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 >{philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA ------ You're right that CD's don't have fantastically accurate drive motors, and they do work rather as you suppose, but there is a servomechanism that adjusts the speed of the motor to keep the buffer about half-full. If it was possible to buffer a significant part of a CD, we wouldn't need secondary storage! Thus, CD's do maintain constant bit rates. ------ A bit of background in disk drive design... I'm no expert in the field, but when I used to play with C-64's, I had a good look at how the machine worked at the hardware level: On the disk, a '1' was encoded as a change in the polarity of the magnetic field on the disk. A '0' was encoded as no change. To prevent long blank regions, nybbles were expressed in a 5-bit code which ensured that there would never be more than 2 0's in a row. When reading data, a bit clock would run at the expected data rate on the disk. If a full cycle of the clock passed without a polarity change sensed by the read head, a '0' was shifted into the serial-to-parallel converter. If a polarity change *was* sensed, a '1' was shifted in, and the bit clock was reset to sync up with the pulse, ensuring it would never drift far. When the serial-to-parallel was full, the byte was latched into an I/O port, and a signal was sent to the CPU to read the byte. Before reading the track, the CPU would adjust the frequency divider used to take the system clock down to the bit rate, to allow higher bit rates on the outer tracks. If the CPU in this example was a DMA controller, there would be _no_ processor overhead needed to allow variable bit-rates, besides looking up the appropriate divider ratio for the given track, which is absolutely trivial. Of course, on a CD, where the bit rate changes continuously, you can just use a PLL instead of a fixed-frequency clock. If this takes too long to sync up, you can prepare it with an expected bit-rate from a variable oscillator while the head seeks. (I don't know if this is actually feasable - it seems reasonable.) I know that MFM recording (which is how most disk drives these days work) is different, but it should give you some idea of how these gizmos operate. ------ About higher-capacity optical disks... This may be just unsubstantiated rumour, but I heard that one of the design goals was to fit Beethoven's 74-minute nth symphony on a disc. (n=5 or 9, I forget which.) Thus only 44,000 +/- samples/second were taken, because they couldn't fit more on a side. Trying to filter out the noise this creates above the Nyquist limit (22,000 Hz) while letting through audio information all the way up to 20,000 Hz gives CD-player designers some serious headaches. Filters with cutoffs that steep induce serious phase distortion. If they could have increased the information content without sending prices through the roof, I'm sure the standards team would have done it. ------ -Colin Plumb (ccplumb@watnot.UUCP) "Bugs: This man page is confusing."
farren@hoptoad.uucp (Mike Farren) (11/07/86)
In article <1256@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: [Discussing clocking data faster on the outside tracks of a disk] > >I don't know how to figure it out exactly, but I suspect that this >simple change (to a disk and its controller) could double the amount of >stuff you could put on the same disk with the same heads and almost the >same electronics. The problem is that it ISN'T a simple change. You have to design a circuit which can handle extreme variations in input data at a fairly high frequency. While circuits like this can be designed, they are neither simple nor cheap. Illustrative example: assume an 8" disk, first track at 7", last at 3.5". Obviously, the data on the 7" track will be recorded at twice the clock frequency, since the track is exactly twice as long as the first. If we assume 5MHz data rate on the 3.5" track, this is a 5MHz data rate at the 7" track; any circuit designed to handle both will be considerably more complex than one designed only to handle one (and remember, the circuit must also handle all in-between cases too!). Even more importantly, one of the most critical of circuit elements in a disk controller is the timing circuitry, which must be highly accurate in order to "catch" the bits properly. Designing a circuit of sufficient accuracy which would operate over an (at least) two-to-one range is VERY difficult. -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"
phil@amdcad.UUCP (Phil Ngai) (11/08/86)
In article <1256@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >I don't understand why nobody has built magnetic disks that spin at >a constant speed, but vary the clocking of data to the disk so that >all the bits end up the same width on the media. This means that you >might get 30,000 bytes per track on the inside and 90,000 on the >outside -- but who cares? On a SCSI interface, the system doesn't know >where the tracks and cylinders are anyway. See "Constant-density recording comes alive with new chips", Mark Young, _Electronic Design_, Nov 27, 1986. It shows how to solve the variable clock problem. It also talks about how it is important the disk you are using not have its own clock separator, which leaves out ESDI and SMD, with only ST506 as a acceptable commonly available drive type. Also, the drive must have a read amplifier with enough bandwidth to support the higher bit rate. Of course, if you wanted to invent your own disk this would not be a problem. And the improvement gotten from constant-density recording is on top of any other improvements you make, such as RLL (multiplies). Yes, OS now has to deal with differing number of sectors per cylinder, wonder what would this do to the Berkeley Fast File System? Anyway, it's a good article and you should read it. -- The VT220 keyboard is an <iS<o standard. That means the French can hate it as well as the Americans. <phil <ngai +1 408 749 5720 <u<uC<p: <[ucbvax,decwrl,ihnp4,allegra<]!amdcad!phil AR<pA<; amdcad!phil@decwrl.dec.com