BandaAncha.eu

Comunidad de usuarios
de fibra, móvil y ADSL

BASpeed 2018 actualizado a la versión 11.0.0.233

djnacho
4

Acabo de subir al site oficial los nuevos instaladores de BASpeed 2018 de 32 y 64 bits, específicos para dichas versiones de Windows. Los enlaces ya están cambiados y disponibles en la sección de descargas de este site oficial.

Se aconseja a todos los usuarios que si disponen de una versión de 64 bits de Windows, instalen la versión de 64 bits de BASpeed 2018, ya que está compilada específicamente para dicha versión de Windows.

¡¡Nota importante!!: Antes de realizar la instalación con los nuevos instaladores, desinstalar la versión previa de BASpeed 2018. Es importante para que no haya dos entradas en el menú inicio con el mismo nombre.

Aparte de este cambio, que ya estaba anunciado hace mucho tiempo, hay otros más sutiles que paso a comentar brevemente:

  • Se ha corregido el menú contextual del icono de la aplicación en la bandeja del sistema, añadiendo aquellas opciones que por olvido habían quedado sin añadir en la versión anterior.
  • Se ha actualizado el test de velocidad para que pueda visualizarse correctamente aunque el usuario aumente la escala de visualización de Windows. Antes la aplicación cortaba los bordes de la aplicación y no se podía abrir la sección de información ampliada. Ahora esto no ocurre.
  • Se han actualizado las librerías OpenSSL, de forma que ahora el test de bandaancha.eu, que se ejecuta sobre SSL funciona correctamente.

Un saludo a todos y que lo disfrutéis 😉

Espero que esos cambios os gusten y sean de vuestro agrado. La función de auto-actualización de momento ha desaparecido, pero está previsto que regrese en una próxima revisión de la suite 😉

quilloquepasa
2

Que máquina eres.

Un abrazo.

🗨️ 5
djnacho

Ojalá fuera un máquina de verdad 😜
Sólo soy una persona que intenta dedicar todo el tiempo que puede a su pasión que es programar. Ya sabéis que no puedo dedicarme tanto como antes, pero intento dedicar tanto tiempo como buenamente puedo.

Un saludo enorme quillo 😊

🗨️ 4
BocaDePez
BocaDePez
-1
🗨️ 3
djnacho
🗨️ 2
Usuario Ah

Gracias y enhorabuena por todo tu trabajo.

Una duda: en el Optimizador de Internet V8, veo que, en los datos calculados por éste (que aparecen abajo, a la izquierda), el valor de Unscaled RWIN es el resultado del producto MSS por un factor variable según el MTU (44 para MTU=1500; 45 para MTU=1492; y así va aumentando conforme disminuye el valor de MTU o MSS=MTU-40).

Según las optimizaciones propuestas por Speedguide.net (a la que se alude en los créditos del optimizador) el valor de Unscaled RWIN debería ser el resultado del producto MSS*44 (MSS por un factor fijo de 44), a partir del cual se escalará este valor en función de la velocidad y latencia máximas de conexión (lo que bien hace el programa).

Así que, ¿es incorrecto el valor de la ventana RWIN sin escalar que da el optimizador? Y, por tanto, el resto de valores obtenidos ¿O no he entendido yo bien el cálculo de este parámetro (mi nivel es de usuario)?

¿Sería acertada una opción manual para la ventana "Datos calculados por el optimizador TCP"?

Espero no haberte hecho perder tu tiempo.

Gracias,

🗨️ 1
djnacho

Hola y ante todo no me haces perder nada de tiempo, faltaría mas.

La verdad es que para calcular el RWIN se aplican los cálculos que dan en este enlace de speedguide.net.

Si ves los cálculos, no es tan sencillo. Te paso a explicar un poco los pasos para que los entiendas:

  1. Hay que averiguar antes de nada, el MSS (normalmente 1460, ya que es MTU-40 o sea 1500-40=1460), la latencia máxima esperada (antes con ADSL era de 300 ms pero en mi versión del optimizador lo bajé a 150 ms porque no era necesario un valor tan alto), y el ancho de banda máximo de la conexión.
  2. Hay que averiguar el RWIN "no escalado" (unscaled RWIN). Para ello se divide 65535 entre MSS para encontrar el valor del múltiplo más pequeño de MSS. Esto da un valor de 44.9 que se redondea hacia abajo hasta 44. Se multiplica el MSS por este valor (44) para hallar el valor del RWIN "no escalado" (64240 es el valor que da).
  3. Ahora hay que hallar el valor del BDP (Bandwith*Delay Product o Producto entre Ancho de banda y latencia). Supongamos una conexión de 100 Mbps con una latencia de 150 ms como máximo. El BDP es 100000 Kbps * 150 ms = 15000000 bits o expresado en bytes, 15000000 / 8 = 1875000 bytes. Este es el BDP de esa conexión en concreto. El RWIN se calcula multiplicando por 2 el RWIN no escalado hasta el que aparezca el primer valor superior al BDP. En nuestro caso 64240*2*2*2*2*2=2.055.680 bytes. Este último si es el valor del RWIN optimizado para esa conexión que es el valor que el optimizador calcula y prepara para ser escrito en el registro de Windows.

¿es incorrecto el valor de la ventana RWIN sin escalar que da el optimizador?

Como ya te he explicado en el punto 2 del cálculo, el valor del RWIN sin escalar no es incorrecto ya que se calcula siempre igual sea cual sea la conexión.

Y, por tanto, el resto de valores obtenidos

Como también he explicado en el cálculo, como el RWIN sin escalar se puede decir que es casi una constante es todas las conexiones, el resto de valores dependen de los cálculos efectuados en el punto 3 (los cuales ya no dependen del RWIN sin escalar, sino de la latencia máxima esperada y de la velocidad de la conexión).

¿Sería acertada una opción manual para la ventana "Datos calculados por el optimizador TCP"?

El valor calculado por el optimizador es el valor óptimo para esa conexión. No tendría sentido poner un valor no optimizado para una conexión de 100 Mb y que luego debido a ese valor incorrecto la velocidad que alcanzara la conexión fuera inferior a su límite teórico.

Espero haberte ayudado a comprender un poco como se optimiza en versiones anteriores de Windows (y en las nuevas si pasas de la optimización automática) las conexiones a internet. Un saludo 😊

Usuario Ah

Hola otra vez djnacho,

Naturalmente que me has ayudado, y mucho, a entender mejor la optimización manual de la conexión a internet (en mi caso el s.o. es Windows 10, pero siempre me ha gustado tener el control de los ajustes: en windows, en el calibrado de la pantalla, en la TV, en el equipo de música,… en todo). Por eso te doy de nuevo las gracias, por dedicarme un tiempo del que no sé si dispones.

He ido al enlace que me indicas y, a continuación, he seguido tus instrucciones, habiéndome surgido alguna duda:

  • Mediante cmd.exe he obtenido que mi MTU es 1492. Lo que me ratifica el Analizador de Speedguide:

« SpeedGuide.net TCP Analyzer Results »

Tested on: 2021.01.25 Client OS/browser: Windows 10 (Firefox 84.0)

TCP options:

MSS: 1452

MTU: 1492

Así que el valor del múltiplo más pequeño de MSS será: 65535/1452= 45,13 que redondeando hacía abajo será = 45. Por tanto, el valor de RWIN "no escalado" será: MSS*45= 1452*45=65340

Aquí surge mi duda, puesto que en el enlace de Speedguide.net, en el ejemplo en el paso 2, dice:

  1. Find the optimal unscaled RWIN value (largest even multiple of MSS less than 65535) (el mayor múltiplo par de MSS menor que 65535):

65535 / 1460 (MSS) = 44.9

round down to even number (redondeado a un número par) = 44

44 * 1460 (MSS) = 64240 (this is the optimal unscaled RWIN value)

Como ves, la traducción que te he pegado en la primera y tercera líneas (he utilizado Google y Deep, y los dos coinciden) habla de redondear al número par inferior. En cualquier caso, "even" también tiene otras traducciones además de "par". Como no sé que sentido puede tener que el múltiplo tenga que ser un número par (aparte del de garantizar que el valor de RWIN sea siempre un número par. No sé si esto tiene algún sentido para ti), puedo suponer que es un error de traducción, que "even number" no significa "numero par".

Vale, pero resulta que al observar los resultados de SG TCP/IP Analyzer, éste me sugiere una serie de valores para optimizar RWIN para mi "MTU/MSS actual" y estos valores son todos múltiplos de 44 (el primero, que debería ser RWIN sin escalar, es 1452*44=63888 y el resto un escalado de estos según la velocidad de conexión y la latencia). Es decir, vuelve a redondear al número par inferior=44. Te pego lo dicho:

TCP Window: 262656 (not multiple of MSS)

RWIN Scaling: 8 bits (2^8=256)

Unscaled RWIN : 1026

In Windows 10, unless "TCP/IP Auto-Tuning" is disabled, only the Current TCP Window is displayed. Use the latest TCP Optimizer for tweaking.

RWIN is not multiple of MSS. If your OS supports setting RWIN directly, consider changing it to a multiple of MSS for optimum performance.

Other RWIN values that might work well with your current MTU/MSS:

63888 (up to 2 Mbit lines, depending on latency. MSS * 44)

127776 (1-5 Mbit lines, depending on latency. MSS * 44 * 2)

255552 (2-15 Mbit lines, depending on latency. MSS * 44 * 2^2)

511104 (10-30 Mbit lines, depending on latency. MSS * 44 * 2^3)

1022208 (30-100 Mbit lines depending on latency. MSS * 44 * 2^4)

BDP limit (200ms): 10506kbps (1313KBytes/s)

BDP limit (500ms): 4202kbps (525KBytes/s)

MTU Discovery: ON

TTL: 49

Timestamps: OFF

SACKs: ON

IP ToS: 00000000 (0)

Aquí ya me pierdo. Quiero decir, que con la confusión que tengo en cuanto al valor adecuado del multiplicador (44 ó 45) por desconocer los fundamentos de este concepto (como te dije, mi nivel es de usuario), en el resto de cálculos que me indicabas después ya no sé si obtengo valores correctos o no.

Te he pegado todos los valores que me da el SG Analyzer, por si te dicen algo.

Gracias de nuevo, de verdad.

🗨️ 1
djnacho
1

Hola de nuevo. Si, en realidad se me pasó decirte que el multiplicador debe ser redondeado al número par inferior. Eso es debido a que en el RFC 7323 se especifica que el valor de la ventana de recepción de datos debe ser un número potencia de 2 (2^N, donde N<=30, aunque en la práctica el protocolo sólo permite como máximo un N de 14, es decir 1 GB), por lo que el multiplicador debe ser par (múltiplo de 2) para que se cumpla esa condición.

Puedes ver eso en el RFC 7323 - Cápitulo 2 - Página 10

Un saludo y de nada, faltaría más 😊

Usuario Ah

Hola y gracias una vez más,

Ok. Concepto aclarado. Te pongo, a continuación, los cálculos correspondientes al tercer punto que me indicas para hallar el valor de RWIN optimizado. Te agradecería que si hago mal algún cálculo o pongo algún valor que no tenga sentido, me lo digas.

Así que partimos de RWIN "no escalado" igual a MSS (1452)*44=63888.

Para calcular el BDP tengo, en mi caso, una conexión de 1.000 Mbps (1 Gb) con una latencia de 126 ms como máximo (he cogido este valor de la calculadora de TCPOptimizer, no sé si es mejor coger otro).

El BDP es 1000000 Kbps * 126 ms = 126000000 bits o expresado en bytes, 126000000 / 8 = 15750000 bytes.

El primer valor superior al BDP que resulta de multiplicar RWIN sin escalar por 2, es: 63888*2^8 (ocho veces) = 16355328

Así que el valor de RWIN optimizado es de 16.355.328 bytes. (Algo menos de 16 Mbps.)

Este es el resultado obtenido. Espero que, si te es posible, me confirmes estos cálculos o, en caso de no ser correctos o no tener sentido, me lo indiques también.

Gracias,

🗨️ 1
djnacho

Exacto, todos los cálculos son correctos 👍😊

Una cosa: Ese RWIN, si todo funciona correctamente irá ok con la conexión, pero si hay un sólo error de transmisión en los datagramas TCP, el mensaje debe reenviarse entero desde el inicio, por lo que la velocidad total bajará en picado. En condiciones normales no debería pasar nada, pero en condiciones de saturación de la conexión (por ejemplo) la velocidad se puede ver resentida y mucho por fallos de ese tipo. Esa es la explicación de que Windows, Linux y Mac tengan RWIN dinámicos en sus rutinas TCP/IP, así como rutinas anti-congestión de paquetes.

Encantado de ver a alguien que intenta aprender las interioridades de los protocolos que mueven toda la información por internet.

Un saludo 😊

Usuario Ah

Hola djnacho,

Pues sí, me encanta aprender cosas nuevas. Lo que no es tan fácil es encontrar a alguien que sea capaz de enseñártelas o se quite algo de su tiempo para ello. En plan autodidacta se hace la cosa bastante difícil, así que gracias.

Deduzco de tu comentario que sería mejor poner un valor RWIN con un escalado menor ¿2^7; 2^6; 2^5; 2^4;… ? ¿cuál? Veo, en el funcionamiento del Optimizador V8, que el factor de escalado aumenta al aumentar la TTL (ping).

También mencionas que los sistemas operativos tienen RWIN dinámicos en sus rutinas TCP/IP y rutinas anti-congestión de paquetes. Esto quiere decir que Windows, como siempre, hace lo que quiere y no tiene mucho sentido una optimización manual, o sí tienen una incidencia real, los parámetros que modifiquemos, en el comportamiento de estas rutinas.

Por cierto, no sé si será factible trasladar a dicho Optimizador V8, lo de "redondear el multiplicador al número PAR inferior" en el cálculo de Unscaled RWIN. Ahora, el multiplicador toma el valor de 45, por lo que en ningún caso da 63888, que es el valor que vimos que era el adecuado para MTU=1492 (MSS=1452).

Gracias, como siempre, y un abrazo,

Usuario Ah

Disculpa djnacho, se me ha olvidado poner interrogaciones en un párrafo y no sé si se entiende que es una pregunta. Te lo pego con las interrogaciones puestas:

También mencionas que los sistemas operativos tienen RWIN dinámicos en sus rutinas TCP/IP y rutinas anti-congestión de paquetes ¿Esto quiere decir que Windows, como siempre, hace lo que quiere y no tiene mucho sentido una optimización manual? ¿o sí tienen una incidencia real, los parámetros que modifiquemos, en el comportamiento de estas rutinas?

Creo que ahora se entiende mejor.

Un saludo,

🗨️ 1
djnacho

A ver voy a intentar explicarme. Cuando digo que Windows (y Linux y Mac) tienen un RWIN dinámico, quiero decir que el Sistema Operativo (independientemente de cual sea) pone el sólo y sin necesidad de intervención del usuario (al contrario de lo que ocurría con Windows XP y anteriores) los valores adecuados para RWIN y demás parámetros de la conexión. La forma de hacerlo, varía según el sistema operativo pero una "idea" sería detectar el tipo de tarjeta de red existente, con lo que la velocidad máxima ya la tienes por que te la da el controlador de la misma. A partir de ahí se va bajando el RWIN automáticamente, hasta que haya pérdida de datagramas con lo que indicaría que se ha llegado al RWIN óptimo (ojo, no me he mirado el código interno de ningún S.O., es una idea a bote pronto de como lo podrían hacer).

Por lo tanto ¿Tiene sentido una optimización manual? … Eso depende del usuario. Normalmente, no se necesita. Ya te digo que es el propio sistema el que se encarga de optimizar el RWIN.

¿Si modifico el RWIN por mi cuenta, tiene repercusión en las rutinas internas del SO? Pues si, porque ya de primeras el optimizador de BASpeed (al igual que hace el TCP Optimizer de SpeedGuide.net) deshabilita el RWIN automático (se puede ver aquí, pero la orden real para el sistema es netsh interface tcp set global autotuning=disabled). A partir de ahí se modifican los apartados necesarios del registro de Windows. Y cuando deshabilitas el TCP/IP auto-tuning (el RWIN automático), sólo funcionan las rutinas básicas del sistema TCP/IP que ya existían en Windows XP, por lo que en teoría no funciona el descubrimiento automático del MTU, las rutinas de congestión, etc, etc.

Un saludo 😊

Usuario Ah

Ok. Creo que lo has explicado perfectamente o, al menos, lo suficientemente sencillo para que lo entienda yo.

Como usuario, sigo siendo partidario de los ajustes manuales o personalizados, aunque, como dices, no sean necesarios, o imprescindibles.

De los otros dos puntos que te mencionaba (respecto a que escalado de RWIN aconsejas para no tener problemas y el caso de MTU=1492 en el optimizador de BASpeed) ¿me puedes decir algo?

Gracias y saludos,

🗨️ 1
djnacho

Respecto al RWIN, te aconsejo el valor que te ofrezca el cálculo del optimizador de BASpeed, o bien el de TCP Optimizer, que serán prácticamente iguales.

Y respecto al optimizador, el valor creo que lo coge redondeando al número inmediatamente inferior. No es correcto, ya que el optimizador debería redondear el número par inmediatamente inferior. Pero el optimizador es algo que no puedo cambiar, no porque no pueda sino porque por un accidente hace mucho tiempo perdí todo el código fuente y no tengo manera de poder corregir el programa original. Quizás creando otro programa, pero el cálculo es tan aproximado al valor correcto que no merece la pena crear una nueva aplicación. Se que es algo "imperdonable" perder el código fuente de una de mis aplicaciones pero eso ocurrió antes de que tomara medidas para que algo como eso no volviera a ocurrir.

Un saludo y perdona el "fallo" que contiene el optimizador (aunque ya te digo que el resultado final se aproxima muy mucho al valor óptimo) 😊

Usuario Ah

Nada que perdonar. Bastante haces con dedicar tu tiempo a los demás sin pedir nada a cambio. Entiendo que es tu pasión, pero sigue siendo algo de lo que nos beneficiamos todos.

Lo que si tiene que sentar mal es lo de perder el código fuente (tu trabajo), pero ya no tiene remedio, así que tienes mis mejores deseos para tus siguientes proyectos.

Siempre gracias,

🗨️ 1
djnacho

Pues acabo de ver por santísima casualidad una versión antigua del optimizador (la que funcionaba en BASpeed v6 que luego fue utilizada en BASpeed v7). Es justo la versión anterior y se podría modificar para corregir los errores que has visto en el cálculo del multiplicador del RWIN. Lo iré haciendo en mis ratos libres, y ya os iré contando 👍😊

Usuario Ah

Enhorabuena!

Es una gran noticia. Sobre todo, como te decía antes, por recuperar tu trabajo.

Ya nos dirás,