El Martes, 18 de Enero de 2005 06:21, Paco Tirado escribió:
Hola a tod@s, me acabo de instalar SuSE 9.2 y he notado que la velocidad de internet fluctua entre 374 Kbps y 570 Kbps.
Realizando las medidas de velocidad mediante la página www.cliente33.es.tdatacenter.com en Knoppix 3.7 me ronda los 570 Kbps.
Tengo conexión con cable a 600 Kbps y no había tenido este problema con
Suse 9.0 ni 9.1
Esos tests o pruebas de comprobación de velocidad no son muy "reales". Para poder comprobar realmente la velocidad de tu conexión, habría que hacer varios tipos de pruebas. Por ejemplo: - subirte 200 MBytes en paquetes grandes en distintos lugares, como Alemania, Noruega, China, México, etc. - volverte a subirte 200 MBytes en paquetes pequeños desde los mismos lugares. Con esos datos podrías hallar una media más realista de las posibilidades de tu conexión. Lo realmente importante es el rendimiento (media de velocidad) de la conexión, no la velocidad puntual en un momento determinado. Cuando hago comprobaciones de velocidad con alguna página de esas que miden la velocidad, los resultados suelen ser más bajos de los esperados, a veces más altos, y existe mucha diferencia según conectes con unas u otras, lo que significa que no sirven para casi nada esas comprobaciones. Por ejemplo, con esas comprobaciones me da una velocidad, pero cuando me bajo desde la línea de comandos con el wget alguna página como por ejemplo la de LuCAS, va que VUELA. Mi conexión por cable es teóricamente de 600, pero lo veo bajar a 700 en línea de comandos. Lo realmente importante es el rendimiento medio, no la velocidad "actual". Bueno, y por aquí encuentro unos apuntes que tomé en la escuela de nuestro compañero de lista "jose maría" (bcn) (Si hay algún error será que no tomé bien los apuntes): Para mejorar el rendimiento se debe ECUALIZAR la línea (reducir un poco el ancho de banda de nuestra tarjeta de red, la que hace de salida/entrada desde nuestro ordenador al exterior, supongamos que sea la eth0), que significa CALIDAD DE SERVICIO (QoS). Se deben evitar colapsos en el canal de subida (UP_STRING), y reservar unos kbytes para otras cosas (por ejemplo, para el router; por ejemplo, para la conexión ssh...). De este modo se evitan los colapsos, porque lo realmente importante es el rendimiento, no la velocidad punta en un momento determinado. Imagínate una cañería por la que circula el agua, déjale entonces algo de respiro. Para la comprobación del rendimiento: 1º) Enviamos pequeños paquetes, por ejemplo de 100 Kbytes, unos 1000, y vemos el tiempo que tardan, y tomamos notas (cronómetro en mano). 2º) Después ficheros grandes, por ejemplo de 50 Mbytes, y hacemos lo mismo. Pues bien, esto nos dará el ancho de banda medio que tenemos, porque la velocidad de la propia interfaz es una medida falsa. FORMULACIÓN =ANCHO DE BANDA MEDIO QUE TENGO VELOCIDAD DE LA PROPIA INTERFAZ=FALSO. Como no lo vamos a hacer, más sencillo es que si disponemos de una conexión de 256, ponemos por ejemplo 250 y cuando veamos que todo va bien podemos subirlo por ejemplo a 251, 252, pero vale... El interfaz que vamos a ecualizar, será eth0, nuestra tarjeta de red de salida/entrada hacia/desde el exterior. [En el interno no tiene sentido ecualizar, ya que las tarjetas de red tienen una velocidad considerable: TdRed=>100Mybtes] eth0,250 251 252 ====== vale Eso es el CAUDAL DE SUBIDA, la BAJADA no se puede ecualizar. Pero con con IP_TABLES, sí lo podríamos hacer (el ecualizar la bajada). No depende de nosotros, del servidor que está sirviendo. En IPv6 sí se puede, tanto la subida como la bajada. Sincroniza con el ISP. En linux para ecualizar la bajada, hay que cargar el módulo IMQ, lo pasa por un interfaz y lo trata como si fuera de subida. Editamos el cortafuegos: prompt:> joe /etc/sysconfig/SuSEfirewall2 Y nos vamos a la línea: FW_HTB_TUNE_DEV= FW_HTB_TUNE_DEV="eth0,252" Lo tendremos que hacer si tenemos el eDonkey Se bajan a.... 300 conexiones El nº de conexiones nos va a colapsar, 30 llamadas por segundo WONDERSHAPER = encolar, y que las cosas vayan como .... bajada IMQ ==> FW_LOG