Cap�tulo 3. Ancho de banda y poder de procesamiento
De los dos recursos discutidos en este cap�tulo, uno (el ancho de banda) es a menudo dif�cil de entender para los nuevos administradores de sistemas, mientras que el otro concepto (poder de procesamiento), es usualmente mucho m�s f�cil de comprender.
Adicionalmente, puede parecer que estos dos recursos no est�n muy relacionados — �por qu� agruparlos?
La raz�n para referirse a estos dos recursos juntos es porque est�n basados en el hardware que se une directamente con la habilidad del computador de mover y procesar datos. Como tal, su relaci�n a menudo est� interrelacionada.
3.1. Ancho de banda
En su forma m�s simple, el ancho de banda es la capacidad de transferencia de datos — en otras palabras, la cantidad de datos que se pueden mover de un punto a otro en cierta cantidad de tiempo. El tener una comunicaci�n de datos de punto a punto implica dos cosas:
Un conjunto de conductores el�ctricos utilizados para hacer posible la comunicaci�n a bajo nivel
Un protocolo para facilitar la comunicaci�n de datos confiable y eficiente
Hay dos tipos de componentes de sistemas que satisfacen estos requerimientos:
Buses
Datapaths
Las secciones siguientes exploran cada uno de estos en m�s detalles.
3.1.1. Buses
Como se mencion� anteriormente, los buses permiten la comunicaci�n de punto a punto y utilizan alg�n tipo de protocolo para asegurarse de que toda la comunicaci�n toma lugar de forma controlada. Sin embargo, los buses tienen otras caracter�sticas distintivas:
Caracter�sticas el�ctricas estandarizadas (tales como el n�mero de conductores, niveles de voltage, velocidades de se�ales, etc.)
Caracter�sticas mec�nicas estandarizadas (tales como el tipo de conector, tama�o de la tarjeta, formato f�sico, etc.)
Protocolo est�ndar
La palabra "estandarizado" es importante porque los buses son la principal forma en la que diferentes componentes de software se juntan.
En muchos casos, los buses permiten la interconexi�n del hardware hecho por diferentes fabricantes; sin estandarizaci�n, esto no ser�a posible. Sin embargo, a�n en situaciones donde un bus es propiedad de un fabricante, la estandarizaci�n es importante porque permite a ese fabricante implementar m�s f�cilmente diferentes componentes usando una interfaz com�n — el bus mismo.
3.1.1.1. Ejemplos de buses
No importa d�nde en el computador usted revise, habr� buses. He aqu� algunos de los m�s comunes:
Los datapaths pueden ser m�s dif�ciles de identificar pero, como los buses, est�n en todas partes. Tambi�n a igual que los buses, los datapaths permiten la comunicaci�n punto a punto. Sin embargo, a diferencia de los buses, los datapaths:
Utilizan un protocolo m�s simple (si es que lo utilizan)
Tienen poca (o ninguna) estandarizaci�n mec�nica
La raz�n de estas diferencias es que los datapaths son normalmente internos a algunos componentes de sistemas y no son usados para facilitar la interconexi�n ad-hoc de componentes diferentes. Como tal, los datapaths son muy optimizados para una situaci�n particular, donde la velocidad y el bajo costo se prefieren sobre una flexibilidad m�s lenta y m�s costosa de prop�sito general.
3.1.2.1. Ejemplos de Datapaths
He aqu� algunos datapaths t�picos:
Datapath de CPU a cach� en chip
Datapath de procesador gr�fico a memoria de v�deo
3.1.3. Problemas potenciales relacionados al ancho de banda
Hay dos formas en la que pueden ocurrir problemas relacionados al ancho de banda (tanto para buses como para datapaths):
El bus o datapath puede representar un recurso compartido. En esta situaci�n, los altos niveles de competencia por el bus reducen el ancho de banda efectivo disponible para todos los dispositivos en el bus.
Un bus SCSI con discos duros altamente activos ser�an un buen ejemplo de esto. Las unidades de disco altamente activas saturan el bus SCSI, dejando poco ancho de banda disponible para cualquier otro dispositivo en el mismo bus. El resultado final es que toda la E/S a cualquiera de estos dispositivos en el bus es lenta, a�n si cada dispositivo en el bus no est� demasiado activo.
El bus o datapath puede ser un recurso dedicado con un n�mero fijo de dispositivos conectados a �l. En este caso, las caracter�sticas el�ctricas del bus (y hasta cierto punto la naturaleza del protocolo utilizado) limitan el ancho de banda disponible. Usualmente, este es m�s el caso con datapaths que con buses. Esta es una de las razones por las que los adaptadores gr�ficos tienden a funcionar m�s lentamente cuando se operan a altas resoluciones y/o profundidades de color — por cada refrescado de pantalla, hay m�s datos que transmitir a trav�s del datapath que conecta la memoria de v�deo al procesador gr�fico.
3.1.4. Soluciones potenciales relacionadas al ancho de banda
Afortunadamente, los problemas relacionados al ancho de banda se pueden resolver. De hecho, se pueden tomar varios enfoques:
Distribuir la carga
Reducir la carga
Incrementar la capacidad
Las secciones siguientes exploran cada uno de estos enfoques en mas detalles.
3.1.4.1. Distribuir la carga
El primer enfoque es distribuir m�s uniformemente la actividad del bus. En otras palabras, si un bus est� sobrecargado y otro est� ocioso, quiz�s la situaci�n ser�a mejorada moviendo algo de la carga hasta el bus ocioso.
Como administrador del sistema, este es el primer enfoque que deber�a considerar, pues a menudo existen buses adicionales ya instalados en su sistema. Por ejemplo, la mayor�a de los PCs incluyen al menos dos canales ATA (lo cual es simplemente otro nombre para un bus). Si tiene dos unidades de disco ATA y dos canales ATA, �por qu� deber�an estar ambas unidades en el mismo canal?
A�n si su configuraci�n no incluye buses adicionales, distribuir la carga puede ser todav�a el mejor enfoque. Los gastos de hardware en hacer esto ser�n mucho menos costosos que reemplazando un bus existente por hardware con mayor capacidad.
3.1.4.2. Reducir la carga
A primera vista, el reducir y distribuir la carga parecen ser los diferentes lados de la misma moneda. Despu�s de todo, cuando uno distribuye la carga, tambi�n se est� reduciendo la misma (al menos en un bus sobrecargado), �cierto?
Mientras que este punto de vista es correcto, no es lo mismo que reducir la carga globalmente. La clave aqu� es determinar si hay alg�n aspecto de la carga del sistema que est� causando que este bus particular est� sobrecargado. Por ejemplo, �est� la red sobrecargada debido a actividades que no son necesarias? Quiz�s un peque�o archivo temporal es el recipiente de grandes lecturas/escrituras de E/S. Si ese archivo temporal reside en un servidor de la red, se podr�a eliminar una gran parte del tr�fico de la red trabajando con el archivo localmente.
3.1.4.3. Incrementar la capacidad
La soluci�n obvia a un ancho de banda insuficiente, es el de incrementarlo de alguna manera. Sin embargo, esto es usualmente una proposici�n costosa. Considere, por ejemplo, un controlador SCSI y su bus sobrecargado. Para incrementar el ancho de banda, se necesita reemplazar el controlador SCSI (y probablemente todos los dispositivos conectados a el) con hardware m�s r�pido. Si el controlador SCSI es una tarjeta separada, esto ser�a un proceso bien directo, pero si el controlador es parte de la tarjeta madre del sistema, se vuelve mucho m�s dif�cil justificar econ�micamente este cambio.
3.1.5. En resumen…
Todos los administradores de sistemas deber�an estar conscientes del ancho de banda y de c�mo la configuraci�n y uso del sistema impacta el ancho de banda disponible. Desafortunadamente, no siempre es aparente cuando se trata de un problema de ancho de banda y cuando no. Algunas veces, el problema no es el bus mismo, pero uno de los componentes conectados al bus.
Por ejemplo, considere un adaptador SCSI que est� conectado a un bus PCI. Si hay problemas de rendimiento con la E/S del disco SCSI, puede ser el resultado de un adaptador SCSI funcionando muy mal, a�n cuando los buses SCSI y PCI mismos no esten ni siquiera cerca de sus capacidades de ancho de banda.
