[2112] in Commercialization & Privatization of the Internet
Gigabits, Mainframes and Workstations
daemon@ATHENA.MIT.EDU (Craig Partridge)
Mon Jan 27 13:09:02 1992
To: com-priv@psi.com
Reply-To: Craig Partridge <craig@aland.bbn.com>
From: Craig Partridge <craig@aland.bbn.com>
Date: Mon, 27 Jan 92 10:03:44 -0800
I've been watching the discussion about the role of computer centers and
their mainframes slowly meander into a discussion of the future of computer
technologies and needs for gigabit networks. I want to comment a bit
on the mainframe, workstation and gigabit networks issues.
I'll start by taking a shot at predicting technologies just a little bit
in the future. This year folks expect to see 100 MIPS (or SPECmark
equivalent) workstation processors. In a few years, several manufacturers
expect to have 1 BIPS (that's Billion Instruction Per Second) workstation
processors.
Now if you take Amdahl's old rule of thumb (which has done pretty well
over the years) those 1 BIPS computers are going to need about one
billion bytes of main memory and about 1 gigabit of IO bandwidth to get
reasonable performance. Now not all of that bandwidth will come from
the network -- IO subsystems like RAID disks will also play a role, but
in such a world it should be clear that a gigabit network is probably
the natural speed for the network to which these computers are connected:
that's the right bandwidth to feed them at. (Consider that based on
instruction counts, it was estimated a few years ago that a 100 MIPS
computer would have sufficient power to send at a gigabit and do a tiny
bit of application processing too if the packet sizes were about 2 or 3
Kbytes long).
Another fun point is that if you assume processor speeds of about 1 BIPS
and then look at distributed computing among workstations with those
speeds you discover that network latency becomes a *big* problem.
One way to illustrate this problem is to consider the cost of a null
RPC call, measured in local instruction cycles spent waiting at the
1 BIPS machine that made the call.
On a LAN of around 10km, the delay equals 112,000 instruction cycles
On a MAN it is over 5 million cycles
On a CONUS WAN it is over 500 million cycles
To provide some perspective, the best analysis of UNIX process lifetimes
suggested that the average UNIX process executed fewer than 1 million
instructions in its lifetime. So a single call to the domain name
system to figure out the IP address of your server might well take 500
times longer than executing all the instructions that come after it.
The numbers are this high because the speed of light delay is fixed,
so increases in processor speed become effective increases in relative
delay (the computer gets faster but the network doesn't).
A key point is that making distributed computations perform well is
becoming difficult as CPUs get faster because the delays between
machines are becoming relatively long.
How to deal with this problem is still a topic of (very interesting) research;
the ideas currently being considered are rather interesting, and all but
one that I'm aware of involve using *more* network bandwidth to try to
reduce the effects of latency. Here's a quick sampling:
* one idea is to improve caching techniques so as to reduce the
number of times an application must do an RPC (or equivalent network
operation). For example, there's a old trick of read-ahead on a
file system -- if an application reads a block from a file, the
operating system reads the next block from disk too, since the
likelihood is high the application will want to read the next
block soon. Similarly, one can do read-ahead but on a larger
scale, via the network. But note the numbers get quite large --
when an application reads a block from a file server, the rational
amount of data to deliver may be an entire file system (!).
Over a gigabit link, this is feasible, although there are some
real cache consistency problems that have to be solved.
* another idea is to use various schemes to push export applications
or pieces of applications to the resources they use. In short,
instead of moving data to applications, as caching does, move
applications to the data they work on. There are different ways
of doing this: one method is process migration or variations on
process migration where parts of the program migrate. These
schemes require lots of bandwidth to move processes/program fragments
fast. Another method is to structure the system to encourage
people to run applications at the servers (such as Plan-9 from
Bell Labs). One might intuitively think that this plan is doomed
to failure because it saturates servers -- in fact there's some
evidence that it burdens servers *less* than current RPC techniques.
Observe that under both approaches, file servers need to be reasonable
powerful machines capable of rapidly moving lots of data off file systems
and onto the network. Some researchers looking at this problem are
concluding that the machines that do this sort of data handling well
look remarkably like mainframes...
Craig
