Re: Scheduled Transfer Protocol on Linux

[Karen Shaeffer]

On Fri, Feb 11, 2000 at 11:24:12AM -0800, Larry McVoy wrote:
> : > Folks, I was at SGI when they did this stuff and I've used it personally
> : > quite a bit.  It's very cool.  I think this is definitely worth a look
> : > and I'll be playing around with it.
> : > 
> : > One thing that I've dreamed about for a while is getting the disk drive
> : > vendors to put STP down in the drives.  Then we throw out the SCSI/IDE
> : > cables and use RJ45 connectors to talk to both the network and the disks.
> : > Think hot plug.  Cool, no?
> : 
> : SCSI over STP is already specified. Infact, SGI and Genroco did
> : a prototype demo at CERN last October with SCSI over STP running out of
> : Origin2000 with GSN connecting through a Genroco bridge to a fibre
> : channel raid array running pure SCSI. That same bridge has blades
> : for GbE also.
> 
> This is cool but what I want is both more cool and more mundane.
> It's the mundane aspect that makes it cool.  Here's the picture:
> 
> Imagine that cheapo IDIE drives could be bought soon with 100BaseT and
> not so soon with GigEth over copper connecters.  They cost about $100
> more than your current IDE drives (which are essentially free :-)
> 
> Imagine Linux with STP in the kernel on _both_ ends of the connection.
> On the disk drive, the embedded 680x0 is gone, replaced with an embedded
> Celeron (or whatever is cheap, maybe Transmeta wants to play in this
> space; hmm, that's a cool idea, maybe I should call Ditzel).  
> 
> Linux on the disk drive is not as far fetched as you might think - the
> drives already have two processors out there, the analogue thing that 
> runs the arm and the more normal thing that manages the cache, does
> any protocol, whatever.  Lift the existing normal one, drop in a Celeron,
> add a little memory and let Linux manage the cache.

I worked on disk drive microelectronics for a few years. Your understanding
of what is in those chips is grossly oversimplified. A general purpose
processor simply could not be utilized in this environment. Behind the disk
controller is a highly advanced dsp that is functionally merged with
pipelined ecc. The latest designs pipeline the ecc right throught the dsp
and into the disk controller. This is then merged with a digital control loop
for the motor driving the arm. Today's advanced drives utilize wavelet
technology (or is that not out yet? They did use trellis codes for a while)
to adaptively decode the nonlinear, nonstationary analog signals. The price
competitive nature of that industry simply precludes anything but highly
optimized solutions...

Beyond that, they have highly integrated 4 year development schedules. This
is necessary because the entire system is functionally tuned to the media
characteristics. And now your talking advanced material and manufacturing
research, involving atomic scale quantum effects... You just can't walk in
to those groups and announce a great idea[1]... Ideas flow down from the
Advanced R&D labs. So whatever innovation you see coming out of the disk
industry has been in the pipeline for years...

Of course, if you want to talk with some R&D managers, I could get you
connected with the right people at Seagate, Maxtor, and Quantum...

[1] Which is why I left the hardware business and am now going to spend the
rest of my days hacking source code--where innovation is only as far away as
your keyboard...

Karen
-- 
----
  Karen Shaeffer
  Neuralscape; [phone]
  Santa Cruz, Ca. 95060
  [e-mail]  http://www.neuralscape.com
-------------------------------------------------------