Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!sri-spam!sri-unix!hplabs!amdcad!phil From: phil@amdcad.UUCP (Phil Ngai) Newsgroups: net.arch,net.periphs Subject: Re: Why optical disks are slow to seek; an idea for higher capacity disks Message-ID: <13645@amdcad.UUCP> Date: Tue, 4-Nov-86 21:01:08 EST Article-I.D.: amdcad.13645 Posted: Tue Nov 4 21:01:08 1986 Date-Received: Wed, 5-Nov-86 05:43:14 EST References: <1128@tekig5.UUCP> <5100141@ccvaxa> <553@cubsvax.UUCP> <2474@peora.UUCP> <1256@hoptoad.uucp> Reply-To: phil@amdcad.UUCP (Phil Ngai) Organization: Advanced Micro Devices, Sunnyvale, California Lines: 28 Xref: watmath net.arch:4187 net.periphs:1276 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