[lkml]   [2000]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Scheduled Transfer Protocol on Linux
Karen Shaeffer wrote:

> 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...

OK. Now we seem to have seen some oversimplification and some overcomplication. I
think reality lies somewhere between.

Most of the complexity referred to by Karen lies in the back end of the drive. The
front end is more flexible. It already appears in at least two forms - IDE, SCSI,
and sometimes some flavour of the month serial interface. I'm not saying IDE and
SCSI drives have common back ends, but they do use common technology ([OT]
Actually, I find the level of back end commonality puzzling. It used to be that
the mechanics of IDE and SCSI drives looked identical and ran that the same speed,
but everyone said they were totally different, with vastly different reliability.
Now almost all IDEs all run at 7200RPM, and almost all SCSIs at 10,000RPM and
people keep telling me the mechanics are now the same. Go figure.) Anyway,
whatever happens in the murky microworld of the platters and their immediate
control electronics has little to do with the interface they present to the world.

The critical word in designing the external interface is "cheap". The whole darned
drive retails for US$100 to 200. The BOM must be much lower than that. A Celeron
is a non-starter on cost grounds (its fan is comparable to the size of a whole
disk drive, but a Crusoe wouldn't solve the cost issue). A serial interface,
whether using Ethernet technology or some other, could add many dollars to the
BOM, since it needs to run at near GigE speeds. The required additional RAM and
ROM to support it would also hurt the cost structure.

The bottom line is that despite the exotic technology going into a disk drive's
back end, its the front end which now most affects it price. I think we are more
likely so see forms of hot plug IDE trying to displace hot plug SCSI, than any
form of serially connected disk drive go mainstream - at least in the near future.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.051 / U:2.828 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site