BandaAncha.eu

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate

Velocidad de descarga en linux, ¿por que es mas lento?

BocaDePez
BocaDePez

Saludos, vereis tengo ADSL 20 megas y haciendo pruebas de velocidad sobre una misma descarga varias veces en Windows y otras tantas en Ubuntu Linux. Concluyo que en windows la velocidad oscila entre 840 y 860 KBytes/seg mientras que en Ubuntu me da entre 680 y 700 KBytes/seg. ¿Sabeis a que se debe esta diferencia? Es demasiado como para pasarlo por alto. Para colmo tambien he usado el mismo navegador y version (Firefox 1.5.0.5).

Leyendo y tal descubrí que el valor optimo del MTU para mi conexión por ser de protocolo PPOE era 1492. Asi que buscando consegui encontrar como cambiarlo en Ubuntu, hice sudo gedit /etc/network/interfaces y una vez dentro añadi a mi interfaz de red ethernet la informacion del MTU como se muestra en la linea en negrita.

auto eth0
iface eth0 inet static
address 192.168.1.3
netmask 255.255.0.0
gateway 192.168.1.1
mtu 1492

Tras salvar y reiniciar tecleando el comando ifconfig compruebo que todo ha ido bien y el nuevo MTU de eth0 es 1492 pero aún así la descarga es mucho más lenta que en windows en el que tambien puse el MTU a 1492.

¿Sabría alguien explicarme por que ocurre esto y si es posible orientarme hacia una solución que me permita descarga en Ubuntu tan rapido como lo hago en Windows?

¡Muchas gracias!

Este tema está cerrado a nuevas respuestas. Abre un nuevo tema para retomar la conversación.
granda

Muy buenas,

¿Has echado un vistazo a Cómo optimizar Ubuntu ?

¿Cómo has hecho las pruebas?, ¿mismo horario?, ¿mismo protocolo (entiendo que http)?, ¿mismos archivos (cacheo en algún lado)?

Creo recordar que la resolución de nombres en GNU/linux va por timeout entre los diferentes servidores que hay en /etc/resolv.conf y en Windows si uno no responde, salta al siguiente.

Saludos

Editado: corregido el enlace, contenía doble "http://"

🗨️ 2
BocaDePez
BocaDePez

en tu enlace de optimizar ubuntu sale El Pais

🗨️ 1
granda

Gracias por el aviso del enlace defectuoso, pero no sé por qué te sale "El País", desde luego ahí no apuntaba...

Frankie2004

Aparte del tema del MTU está el tema del RWIN ... ver artículo de Luke en foro de Jazztel:

RWIN: Solución a bastantes problemas de velocidad

Y luego esta información sobre el control de los valores en Linux:

======================================================================

The maximum buffer sizes for all sockets can be set with /proc variables:

/proc/sys/net/core/rmem_max - maximum receive window
/proc/sys/net/core/wmem_max - maximum send window

These determine the maximum acceptable values for SO_SNDBUF and SO_RCVBUF (arguments to setsockopt() system call). The kernel sets the actual memory limit to twice the requested value (effectively doubling rmem_max and wmem_max) to provide for sufficient memory overhead.

The per connections memory space defaults are set with two 3 element arrays:

/proc/sys/net/ipv4/tcp_rmem - memory reserved for TCP rcv buffers
/proc/sys/net/ipv4/tcp_wmem - memory reserved for TCP snd buffers

These are arrays of three values: minimum, default and maximum that are used to bound autotuning and balance memory usage while under global memory stress.

The following values would be reasonable for path with a 4MB BDP (You must be root):

echo 2500000 > /proc/sys/net/core/wmem_max
echo 2500000 > /proc/sys/net/core/rmem_max
echo "4096 5000000 5000000" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 65536 5000000" > /proc/sys/net/ipv4/tcp_wmem

All current Linux 2.4 and 2.6 versions include sender side autotuning, so the actual sending socket buffer (wmem value) will be dynamically updated for each connection. You can check to see if receiver side autotuning is present an enabled by looking at the file:

/proc/sys/net/ipv4/tcp_moderate_rcvbuf

If it is present and enabled (value 1) (and the TCP receiver buffer size is not explicitly adjusted), the receiver socket buffer size (rmem value) will be dynamically updated for each connection. Generally autotuning should not be disabled unless there is a specific need, e.g. comparison studies of TCP performance.

NB:Manually adjusting socket buffer sizes with setsockopt() implicitly disables autotuning. Application that are optimized for other operating systems may be non-optimal on Linux.

If autotuning is not present (Linux 2.4 before 2.4.27 or Linux 2.6 before 2.6.7), you may want to get a newer kernel. Alternately, you can set the global default receive socket buffer size by setting the middle value of the tcp_rmem array.

Do not adjust tcp_mem unless you know exactly what you are doing. This array determines how the system balances the total network memory usage against other memory usage, such as disk buffers. It is initialized at boot time to appropriate fractions of total system memory.

You do not need to adjust rmem_default or wmem_default (at least not for TCP tuning). These are the default buffer sizes for non-TCP sockets (e.g. unix domain sockets, UDP, etc).

All standard advanced TCP features are on by default. You can check them by cat'ing the following /proc files:

/proc/sys/net/ipv4/tcp_timestamps
/proc/sys/net/ipv4/tcp_window_scaling
/proc/sys/net/ipv4/tcp_sack

Linux supports both /proc and sysctl (using alternate forms of the variable names - net.core.rmem_max) for inspecting and adjusting network tuning parameters. The following is a useful shortcut for inspecting all tcp parameters:

sysctl -a | fgrep tcp
For additional information on kernel variables, look at the documentation included with your kernel source, typically in some location such as /usr/src/linux-/Documentation/networking/ip-sysctl.txt. There is a very good (but slightly out of date) tutorial on network sysctl's at (link roto)

If you would like to have these changes to be preserved across reboots, you can add the tuning commands to your /etc/rc.d/rc.local file.

Autotuning was prototyped under the Web100 project. Web100 also provides complete TCP instrumentation and some additional features to improve performance on paths with very large BDP.

lxuser

Yo no me fio mucho de la velocidad que marcan los exploradores, cuando tenia windows las 4Mb descargando una distro me marcaba 1500kb y pico, ya sabes empieza a velocidades q para nada son de 4mb xD y va bajando bajando hasta q se quedaba estable en unos 500Kb, en linux el firefox parecido bajando la mismo distro me marcaba unos 490Kb, pero en cambio me voy a el monitor de rendimiento y me marca unos 470Kb/s q en realidad esa el la velocidad real q alcanzo, asi q no me fio de la velocidad q pueda marcar el IE, firefox, etc.

A mi me bajo de 500 en windows a 490 en linux acercandose asi un poco mas a la realidad, pero aun asi lo tuyo es mucha diferencia, mira con algun monitor de rendimiento, yo uso suse pero supongo q ubuntu tenga algo parecido.

Haz calculos, Calcula cuanto tarda lo q estas bajando a esa velocidad en windows y cuando termine de bajar comprueba q tarde eso y no mas, y lo mismo en linux, asi comprobaras si lo q marca por lo menos se acerca un poco a la realidad.

Saludos.

BocaDePez
BocaDePez

He mirado el monitor de red para ver la descarga real, tanto en Ubuntu como en Windows. Es definitivo, en Ubuntu la descarga es mucho más lenta (entre 100 y 150 KBytes/seg mas lenta). Como ya digo actualicé el MTU en Ubuntu pero no sirvió de nada.

Si alguno de vosotros usa Ubuntu y Windows le agradecería que hiciera la prueba también. No he hecho ningun cambio drastico en las configuraciones de Ubuntu (salvo lo del MTU que no mejoró nada), me he asegurado de que no haya ningun programa consumiendo ancho de banda (el monitor de red antes de la descarga marca o 0 o muy pocos Bytes por seg que seran de dialogo con el router), he probado la misma descarga en tandas de 5 o 6 veces en distintos horarios y siempre supera la velocidad de Windows a la de Ubuntu en 100 o 150 KBytes... La verdad no se que puede ser pero para mi Ubuntu pierde muchos puntos por este tema, son muchos KBytes/seg menos que Windows.

Si sabeis a que puede deberse o teneis la amabilidad de hacer también vosotros la prueba os lo agradezco. Una buena descarga para probar es la HTTP de ONO en la siguente dirección: http://www.corie.onored.com/
Pinchad con boton derecho sobre el enlace de 100 MB y dadle a "Save link as..."

A ver que resultados teneis vosotros, si os pasa igual el problema está en Ubuntu y no estaría de más que los desarrolladores contemplaran una solución.

Un saludo y muchas gracias.

🗨️ 2
BocaDePez
BocaDePez

No uso habitualmente Ubuntu, pero tengo una Kubuntu instalada y he realizado la prueba esa, y otras cuantas. Además de no ir peor, casi va mejor con Kubuntu.

Lo que indica el amigo Frankie2004 también es interesante, pero no se obtienen resultados que merezcan la pena (al menos no los veo obvios).

Así pues, deberías empezar por hacer las pruebas con una Live de otra distro, por que me da la impresión de que pueda ser cosa del driver de la tarjeta, es decir, que no te esté instalando el adecuado, o tengas alguna regla de iptables que te esté fastidiando ( no lo creo, pero bueno, algo será ).

🗨️ 1
BocaDePez
BocaDePez

Muchas gracias, localizo pues la fuente del problema en un tema de configuracion. La verdad no he tocado nada, el driver lo puso solo Ubuntu y el iptables no tiene ninguna regla extraña que filtre ningun tipo de tráfico.

En fin, seguiré indagando. Gracias por hacer la prueba.

Un saludo.