Mailinglist Archive: opensuse-es (1031 mails)

< Previous Next >
Re: [opensuse-es] Como probar ancho de banda real
  • From: jose maria <letrados@xxxxxxxxxxx>
  • Date: Sun, 22 Apr 2007 18:10:19 +0200
  • Message-id: <200704221810.30353.letrados@xxxxxxxxxxx>
El Viernes, 20 de Abril de 2007 22:39, Alejandro C. González Chávez escribió:
> Hola amigos, recientemenet nos aumentaron el ancho de
> banda de 256 a 512 clear channel y la verdad no se
> como probar esto, alguno de uds sabe la forma de
> probar el ancho de banda real?.
>
> De antemano les agradezco.
>

* Tienes que usar programas de auditoria que sean cliente servidor y a ser 
posible (si buscas la realidad) tres o cuatro conexiones de proveedores que 
no compartan lineas, al menos cable y cobre.

* Hay programas para distintas funciones, sip, tcp, etc, busca por freshmeat o 
sourceforge algo como "test internet performance o bandwitch"
 
* Por ejemplo:
http://sourceforge.net/projects/tptest/
http://sourceforge.net/projects/ndt/

* Una estrategia seria, en el ejemplo la linea que te interesa sera el 
cliente, instalar a mayores un netmonitor para ver los picos en directo, 
subir miles de ficheros pequeños a los servidores, subir un fichero grande a 
los servidores, subir simultaneamente ambos grupos a un servidor y ambos 
grupos a ambos servidores, para ver el comportamiento en conexiones 
simultaneas.

* A la vista del resultado inicial del programa de performance y viendo los 
picos y transmision sostenida, tunear los valores de red de los equipos, en 
linux por defecto se sigue el standard y son opciones generalistas.

* editar /etc/sysctl.conf de clientes y servidores.

* Empezar por esto y repetir los tests.

# incrementar el tamaño del del buffer TCP
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# incrementar los limites del autotunning de linux de los limites de los 
#Buffers TCP.
# min, defecto, y max numero de bytes a usar
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# no cachear ssthresh de las conexiones previas
net.ipv4.tcp_no_metrics_save = 1

# recomendado incrementarlo para 1000 BT o superior
net.core.netdev_max_backlog = 2500
# Para 10 GigE, 
# net.core.netdev_max_backlog = 30000

sysctl -p (man sysctl)
leer /usr/src/linux-xxx/Documentation/networking/ip-sysctl.txt 
/usr/src/linux-xxxx/Documentation/sysctl/kernel.txt

* Cuando la performance sea alta, atacar los picos de ancho de banda que 
muestre el netmonitor, aplicando QoS con htb (ya puedes aplicar valores 
nominales de ancho de banda decentes como resultado de los test), dando 
prioridad a los paquetes de respuesta y conexiones entrantes.

* Los valores se han de obtener en Monopuesto o hacerlos en el router, seguir 
tuneando la pila hasta dar con los valores que producen la mayor velocidad 
sostenida sin picos o con los minimos (ojo que encontraras antes las 
limitaciones del router (conexiones simultaneas, etc, ) lo digo para que esta 
circunstancia no te equivoque, entonces esa es la velocidad que puede 
considerarse como real, es decir en realidad estaras tuneando las capacidades 
del router ...., teniendo en cuenta que una conexion asincrona en ningun caso 
dara valores de rendimiento en subida igual a otra sincrona del mismo valor 
nominal, vamos que en mi opinion es bastante mejor una 512/512 que una 
3mb/512, a efectos del proveedor todo esto se la suda en conexiones 
domesticas, por la influencia  de la ultima milla, el gobierno, el 
calentamiento global, los protocolos, que venden mas del 50% por encima del 
ancho de banda de que disponen, etc .....

* Y ten en cuenta que los valores maximos son los del rendimiento sostenido, y 
producen un rendimiento superior al menos en un 20% a valores con picos 
maximos que implica minimos, tirada de paquetes y retransmision de los 
mismos.

* Los bufferes de las tarjetas no creo que influyan negativamente en esa 
conexion.


< Previous Next >