Lo hice y lo entendí

El blog de Vicente Navarro
13 dic

Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget)

No sé qué le pasa últimamente a mi router Zyxel 660HW en su función de switch de red para conectar los diferentes ordenadores de casa. Mientras que el ancho de banda de red que debería de permitir para la comunicación entre los ordenadores debería de ser cercano a los teóricos 100 Mbps, hay veces que no hace falta esforzarse mucho para ver que realmente es muy inferior, hasta llegar a ver cosas como esta usando Samba entre un sistema con Ubuntu y otro con Debian:

Sin saber realmente por qué me está ocurriendo esto, este problema me sirve para hablar del IPerf, una pequeña utilidad que nos sirve para medir el ancho de banda efectivo entre dos sistemas de la red usando TCP o UDP. Como está disponible para Windows, y para los diferentes sistemas UNIX (en Debian y Ubuntu existe un paquete en la distribución estándar), podemos usarla entre dos nodos cualquiera conectados a una red para ver el ancho de banda real que, tras quitar las cabeceras y los retardos que introducen los dispositivos de red intermedios, nos queda.

En un extremo la ejecutaremos en modo servidor, con la opción -s:

debian $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.2 port 5001 connected with 192.168.1.3 port 53490
[  4]  0.0-10.3 sec    116 MBytes  94.1 Mbits/sec

En el otro extremo, en modo cliente, con la opción -c. Por defecto, ambos extremos usan el puerto 5001:

ubuntu $ iperf -c debian
------------------------------------------------------------
Client connecting to debian, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.3 port 53490 connected with 192.168.1.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec    116 MBytes  96.3 Mbits/sec

Vemos que, de una red de 100 Mbps salen 94-96 Mbps. No está mal.

Por defecto, es el cliente es el que manda datos al servidor durante 10 segundos (a menos que usemos el parámetro -t en el cliente). Curiosamente, si hago la prueba al revés, para que el ordenador con Debian mande al ordenador con Ubuntu, obtengo algo menos de velocidad:

ubuntu $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.3 port 5001 connected with 192.168.1.2 port 35792
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec    104 MBytes  87.1 Mbits/sec

debian $ iperf -c ubuntu
------------------------------------------------------------
Client connecting to ulises, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.2 port 35792 connected with 192.168.1.3 port 5001
[  3]  0.0-10.0 sec    104 MBytes  87.2 Mbits/sec

Pero en realidad, tales números sólo los obtengo cuando no está ocurriendo nada más en la red. La realidad es que si el router está trabajando en otras cosas, los números que puedo obtener son bastante peores. Definitivamente, mi router/switch no tiene bastante potencia para mover varios flujos de datos a la vez a 100 Mbps entre sus diferentes interfaces:

debian $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.2 port 5001 connected with 192.168.1.3 port 43429
[  4]  0.0-10.4 sec  38.9 MBytes  31.3 Mbits/sec

ubuntu $ iperf -c debian
------------------------------------------------------------
Client connecting to debian, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.3 port 43429 connected with 192.168.1.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  38.9 MBytes  32.0 Mbits/sec

Pero lo que es el colmo es lo que estoy viendo estos últimos días, que se traduce en la captura de la copia de datos con Samba del principio de la entrada:

ubuntu $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  5] local 192.168.1.3 port 5001 connected with 192.168.1.2 port 36886
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.2 sec  2.38 MBytes  1.96 Mbits/sec

debian $ iperf -c ubuntu
------------------------------------------------------------
Client connecting to ubuntu, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.2 port 36886 connected with 192.168.1.3 port 5001
[  3]  0.0-10.2 sec  2.38 MBytes  1.96 Mbits/sec

¡Menos de 2 Mbps! En los aproximadamente 4 años que llevo con este router, nunca me había hecho estas cosas. Sí que estaba acostrumbrado a no mover datos entre ordenadores a más de unos 4MB/seg (los 32 Mbps que salían anteriormente). Eso era lo normal, y me parecía razonablemente aceptable, pero ahora, de vez en cuando le da por hacer esto y no se arregla hasta que lo reinicio y sólo por un rato. ¿Será problema de hardware? ¿Será problema de software? ¿Ha llegado la hora de cambiar el router?

Por cierto, si necesitamos medir el ancho de banda y no tenemos el más versátil IPerf a mano, siempre podemos recurrir a un clásico scp, pero tendremos que tener en cuenta la carga adicional en encriptar y desencriptar los datos en ambos extremos:

debian $ scp linux-2.6.25.5.tar.bz2 vicente@ubuntu:/tmp/
linux-2.6.25.5.tar.bz2                        100%   46MB   3.6MB/s   00:13

También podemos usar un netcat con un dd o con un pv para que nos midan la velocidad de transferencia:

debian $ cat linux-2.6.25.5.tar.bz2 | nc -q 0 ubuntu 2222

ubuntu $ nc -lp 2222 | dd of=/dev/null
68980+31407 records in
94901+1 records out
48589640 bytes (49 MB) copied, 6.28166 s, 7.7 MB/s

debian $ cat linux-2.6.25.5.tar.bz2 | nc -q 0 ubuntu 2222

$ nc -lp 2222 | pv > /dev/null
46.3MB 0:00:06 [7.43MB/s] [     <=>                                           ]

Si en uno de los sitemas tenemos un servidor web, el wget también nos dará estadísticas de velocidad de transferencia:

$ wget http://debian/linux-2.6.25.5.tar.bz2
--2008-12-12 20:17:58--  http://debian/linux-2.6.25.5.tar.bz2
Resolving debian... 192.168.1.2
Connecting to debian |192.168.1.2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 48589640 (46M) [application/x-tar]
Saving to: `linux-2.6.25.5.tar.bz2'

97% [====================================>  ] 47,195,808   418K/s  eta 4s

ubuntu $ wget http://debian/linux-2.6.25.5.tar.bz2
--2008-12-12 20:20:38--  http://debian/linux-2.6.25.5.tar.bz2
Resolving debian... 192.168.1.2
Connecting to debian |192.168.1.2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 48589640 (46M) [application/x-tar]
Saving to: `linux-2.6.25.5.tar.bz2.2'

100%[======================================>] 48,589,640  10.5M/s   in 4.4s    

2008-12-12 20:20:42 (10.4 MB/s) - `linux-2.6.25.5.tar.bz2' saved [48589640/48589640]

¿Se nota que entre las dos ejecuciones he reiniciado el router? ¡Qué diferencia! ¡De 418 KB/s a 10.5 MB/s!.

:wq

Entradas relacionadas

14 Comentarios a “Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget)”

  • Dani dice:

    a mi con un comtrend de telefonica me pasa algo parecido, haciendo un dd a través de netcat o con scp, me marca velocidad máximo de unos 5Mb/s, y de repente baja a 1Mb/s sin que en el servidor o en el cliente se esté realizando algún uso de la red… mmm no tengo más datos pero es algo a mirar..

  • Mozoilo dice:

    ¡Que cosa mas rara!
    Yo tengo el mismo router. Cuando tambien lo usaba de switch para la red de casa variaba de 6 a 8 Mb/seg. Cierto era que las cifras ma bajas se daban cuando desde konqueror usaba fish:// para copiar/pegar a traves de ssh. Samba fluctuaba mucho, con picos a la baja de 5,5. El mas estable y rapido era NFS que no bajaba de 7. Ahora tengo un switch NO configurable y todos los protocolos se mantienen por encima de 7. El peor es samba y ssh o nfs no bajan de 8.
    Estos cambios me dijeron que el router es para lo que es, sobre todo si lleva el firmware de telefonica (presupongo que este es tu caso).
    El oficial de Zyxel dicen los foros que va algo mejor pero donde da algo de guerra es en el wifi. Si te decides a cambiarlo y reservas presupuesto para uno nuevo puedes trastear con las guias de adslayuda o adslzone para cambiar el firmware. Requiere algo de bricolaje con el cable de conexión pero en los mismos foros encuentras casos de exito que hablan de las diferencias. Si te arregla algo, eso que te ahorras.

    Saludos y gracias por las lecciones.

  • Maks3w dice:

    Las últimas veces que he transferido entre equipos y ha ido a lento ha sido por problemas con la lec

  • @Dani Lo curioso es que, dentro de la bajada de ancho de banda cuando el router está siendo más usado, siempre me había funcionado bien, pero lo que me pasa ahora no es normal. Si no reinicio el router, necesito días para mover archivos grandes.

    @Mozoilo Sí, yo también tengo un switch Conceptronic de 15€ y ése no tiene problemas para gestionar varios flujos de 100 Mbps a la vez. Cada cosa es para lo que es. Sobre el firmware del fabricante, yo también he seguido las guías a las que te refieres, y alguna vez he estado a punto de ponerme a hacerme el cable, pero al final nunca lo he hecho… De todas formas, el Zyxel siempre me había ido bien con el firmware de Telefónica. No sé qué le estará pasando ahora.

    @Maks3w Vaya, nos has dejado con la incógnita de cuál era tu problema ;-)

  • En mi router D-Link también he tenido problemsa con samba, y curiosamente usar scp resuelve el problema. El mismo archivo via Samba se transfiere a 3 KB/s y via SCP se transfiere a 10 MB/s…

  • dapobe dice:

    He oido por ahí que en realidad tales switches que llevan los routers no son tales si no que en realidad son hubs, y de ahí la lentidud a la hora de gestionar trafico.

    Teoricamente un switch aislaria el tráfico entre dos dispositivos y no le tendria que afectar el modem interno. Pero en un hub es evidente que todo pasa por el mismo hueco…

    No será que nos estan vendiendo hubs por swiches en los routers???

  • @David Martínez Bueno, en mi caso, no es tema de samba. Absolutamente todo el tráfico va mal. Se puede ver en los resultados de iperf, y fíjate en lo que me da ahora mismo:

    $ scp vicente@debian:~/linux* .
    linux-2.6.25.5.tar.bz2                          4% 2336KB 411.0KB/s   01:49 ETA

    ¡Y lo curioso es que si lo reinicio, se arregla!

    @dapobe Pues es una muy buena pista, gracias, pero creo que no es un hub internamente, porque acabo de capturar el tráfico de la red con WireShark y no soy capaz de ver el tráfico entre otros nodos de la red. Además, ¿por qué iba a empezar a ir tan mal ahora después de tantos años si fuera un tema de características del router? En tal caso, me habría pasado esto siempre…

  • Reirok dice:

    Cuando empecé a leer pensé que podía ser un problema de fragmentación de paquetes por un mal valor de MTU.
    Pero las caídas de valor son muy altas por eso no puede ser el MTU.
    Seguramente hay algo que te esta saturando el procesamiento de datos del Router.
    Yo vería si en los momentos que tenes esa baja transferencia hay muchas sesiones NAT que estén concedidas por el Router.
    Anula la conexión a internet del router por soft, no la conexión del cable, y no pongas el gateway en las terminales clientes.
    Trata de saturar al Router ahora para descartar lo anterior.

    Saludos Reirok.

  • abaca dice:

    Tengo muchos artículos pendientes de leer, pero este me ha resultado muy interesante, y creo que entre todos seremos capaces de averiguar lo que le pasa al router, porque lo que cuentas intriga. Estoy de acuerdo con lo que dice Reirok, yo probaría además a desconectar todos los cables de red/adsl excepto los dos implicados. Por otra parte, ¿tiene el router agente snmp? A lo mejor por ahí puedes ver si en determinados momentos hay algún interfaz con mucho tráfico (puede que te estén haciendo un Dos). Ya nos contarás…

  • @Reirok Gracias por tus sugerencias. Sí que tengo claro que va mal por otras tareas que hace el router. Ya probé a que no hiciera nada más que la transferencia entre ordenadores y no deja de ir rápido en ningún momento. Sin embargo, algo debe de ocurrirle en un momento dado que empieza a funcionar mal. Lo que me asombra es que este router ha estado muchos años trabajando sin dar estos problemas, incluso en la época en la que tenía el hosting en casa.

    Como dice @abaca, muy bien podría ser algún tipo de ataque DoS que no hubiera sufrido nunca y que no acabo de detectar o algún problema de hardware.

  • Juanga dice:

    Hola,

    Por si te sirve, a nosotros Telefónica nos ha cambiado en la oficina un router Zyxel 660HW después de una incidencia por otra cosa (en fin). El asunto es que el técnico nos explicó que ha salido un nuevo modelo de 660HW en el que las chapitas de los puertos ethernet son de plástico en lugar de ser metálicas. Según dijeron, se recalientan y esto provoca cortes esporádicos. No sé si tendrá que ver con tu tema, pero viendo la antigüedad que dices que hace que lo tienes, igual te sirve de ayuda.

    Acabo de mirar el modelo exacto del nuevo que tenemos hace varias semanas y es Zyxel 660HW DH-1, con los puertos de plástico en color amarillo ;)

    Un saludo,

    Juanga.

  • @Juanga Muchas gracias por la información. Sin embargo, si fuera por el modelo inicial del router, habría tenido problemas antes ya, no ahora, a los cinco años. Es posible que sea un problema de hardware o de algún tipo de tráfico nuevo que lno le llegara antes y que le cause estos problemas… ¡Qué misterio!

Trackbacks y pingbacks:

Tema LHYLE09, creado por Vicente Navarro