PDF de programación - Wondershaper : Gestiona eficientemente el ancho de banda de tu conexión adsl (o cable)

Bisoños Usuarios de Linux de Mallorca y Alrededores | Bergantells Usuaris de Linux de Mallorca i

Wondershaper : Gestiona eficientemente el ancho de banda de tu
conexión adsl (o cable)

Afegitons

Por Kiko Piris, kiko ()
Creado el 02/10/2002 09:11 y modificado por última vez el 02/10/2002 09:11

Cuando "compraste" tu conexión adsl (o cable) te dijeron que el ancho de banda de bajada era independiente
del de subida. Pero por más pruebas que haces, ¿ no consigues que éso parezca real ?

¿ Quieres poder navegar a la velocidad de siempre (o casi) mientras subes megas a saco a tu servidor ?
¿ Quieres poder trabajar "en condiciones" con una sesión de ssh (o incluso navegar decentemente)

mientras te bajas megas a todo trapo ?

Si es así, sigue leyendo ...

Linux dispone de unos algoritmos de "Quality of Service" (gestión del ancho de banda o "bandwidth
management") que ya quisieran muchos routers.

Primero un poco de teoría -light- (puedes saltartelo si tienes mucha prisa :-) :

Si el ancho de banda de subida y de bajada son independientes, ¿ por qué la cosa no funciona como
debería desde un principio ?

Por culpa de las colas. Cuando el tráfico de subida es grande, se forman colas largas de paquetes en la cola
"Send-Q" (del router). El servidor del cual intentamos bajarnos algo deja de enviarnos paquetes hasta que
recibe los ack’s (y esos ack’s deben atravesar una cola "Send-Q" congestionada).

¿ Qué se puede hacer ?

Limitar la velocidad de subida un poco por debajo de nuestro ancho de banda. Así conseguimos que las colas
"largas" se formen en nuestro equipo (y no en el router). Ahora podemos hacer que los paquetes del tipo "ack"
y de tráfico interactivo pasen por delante de los otros y no tengan que "hacer cola".

Nos queda un punto por resolver. La cola de bajada. Esta cola se encuentra en los equipos de nuestro ISP. Si la
cola de bajada es demasiado larga, el tráfico interactivo se verá afectado negativamente. La solución para
evitar ésto es limitar la velocidad de bajada un poquito con el siguiente "truco" : si los paquetes llegan
"demasiado rápido", los descartaremos y entonces el emisor adecuará su velocidad de transmisión a la
nuestra.

De esta manera sacrificando un poquito de nuestro ancho de banda conseguiremos 2 cosas: aprovechar los
anchos de banda independientes de subida y de bajada, y que el tráfico "masivo" no nos deje la latencia
del tráfico interactivo por los suelos . Casi nada !

Ahora lo práctico :

¿ Qué necesito ?

Wondershaper es un script muy sencillo que nos definirá las colas necesarias para implementar lo que he
comentado en el punto anterior. De hecho la información está sacada directamente del README, os
recomiendo su lectura.

Pero antes de ponernos con el script, necesitamos habilitar (si no lo están ya) un par de cosillas en nuestro
kernel 2.4.

Debemos tener al menos las siguientes opciones activadas dentro de "Networking Options" / "QoS and/or
Fair Queueing" : CBQ, PRIO, SFQ, Ingress Qdisc, QoS support, Rate Estimator, Packet classifier,
Firewall based classifier. U32 classifier y Traffic Policing. Aunque puedes activar todo lo de dentro de QoS
and/or Fair Queueing sin problemas.

También hemos de instalar el paquete iproute2.

Wondershaper nos proporciona dos versiones del script : "wshaper" que nos servirá con cualquier kernel 2.4
y que usa el algoritmo CBQ. Y "wshaper.htb" que usa el algoritmo HTB (HTB no viene incluido en todos
los kernels, viene a partir del 2.4.20-pre1; o nos actualizamos o parcheamos nuestro kernel).

CBQ es un algoritmo más usado y testeado pero técnicamente inferior a HTB (?). La tendencia parece ser
que es hacia HTB. Yo lo he implementado usando HTB (con el kernel 2.4.20-pre8) y no he tenido ningun
problema (os lo recomiendo).

Pero antes hay que hacer una comprobación: si vamos a usar HTB, la versión del algoritmo HTB del kernel
debe corresponderse con la versión del binario tc que viene en el paquete iproute2. Si al ejecutar el script
wshaper.htb os da errores y en el syslog se os queja de la versión del HTB, bajaros el binario tc de aquí y
sustituid el que tengais en vuestro sistema (a mi me pasó con Debian sid).

Una vez tenemos nuestro kernel listo y el iproute2 adecuado instalado, pasamos al script que define las
colas.

Aquí me centraré en wshaper.htb que es el que he usado yo (aunque tampoco es que haya mucho que
comentar ...).

Lo único que tenemos que hacer es definir los anchos de banda de bajada y de subida y el interfaz de red
donde tenemos conectado el router. Modificando las siguientes líneas (son Kilobits/s) :

DOWNLINK=208
UPLINK=120
DEV=eth0

Los valores mostrados son los que me han funcionado a mí con una línea adsl de telefónica de 256 Kbits. Se
trata de ir probando y ajustando hasta encontrar los valores óptimos para nuestra conexión (cómo dicen los
ingleses: YMMV).

Copiamos el script en /etc/init.d/ y ponemos los enlaces simbólicos correspondientes en /etc/rc.X/ (ojo, esto es
para Debian, para otras distros, consultar la documentación de los scripts de arranque de los servicios,
YMMV).

En el script wshaper.htb pueden personalizarse otras cosillas, para mas información leeros el README y los
comentarios que encontrareis en el mismo script.

Con HTB pueden hacerse auténticas virguerías , pero éso se escapa del objetivo de este artículo.

PD.: Si alguien lo prueba con otra conexión a Internet, estaría bien que pusiera los valores que haya
encontrado como comentarios para compartir la información.

E-mail del autor: [email protected]
Podrás encontrar este artículo e información adicional en:
http://bulmalug.net/body.phtml?nIdNoticia=1527