The fastest networks will challenge desktop systems architects
Peter Wayner
One of the biggest design challenges over the next ten years will be integrating desktop machines with the increasing power of networks. These new networks promise to deliver hundreds of megabits of data per second, and the traditional personal computer is built around an architecture that rarely has to handle more than a 14.4-Kbps modem. Ramping up the desktop machine will require more than just adding a faster interface card--designers will probably have to reengineer nearly every part of the desktop system to handle the flood of data.
Engineers and technicians involved with high-speed testbed networks are already facing some of these problems. Take, for exampl
e, the Aurora Project, one of several U.S. Government-funded Gbps testbeds for researching high-speed networking technology.
While the other Gb testbeds linked supercomputers and mainframes, Aurora concentrated on hooking up workstation-level machines to 600-Mbps ATM (asynchronous transfer mode) networks. The test network linked workstations at MIT (Cambridge, MA), IBM's TJ Watson Research Center (Yorktown Heights, NY), Bellcore (Morristown, NJ), and the University of Pennsylvania (Philadelphia, PA).
The folks involved in the Aurora Project are among the first that are encountering the problems that will eventually hit every desktop machine architect: Many different bottlenecks limit the performance of every part of the machine, from the hardware cards to the video apparatus to the software protocols that linked everything together. In fact, some members of the Aurora Project concluded that a RISC instruction set may be the only part of the computer that won't need to be redesigned.
Related Bottlenecks
Everything from the desktop system's network I/O components to its operating system should be reexamined to attach the machine to a high-speed network (see the table, ``
Not Ready for Prime Time
''). The Aurora Project uncovered some subsystem's limitations. For example, the I/O cards in their RS/6000 workstations could handle only 135 Mbps. Faster cards might be able to assemble the incoming data without balking, but they could not find a way to get the data to memory because the bus bogged down. Other data cards, such as those that link the hard disk, began to interfere with the bus traffic.
These problems are certain to cause grief for computer architects. Many users are quite familiar with the limitations that the old computer bus brought to video performance. Local buses that link the processor with the video cards are now almost standard on many desktop machines. Adding a single, faster bus between the CPU and the video card is just a tem
porary maneuver that will speed up only one process. It is not possible to add another fast bus between the CPU and the fast network I/O card because this overloads the CPU.
One solution to this problem, the PCI (Peripheral Component Interconnect) bus, is becoming a standard for providing fast links between the CPU and other operations. This bus promises to offer enough speed to juggle several different parts that want to send information across the bus. The greatest danger will be long packets that bog down the bus. Devices on the bus cannot seize control of it until the packet is finished traversing the bus. This delay can be significant if the packets are large.
In the future, the possibility of packet delays could make the bus obsolete. The nature of the bus allows any device to communicate with any other one, but only two can communicate at one time. This might have made sense when there was one CPU that did all of the work. Now, though, any desktop system with a collection of I/O processor
s will have trouble letting them all work to capacity if they must communicate through a bus.
But remember that you can't make any change in a component without considering its interplay with other components. For example, distributing processing tasks to CPUs optimized for that particular task without changing the bus architecture will only yield an incremental gain in performance (which is limited by the bus' capacity to move the data between devices). Conversely, a high-speed bus that operates without regard to an attached device's ability to handle the data can be a performance disaster. For example, when a bus passes data faster than the device's buffers and processor can handle, they drop data or require that it be resent frequently.
Over the years, desktop systems have gone through bus changes, so another change to accommodate high-speed networks doesn't seem that drastic. The most radical overhaul will be the operating system. The current batch (MS-DOS, Windows, Mac operating system) eme
rged from an era when each application could assume that it had complete control over the machine. The latest versions provide a cursory amount of multitasking, but they can quickly break down when one application goes awry.
This application-centricism must change. As information pours in from the network, the computer must be able to handle it as a background task. Every few microseconds, the operating system must devote some time to processing the incoming information and making sure that it gets to the right place. If it fails often enough, the buffers will overflow, and the battle will be lost.
More modern operating systems like Windows NT, OS/2, and Unix offer preemptive multitasking. The operating system is capable of interrupting programs and allocating resources to another process. While this approach is a step in the right direction, it is not a complete solution. Too many processes can still bog these operating systems down because the operating systems treat all processes in the same
manner.
The next round of operating systems will need to make decisions about allocating resources in real time. They will have to keep a list of essential programs and ensure that they get a guaranteed amount of time so that they can do the essential work. Real-time versions of Unix are already used in time-critical machines, like ATM network switches. These versions have a light-weight kernel that switches between processes based on real time. The designs in these machines will become more standard in desktop machines that step up to the challenge of handling multiple processes.
Using New Protocols
Even if the computers can absorb the information fast enough and the operating system can keep the data straight without bogging down, the computer still must pack up data correctly for conversing over the network. One of the biggest and most widely known standards for this is TCP/IP, a system that manages the data in blocks and stores it locally before giving it to the local
application that requested it. One computer manufacturer reported that its machine would move a block of data around in local memory as many as four times to satisfy one network TCP/IP transaction.
Protocols like these won't function successfully at high speeds. Higher speeds mean bigger blocks of data, which require more memory and CPU cycles to handle these requests. The CPU will spend more of its time moving the data and less doing something with it when it arrives. When the TCP/IP protocol emerged years ago, many of the networks were much slower than the computers. Adding a layer of software that handled the incoming data made life easier for the applications programmer.
In the faster future, a more rational approach will require each application to bypass any local network protocol arbitrator and set up direct, virtual connections between itself and another machine. It will be important to remove any level of abstraction, such as TCP/IP's socket-based system, so the two applications bridgin
g the network can shuffle packets directly.
The ATM standard has the potential to do this successfully. However, the standard covers only how the packets move once they enter the network. The software tools for exploiting this are still emerging.
Keeping Pace
The most likely casualty of all this change will be the imperial CPU that has long ruled the desktop computer. In recent years, it shed some of the responsibility for maintaining the display, as faster GUI-accelerator video cards became common. Now CPU design must change again to cope with the demands of faster network connections.
High-speed I/O controller cards will become increasingly common. The more powerful they are, the more viable they will be. Some manufacturers are currently offering cut-rate prices on ATM cards that require the host CPU to split each data transmission into 53-byte packets. This often bogs down the CPU and absorbs most of its time. The better cards come with their own I/O controller
for handling the buffering and the network connections.
Desktop systems may even come with multiple CPUs that share a common memory space. Such machines are increasingly common in the workstation world. In a multiple-CPU design, one would maintain network connections while the other responded to the user's direct requests. This setup could become necessary if network protocols demand plenty of computational resources.
Eventually, the market might begin to list the network I/O capacity instead of the main CPU number as a measure of a computer's performance. The network I/O's speed will govern how well the system manages multiple video and data streams. Machines with fast network access can link up with remote services that offer virtual-reality graphics, video, and other real-time, data-intensive services. Then probably only writers and other isolated individuals who don't need high-speed interaction will be among the few still using the older, slower systems.
Getting a desktop computer ready for high-speed networking means significant
changes to some fundamental components.
BOTTLENECK PROBLEM POSSIBLE SOLUTION
Network Adapter Cards Cannot handle high-speed More on-board processing
data flow I/O tasks power and memory
PC bus Current bus architectures' Higher-speed bus, such as
low capacities and PCI, and nonblocking
blocking nature architectures
CPU Processing power diverted Processors on I/O cards
to handling communications that off-load some of the
tasks CPU's communications
tasks
Operating System Many operating systems' Multitasking operating
single-tasking natures tie systems that allocate
up a system when handling resources in real-time
long data streams
Networking Protocol Built-in features, such as Newer protocols, such as
error detection and ATM, that rely on higher-
handling, bog down systems layer functions to deal
with errors
Peter Wayner is a BYTE consulting editor based in Baltimore, Maryland. He can be reached on BIX at
pwayner@bix.com
or on the Internet at
pcw@access.digex.com
.
Network-Ready Computers
