Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hplabsz!renglish
From: renglish@hplabsz.HP.COM (Bob English)
Newsgroups: comp.arch
Subject: Re: Incremental sync()s and using disk idle time
Message-ID: <6707@hplabsz.HP.COM>
Date: 15 Mar 91 18:17:56 GMT
References: <1991Mar12.202238.19586@zoo.toronto.edu> <3254@crdos1.crd.ge.COM> <PCG.91Mar13180706@aberdb.test.aber.ac.uk>
Organization: HPLabs, Palo Alto CA
Lines: 72

In article <1991Mar12.202238.19586@zoo.toronto.edu>
henry@zoo.toronto.edu (Henry Spencer) writes:

> That aside, the most probable result is that your big expensive
> main host CPU, which could undoubtedly run that code a lot
> faster, will spend all its time waiting for the dumb little I/O
> controller to run the filesystem.  This is not a cost-effective
> use of hardware resources.

This is only true if the dumb little I/O controller is not fast enough
to keep up with the device it's controlling.  As long as it can, and as
long as the device is designed so that its "intelligence" doesn't
appreciably increase its latency, it doesn't really matter whether it's
as fast as the host CPU.  If it can offload functions, the system wins.

With uPs continuing to surge ahead of disks in the performance race,
disk controllers are getting ever faster compared to the disks they
control, and there is certainly potential there to exploit.  In spite of
arguments that CPU power is more effectively concentrated in a central
location, the CPU power to build intelligent controllers will soon be,
effectively, free.  When the performance of cheap, imbedded
microcontrollers reaches 20 MIPS or so, arguments about effective
concentration of CPU power will no longer be relevant.

As Piercarlo points out, however, device controllers often make poor
decisions and end up penalizing the system rather than helping them, in
part because the standard interfaces used to talk to disk drives do not
provide the information necessary to make good decisions and in part
because most "intelligent" devices are programmed by disk drive
designers focused on raw access times rather than total system
performance.

I don't want to sound like I'm hammering on the disk drive guys,
however.  The centralized CPU (cluster) and its operating system are in
no better shape.  Standardized file systems are based on idealized models
of disks that no longer reflect actual structures and performance
characteristics of real disks.  The 4.2BSD file system, for example,
assumes that all tracks and cylinders are the same size and that all
tracks start at the same rotational position, assumptions that are false
in many cases.  There may be file systems available that take advantage
of information such as precise, current head position and settle time in
order to optimize requests, but if so, they are rare.

The fundamental problem here is that the controller and the CPU do not
communicate well enough to cooperate well together.  The protocols by
which the CPU could keep the controller informed on its global state
cheaply and efficiently do not currently exist, certainly not in a
standard way, and neither do the protocols by which the controller could
keep the CPU informed of its current state.  If anything, current
standards seem to be progressing in the opposite direction.

Where does this put intelligent disk controllers?  I must confess that I
don't know.  There seem to me opportunities for improved performance
there, but the continuing decline in DRAM prices and the consistent
performance gap between DRAM and disk systems makes we wonder whether
those potentials will ever be economically important.  Sometime in the
next 10-20 years, DRAM and disk storage prices are projected to cross.
After that disks will be important only for persistance and power
consumption reasons, and will have to compete with other technologies on
those bases.  Perhaps a new, cheaper technology will come along with
better access times than disks.

It may be more interesting to think of intelligent storage servers.  As
uP-based systems become more powerful, their data and storage appetites
will increase as well.  In the not-to-distant future, it may be common
for storage servers to have to manage terabytes of data and transfer it
at gigabit or gigabyte rates to and from a large number of clients.  I
doubt that any current filesystems or file access protocols are really
ready for such an environment.

--bob--
renglish@hplabs.hp.com