¿Por qué la discrepancia entre Speedtest y Wget?


18

Mi cliente se queja de bajas velocidades de internet. Cuando se mide con Speedtest.net, las velocidades son aceptables. Las descargas medidas periódicas son del 10% al 30% de la velocidad nominal. No puedo explicar eso.

Algunos antecedentes. La conexión problemática se encuentra en una de esas soleadas islas del Caribe donde Internet rápido no es el mayor activo. Últimamente las velocidades de internet se volvieron decentes, hasta 200 Mbps. Pero el viaje de ida y vuelta a (por ejemplo) Amsterdam es de aproximadamente 180 ms.

El cliente tiene una conexión de fibra de 100 Mbps. Al realizar una prueba de velocidad en una máquina Windows (speedtest.net) al ISP CO obtenemos 95 Mbps. Cuando usamos la misma prueba de velocidad en Amsterdam, alcanzamos 60-70 Mbs. Totalmente aceptable

Hace algún tiempo instalé un RasPi que periódicamente actualiza un archivo de uno de mis servidores en Amsterdam. En un centro de datos, que está directamente conectado a AMS-IX. Usando este comando:

wget -O /dev/null --report-speed=bits http://aserv.example.net/~myuser/links/M77232917.txt

El archivo .txt tiene 23 MByte de números. (En realidad, es el primer pero más grande Mersenne Prime, 23e6 dígitos)

Cuando descargo ese archivo en la red problemática, wget informa esto:

dev/null 100%[====================================================================>]  22.81M  11.6Mb/s   in 17s    

2019-02-08 14:27:55 (11.2 Mb/s) - ‘/dev/null’ saved [23923322/23923322]

Es decir, al mismo tiempo, speedtest.net reporta 60-70 Mbps.

Sé que el Raspi tiene sus limitaciones. Pero esta velocidad varía enormemente. Una vez, el RasPi reporta estos 11 Mbps, la próxima vez 22 Mbps. Pero a veces tan bajo como 1.5 Mbps.

ingrese la descripción de la imagen aquí

Cuando hago esta prueba con una computadora portátil realmente potente, las velocidades máximas son algo más altas (hasta 30 Mbps), pero también muestran los mismos mínimos. Por lo tanto, indica una limitación de RasPi en el lado alto, pero no los 10 Mbps en el lado bajo.

Emití exactamente el mismo comando desde un servidor en München, Alemania, en un centro de datos. Velocidad 96 Mbps.

Luego, desde una conexión de fibra de consumo de 100 Mbps en los Países Bajos: 65 Mbps.

Luego, en mi casa que tiene ADSL nominal de 10 Mbps. Speedtest muestra 10Mbps. Wget da 8.5 Mbps. Lo cual es igual en mi libro.

Esto excluye cualquier limitación en el servidor que actúa como host para la descarga del archivo.

No espero que nadie pueda señalar la causa de la lentitud de la conexión en las instalaciones del cliente. Pero, ¿alguien puede explicar la discrepancia entre speedtest.net y wget?

¿Hay algo que la velocidad más rápida ignora, o mide solo los picos? ¿O está wget seriamente influenciado por largos tiempos de ping?

Siento que la prueba de wget proporciona la velocidad real y efectiva, mientras que speedtest es principalmente para mostrar la velocidad anunciada.


Otra forma de verificar la velocidad es hacerlo ssh personal-server cat /dev/zero | pv > /dev/null, en un servidor personal que usted sabe que no está limitado a una velocidad menor que la velocidad que espera.
JoL

Leí tu pregunta. Y parece que tiene un gran ancho de banda y tal vez un escenario de retraso de ida y vuelta significativo también conocido como "red larga y gruesa". Experimenté este tipo de cosas personalmente y lo resolví abriendo muchas conexiones (usé rsync). ¿Puedes intentar abrir muchas instancias de wget (prueba 5, 10, 20)? La página de Wikipedia es: producto de retraso de ancho de banda.
Trevor Boyd Smith

Wget informa en bytes de forma predeterminada: [james @ lamia root] $ wget -O / dev / null 10.32.48.1/t1 / dev / null 100% [================= ====>] 100.00M 112MB / s en 0.9s [james @ lamia root] $ wget --report-speed = bits -O / dev / null 10.32.48.1/t1 / dev / null 100% [=== ==================>] 100.00M 932Mb / s en 0.9s
james

Considere ejecutar un servidor iperf para tcp y un segundo para udp en su máquina alojada en DC. Luego, como parte del trabajo cron, llame a una prueba de su cliente y vea cómo se comparan las velocidades con la http.
Criggie

¿Qué tipo de archivo es de todos modos? ¿Es compresible y el servidor admite la compresión http? Si bien no puede solucionar los problemas de ancho de banda, puede hacer que el archivo sea más pequeño.
Salman A

Respuestas:


16

Además de las otras razones publicadas, las conexiones TCP no funcionan bien con archivos grandes cuando el producto de retraso de ancho de banda se vuelve grande.

Como en una conexión de otra manera rápida a una isla.

Vea la entrada de Wikipedia sobre la sintonización TCP .

Entonces Speedtest puede volcar un archivo pequeño a través de la conexión a 95 mb / seg, pero wgetsolo puede obtener 10 mb / seg en un archivo de 20 MB.


2
Este es un nuevo conocimiento para mí. Muy bien. De hecho, el producto de retraso de ancho de banda es alto (2,25 MB si calculé correctamente). Un vistazo rápido mostró un búfer predeterminado de 87kB y un máximo de 3.5 MB. (Asumo Byte, no bits). Tengo que profundizar más en esto para evaluarlo mejor. Si, en combinación speedtest, descarga muchos archivos pequeños y registra la velocidad máxima, eso explica mucho.
Hans Linkels

21

Los ISP a menudo priorizan el tráfico a speedtest.net para que puedan presumir de lo rápido que son sus conexiones, mientras que en realidad no proporcionan tanto ancho de banda. Son perfectamente conscientes de que la mayoría de los usuarios solo verificarán ese sitio para confirmarlo.

También debe tener en cuenta que la velocidad de transferencia depende tanto del cliente como del servidor. En el mundo actual, la mayoría de los servidores funcionan de una forma u otra.

Finalmente, no tiene sentido esperar un ancho de banda estable para conexiones en el extranjero. Simplemente no hay tal cosa. Tiene que pasar por un número infinito de interruptores, fibras, centros de datos para llegar a la ubicación final. Y todo lo que se necesita es solo una parte móvil para reducir la velocidad.


Entiendo sus declaraciones, excepto por la limitación en el lado del servidor. Es mi propio servidor, y cuando el cliente está en un centro de datos diferente (a unos 1200 km de distancia) la velocidad es de 95 Mbps. Incluso si el cliente tiene una conexión de consumidor de 100 Mb, es de 65 Mbps.
Hans Linkels

9
¿Puedes documentar tu reclamo? "Los ISP a menudo priorizan el tráfico en speedtest.net"
Soleil

1
@Soleil no tomó demasiado googlear: myce.com/news/…
MonkeyZeus

66
Un ISP que prioriza el tráfico más rápido es tan probable como un fabricante de automóviles que falsifica pruebas de emisiones.
Barmar

3
Como anécdota, una vez pude 'arreglar' una secuencia tartamudeante del Super Bowl enviando tráfico a speedtest.net repetidamente desde una Raspberry Pi. Parecía que priorizaban toda mi conexión siempre que hubiera el tráfico más rápido presente - diferencia de día y noche. No es mucha evidencia de que los ISP hacen cosas sospechosas, pero es algo.
Deshacer

7

wgetdar una buena medida práctica de la velocidad. Las pruebas de Speedtest probablemente incluyen algún tipo de paralelismo que puede explicar números más altos.

Para una buena prueba de velocidad promedio, creo que el tiempo de descarga debe ser de al menos 90-120 segundos (para obtener un buen promedio)


Estoy trabajando para instalar una computadora de registro más potente y para aumentar el tamaño del archivo.
Hans Linkels

¿Se puede desarrollar "tipo de paralelismo"? No veo ninguna forma / razón ya que hay una conexión a priori 1.
Soleil

1
@Soleil, en mi humilde opinión, descargan pocos archivos, no solo uno. Puedes probarlo corriendo pocos wgety sumando la velocidad
Romeo Ninov

1
Podría paralelizar mi medición, pero ¿cuál es el beneficio? Ya demostré que otros clientes alcanzan la velocidad máxima. La diferencia es que la conexión problemática tiene una latencia de 180 ms. Las conexiones rápidas <10 ms. ¿Disminuirían paralelamente los efectos de latencia? Sólo preguntaba.
Hans Linkels

1
@RomeoNinov Lo comprobé, no existe tal paralelismo (speedtest.net). Un archivo por carga y uno por descarga ([1-2] MB cada uno).
Soleil

3

Una razón podría ser que a menudo no se puede alcanzar la velocidad máxima con una sola conexión TCP.

Speedtest.net introdujo recientemente un modo de conexión único. Pruebe esto y vea si hace la diferencia.

Luego, para la descarga, use, por ejemplo, aria2 con parámetros para usar múltiples conexiones y comparar. p.ejaria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt


2

Use la prueba de velocidad de Internet Fast.com , esta es una prueba de velocidad basada en Netflix, lo que significa que los ISP no pueden diferenciarla de Netflix.

Esta es una prueba más precisa que cualquier otra prueba en general. La gente no se preocupará por la rapidez con que se carga una página web, sino por la rapidez con que se almacenan los videos debido al mayor ancho de banda necesario para mostrar un video.

Los ISP a menudo aumentan las velocidades en función del dominio al que alguien se está conectando si es una prueba de velocidad o usa el puerto 8080. Mientras que Netflix usa el puerto 80, un puerto más lento cuando se le da prioridad.


1
"lo que significa que los ISP no pueden diferenciarlo de Netflix". Eso no es cierto, el ISP definitivamente puede ver tanto la solicitud DNS como el SNI en la conexión HTTPS.
Kevin

@Kevin fast.com contacta a los servidores de netflix para descargar, lo que significa que emula videos de netflix. Aunque le concederé que los ISP pueden comprender el hecho de que conectarse a ese sitio específico que posteriormente se contacta con servidores basados ​​en Netflix requiere una priorización similar a speedtest.net
Jonathan

No es exactamente ciencia espacial. Todo lo que tienen que hacer es desacelerar Netflix durante unos minutos u horas después de que vean una conexión fast.com. Lo bueno, por supuesto, es que puedes ir a fast.com para liberarte, luego cerrar la pestaña y ver Netflix de verdad.
Kevin

Personalmente sospecho que es ciencia de la computación o al menos está relacionada con ella en lugar de ciencia espacial. Parece que algunos de los ISP más grandes (por ejemplo, Bell) no se han adherido a fast.com en los últimos años. De cualquier manera, ejecutar un script en su computadora que se conecte a fast.com para aumentar su velocidad de descarga cada cierto tiempo si la aceleración es lo suficientemente mala, sería viable.
Jonathan

0

¿Soy yo o nadie se dio cuenta de que dijo Mbps y la lista de comandos wget "MB / s".

60mbp / sy obtener 11.2Mb es normal.

Mbps y MB / s son dos velocidades diferentes.

"un Megabit es 1/8 tan grande como un Megabyte, lo que significa que para descargar un archivo de 1 MB en 1 segundo necesitaría una conexión de 8 Mbps". Entonces 11mbx8 = 88mbps ... 11.2Mb es realmente bueno para un informe de conexión 60-70mbps.

¿Las personas que tienen memoria pierden esto? Nunca obtendrá 70mb / s con una velocidad máxima de 70Mbps


La salida de wgetes Mb / s que se traduce en Megabits / s . MB / s se traduciría a MegaBytes / s . Simplemente ejecute su propio wgetcomando y verifique el resultado.
Thomas

1
@james: Sí de forma predeterminada, pero en OP el wgetcomando incluye --report-speed=bitsqué resultados en Mb/scuál es Mbit/s. Correr sin --report-speed=bitsda lo MB/sque se traduce en MByte/s. Tenga en cuenta la by B.
Thomas
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.