Regla #1: La velocidad de la CPU es ms importante que la velocidad de la red Una amplia experiencia ha demostrado que en casi todas

las redes la sobrecarga de los sistemas operativos y protocolos domina el tiempo de utilizacin en el alambre. Por ejemplo, en teora, el tiempo mnimo de una RPC en una red Ethernet es de 102 seg, correspondiente a una solicitud mnima (64 bytes) seguida de una respuesta mnima (64 bytes). En la prctica, reducir la sobrecarga de software y conseguir el tiempo de RPC ms cercano a 102 seg es un logro considerable. De la misma manera, el problema principal al operar a 1 Gbps es llevar los bits desde el bfer del usuario hasta la primera fibra a velocidad suficiente y lograr que la CPU receptora los procese tan rpidamente como entran. En pocas palabras, si se duplica la velocidad de la CPU, con frecuencia casi se puede duplicar la velocidad real de transporte. La duplicacin de la capacidad de la red en muchos casos no tiene efecto, ya que el cuello de botella generalmente est en los hosts Regla #2: Reducir el nmero de paquetes para reducir la sobrecarga de software El procesamiento de una TPDU tiene cierta cantidad de sobrecarga por TPDU (por ejemplo, procesamiento de encabezados) y cierta cantidad de procesamiento por byte (por ejemplo, procesar la suma de verificacin). Al enviar 1 milln de bytes, la sobrecarga por byte es la misma sin importar el tamao de la TPDU. Sin embargo, el uso de TPDUs de 128 bytes implica 32 veces ms sobrecarga por TPDU que el uso de TPDUs de 4 KB. Esta sobrecarga crece con rapidez. Adems de la sobrecarga de las TPDUs, hay una sobrecarga en las capas inferiores que se debe considerar. Cada paquete que llega causa una interrupcin. En un procesador moderno con canalizacin, cada interrupcin rompe la canalizacin de la CPU, interfiere con el cach, requiere un cambio en el contexto de administracin de la memoria y obliga al almacenamiento de una cantidad de registros de CPU importante. Una reduccin de n veces en las TPDUs enviadas reduce la sobrecarga de la interrupcin y de los paquetes en un factor de n. Esta observacin es un argumento a favor de la recoleccin de una cantidad importante de datos antes de su transmisin, a fin de reducir las interrupciones en el otro lado. El algoritmo de Nagle y la solucin de Clark al sndrome de la ventana tonta son intentos por lograr precisamente esto. Regla #3: Reducir al mnimo las conmutaciones de contexto Las conmutaciones de contexto (por ejemplo, del modo de kernel al modo de usuario) son mortales; pueden tener los mismos inconvenientes que las interrupciones, siendo la peor una larga serie de fallas de cach iniciales. Las conmutaciones de contexto pueden reducirse haciendo que el procedimiento de biblioteca que enva los datos los guarde en un bfer interno hasta tener una buena cantidad de ellos. De la misma manera, en el lado receptor las TPDUs de entrada pequeas deben juntarse y pasarse al usuario como un bloque completo y no individualmente, para reducir al mnimo las conmutaciones de contexto. En el mejor caso, un paquete entrante causa una conmutacin de contexto del usuario actual al ncleo, y luego una conmutacin al proceso receptor para darle los nuevos datos. Desgraciadamente, en muchos sistemas operativos ocurren conmutaciones de contexto adicionales. Por ejemplo, si el administrador de la red ejecuta un proceso especial en el espacio de usuario, un paquete entrante tender a causar una conmutacin de contexto del usuario actual al kernel, luego otra del kernel al administrador de red, seguida de otra de regreso al kernel y, por ltimo, una de ste al proceso receptor. Esta secuencia se muestra en la figura 6-43. Todas estas conmutaciones de contexto en cada paquete desperdician mucho tiempo de CPU y tienen un efecto devastador sobre el desempeo de la red. Regla #4: Reducir al mnimo las copias Peores que las mltiples conmutaciones de contexto son las mltiples copias. No es inusitado que un paquete entrante se copie tres o cuatro veces antes de entregarse la TPDU que contiene. Despus de recibirse un paquete en la interfaz de la red en un bfer especial integrado a una tarjeta, es comn que se copie en un bfer del kernel. De ah se copia en el bfer de capa de red, luego en el bfer de la capa de transporte y, por ltimo, en el proceso de aplicacin receptor. Un sistema operativo ingenioso copiar una palabra a la vez, pero no es raro que se requieran unas cinco instrucciones por palabra (carga, almacenamiento, incremento de un registro de ndice, prueba de fin de datos y ramificacin condicional). La elaboracin de tres copias de cada paquete a cinco instrucciones por palabra de 32 bits copiada requiere 15/4 o cerca de cuatro instrucciones por byte copiado. En una CPU de 500 MIPS, una instruccin toma 2 nseg, de tal manera que cada byte necesita 8 nseg de tiempo de procesamiento o cerca de 1 nseg por bit, lo cual da una tasa mxima de 1 Gbps. Si incluimos la sobrecarga del procesamiento del encabezado, el manejo de interrupciones y las conmutaciones de contexto, podran lograrse 500 Mbps, sin considerar el procesamiento real de los datos. Queda claro que es imposible manejar a toda velocidad una lnea Ethernet de 10 Gbps. De hecho, es probable que tampoco se pueda manejar a toda velocidad una lnea de 500 Mbps. En el clculo anterior hemos supuesto que una mquina de 500 MIPS puede ejecutar 500 millones de instrucciones por segundo. En realidad, las mquinas slo pueden operar a tales velocidades si no hacen referencia a la memoria. Las operaciones de memoria con frecuencia son diez veces ms lentas que las instrucciones registro a registro (es decir, 20 nseg/instruccin). Si en realidad 20 porciento de las instrucciones hacen referencia a la memoria (es decir, son fallas de cach), lo cual e probable cuando entran en contacto con los paquetes entrantes, el tiempo de ejecucin promedio de las instrucciones es de 5.6 nseg (0.8 2 + 0.2 20). Con cuatro instrucciones/byte, necesitamos 22.4 nseg/byte, o 2.8 nseg/bit), lo cual da cerca de 357 Mbps. Al factorizar 50 por ciento de sobrecarga da como resultado 178 Mbps. Observe que la asistencia de hardware no ayuda aqu. El problema es que el sistema operativo est ejecutando demasiadas copias. Regla #5: Es posible comprar ms ancho de banda, pero no un retardo menor

Las tres reglas que siguen tienen que ver con la comunicacin, ms que con el procesamiento del protocolo. La primera regla indica que, si se desea ms ancho de banda, se puede comprar. La instalacin de una segunda fibra junto a la primera duplica el ancho de banda, pero no hace nada para reducir el retardo. Para que el retardo sea ms corto es necesario mejorar el software del protocolo, el sistema operativo o la interfaz de red. Incluso si se mejoran las tres cosas, el retardo no se reducir si el cuello de botella es el tiempo de transmisin. Regla #6: Evitar la congestin es mejor que recuperarse de ella La vieja mxima de que ms vale prevenir que lamentar ciertamente se aplica a la congestin en redes. Al congestionarse una red, se pierden paquetes, se desperdicia ancho de banda, se introducen retardos intiles, y otras cosas. La recuperacin requiere tiempo y paciencia; es mejor no tener que llegar a este punto. Evitar la congestin es como recibir una vacuna: duele un poco en el momento, pero evita algo que sera mucho ms doloroso. Regla #7: Evitar expiraciones del temporizador Los temporizadores son necesarios en las redes, pero deben usarse con cuidado y deben reducirse al mnimo las expiraciones del temporizador. Al expirar un temporizador, lo comn es que se repita una accin. Si realmente es necesario repetir la accin, que as sea, pero su repeticin innecesaria es un desperdicio. La manera de evitar el trabajo extra es tener cuidado de que los intervalos del temporizador sean ms bien conservadores. Un temporizador que tarda demasiado en expirar agrega una pequea cantidad de retardo extra a una conexin en el caso (improbable) de la prdida de una TPDU. Un temporizador que expira cuando no debera consume tiempo de CPU valioso, desperdicia ancho de banda e impone una sobrecarga tal vez a docenas de enrutadores sin razn alguna.