Of the two resources discussed in this chapter, one (bandwidth) is often hard for the new system administrator to understand, while the other (processing power) is usually a much easier concept to grasp.
Additionally, it may seem that these two resources are not that closely related — why group them together?
The reason for addressing both resources together is that these resources are based on the hardware that tie directly into a computer's ability to move and process data. As such, their relationship is often interrelated.
At its simplest, bandwidth is simply the capacity for data transfer — in other words how much data can be moved from one point to another in a given amount of time. Having point-to-point data communication implies two things:
A set of electrical conductors used to make low-level communication possible
A protocol to facilitate the efficient and reliable communication of data
There are two types of system components that meet these requirements:
Buses
Datapaths
In the following sections, we will explore both in more detail.
As stated above, buses enable point-to-point communication, and use some sort of protocol to ensure that all communication takes place in a controlled manner. However, buses have other distinguishing features:
Standardized electrical characteristics (such as the number of conductors, voltage levels, signaling speeds, etc.)
Standardized mechanical characteristics (such as the type of connector, card size, etc.)
Standardized protocol
The word "standardized" is important because buses are the primary way in which different system components are connected together.
In many cases, buses allow the interconnection of hardware that is made by multiple manufacturers; without standardization, this would not be possible. However, even in situations where a bus is proprietary to one manufacturer, standardization is important because it allows that manufacturer to more easily implement different components by using a common interface — the bus.
Datapaths can be harder to identify but, like buses, they are everywhere. Also like buses, datapaths enable point-to-point communication. However, unlike buses, datapaths:
Use a simpler protocol (if any)
Have little (if any) mechanical standardization
The reason for these differences is that datapaths are normally internal to some system component, and are not used to facilitate the ad-hoc interconnection of different components. As such, datapaths are highly optimized for a particular situation, where speed and low cost are preferred over general-purpose flexibility.
There are two ways in which bandwidth-related problems may occur (for either buses or datapaths):
The bus or datapath may represent a shared resource. In this situation, high levels of contention for the bus will reduce the effective bandwidth available for all devices on the bus.
A SCSI bus with several highly-active disk drives would be a good example of this. The highly-active disk drives will saturate the SCSI bus, leaving little bandwidth available for any other device on the same bus. The end result is that all I/O to any of the devices on this bus will be slow, even if the device itself is not overly active.
The bus or datapath may be a dedicated resource with a fixed number of devices attached to it. In this case, the electrical characteristics of the bus (and to some extent the nature of the protocol being used) limit the available bandwidth. This is usually more the case with datapaths than with buses.
This is one reason why graphics adapters tend to perform more slowly when operating at higher resolutions and/or color depths; there is more data that must be passed between the datapath connecting video memory and the graphics processor.
Fortunately, bandwidth-related problems can be addressed. In fact, there are several approaches you can take to address bandwidth-related problems:
Increase the capacity
Spread the load
Reduce the load
In the following sections, we will explore each approach in more detail.
The obvious solution to insufficient bandwidth is to increase it somehow. However, this is usually an expensive proposition. Consider, for example, a SCSI controller and its overloaded bus. In order to increase its bandwidth, the SCSI controller, and likely all devices attached to it, would need to be replaced. If the SCSI controller is a separate card, this would be a relatively straightforward process, but if the SCSI controller is part of the system's motherboard, it becomes much more difficult to justify the economics of such a change.
Another approach is to more evenly distribute the bus activity. In other words, if one bus is overloaded, and another is idle, perhaps the situation would be improved by moving some of the load to the idle bus.
As a system administrator, this is the first approach you should consider, as often there are additional buses already present in your system. For example, most PCs include at least two IDE channels (which is just another name for a bus). If you have two IDE disk drives and two IDE channels, why should the drives both be on the same channel?
Even if your system configuration does not include additional buses, spreading the load might still be a reasonable approach. The hardware expenditures to do so would be less expensive than replacing an existing bus with higher-capacity hardware.
At first glance, reducing the load and spreading the load appear to be different sides of the same coin. After all, when one spreads the load, it acts to reduce the load (at least on the overloaded bus), correct?
While this viewpoint is correct, it is not the same as reducing the load globally. The key here is to determine if there is some aspect of the system load that is causing this particular bus to be overloaded. For example, is a network heavily loaded due to activities that are unnecessary? Perhaps a small temporary file is the recipient of heavy read/write I/O. If that temporary file was created on a networked file server, a great deal of network traffic could be eliminated by simply working with the file locally.
All system administrators should be aware of bandwidth, and how system configuration and usage impacts available bandwidth. Unfortunately, it is not always apparent what is a bandwidth-related problem and what is not. Sometimes, the problem is not the bus itself, but one of the components attached to the bus.
For example, consider a SCSI adapter that is connected to a PCI bus, and providing a SCSI bus. However, if there are performance problems with SCSI I/O, it might be the result of a poorly-performing SCSI adapter, even though the SCSI and PCI buses are nowhere near their bandwidth capabilities.