BandaAncha.eu

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

Pregunta sobre Conexión Futura y DSLAMs de Jazztel

Frankie2004

Hola Luke,

He puesto este mensaje en el foro de Jazztel por si no te pillo en el de Otros ISP. Si lo estimas conveniente, podrías moverlo allí una vez respondido.

Como sabrás, Conexión Futura utiliza los DSLAM de Jazztel para encauzar el tráfico ATM de los usuarios hasta sus propias instalaciones, para después salir hacia Internet con TeleGlobe o con EasyNet, con muy buenas conexiones y latencias, por cierto.

Sin embargo, creo que se ha visto envuelto en todos los mismos líos que ha tenido Jazztel, desde los retrasos en las altas hasta las ampliaciones de caudal de 1 a 4 Mbps, que han sucedido solo hace un par de días, como también sabrás.

Acabo de estar en casa de un amigo con 4 Mbps en CF y hemos estado haciendo muchas pruebas, que nos han dejado sorprendidos y pensativos ... porque si todos los líos que hemos tenido que hacer para que fuese bien, lo tiene que hacer un usuario sin conocimientos, apaga y vámonos.

Lo primero de todo, que la velocidad parecía muy estable, siempre que no se llegase al límite. Cuando bajabas un driver de nVIDIA, como tienen ellos capadas sus descargas a 300 KB/s, pues perfecto, 300 KB/s sostenidos.

Pero cuando intentabas descargar de sitios, tenía el mísmo síntoma de los dientes de sierra del DUMeter de los hilos de Jazztel de las semanas pasadas. En cuanto llegaba a 450 KB/s, bajonazo a menos de 100 KB/s y una lenta recuperación.

Haciendo muchísimas pruebas con el tema de RWIN, vimos que los picos ocurrían cuando el MTU estaba a 1492, el supuestamente óptimo para PPPoE. Leyendo con detenimiento varios de los hilos largos, fuimos bajando hasta dejarlos en los 1478 que recomendaste en un momento dado.

Con 1480 ví que ya habían desaparecido los dientes de sierra y la conexión era estable a unos 438-440 KB/s. No hice demasiadas pruebas intermedias. Con MTU de 1490 los dientes de sierra volvían. Como leí tu hilo sobre los 1478, pudimos comprobar que así se conseguían unos increibles y estabilísimos 450 KB/s desde Red Iris.

Pero cambiar MTU y RWIN no es algo normal para un usuario. El router DrayTek Vigor 2600Ge que él tiene, también era bastante conservador en los valores y tiene un MTU de 1474 con los parámetros de fábrica. Lo que me ha preocupado es que con 1492 aparezcan esos picos acojonantes que asustan al verlos.

Por cierto, probamos a poner tu truco de DefaultSendWindow a 16K, pero no sé qué efecto tendrá en Azureus o similares aplicaciones. Ya era muy tarde y no me quedé a ver la evolución de las descargas.

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

Hola,

La verdad no sé qué podría causar que los picos aparecieran o no dependiendo del MTU. Sé que CF usa un modelo de router de acceso (lo que conecta el mundo atm con el ip) que no tiene problemas con colas (los que usaba jazztel antes de junio), por lo que este problema no debería manifestarse. Y de hecho con mtu adecuado no lo hace...

El problema de los picos es debido a la pérdida o descarte de paquetes. Da un poco igual dónde se produzca esta pérdida que los síntomas serán parecidos. Creo que el problema de CF debe estar en la parte IP de la red, que por alguna razón descarta paquetes de ciertos tamaños en determinadas circunstancias que no conozco... O la red IP, o el conjunto general de red, carriers, equipos cliente, servidor del que se descarga... etc. pero dudo que sea por exactamente el mismo problema que con Jazztel.

1492 es el MTU para PPPoE, pero es el MTU máximo posible, no el óptimo. El MTU óptimo para PPPoE no lo he calculado, pero debe estar en torno a los 145x. Llamo óptimo al MTU necesario para que no haya ninguna celda ATM medio vacía (con padding).

CF no usa PPPoE, sino PPPoA. Con este encapsulamiento es perfectamente posible usar MTU de 1500, que además es el MTU por defecto casi siempre, probasteis ese? Lo del defaultsendwindow con el azureus no lo vais a notar, ya que normalmente envias a muchos clientes al mismo tiempo, y este "parche" es para una única conexión. Como ejemplo, Neophyte me estaba mandando por IRC un rar, iba a unos 34kiB/s, fue decirle que aplicara el parche, reiniciar y magia, la velocidad de transferencia pasó a ser 54kiB/s constantes. Como nota, el azureus permite seleccionar este valor independientemente, en opciones es un campo que se llama SO_SNDBUF. Pero bueno esto es irrelevante :P

Creo que no me dejo nada.. :P muevo esto a Otros ISP que ahi estará mejor. Un saludo ;)

🗨️ 11
Frankie2004

Gracias por contestar tan tempranito (desde mi punto de vista y por mis horarios completamente anárquicos). Sería genial que se pudiese calcular ese MTU óptimo para PPPoE en RIMA, porque yo ni de lejos consigo 400 KB/s en casi ningún sitio, ni en Red Iris.

A ver si ahora va a merecer la pena CF o Jazztel antes que ningún otro proveedor del país. :-D

Editado: Buscando por Google, he encontrado este artículo en el que siguiendo una estrategia similar a la tuya, para completar celdas ATM sin resíduos, comenta que un MTU óptimo para líneas ADSL basadas en PPPoE sería de 1454 bytes.

🗨️ 3
Luke

A ver, hay dos posibilidades:

- Que telefónica use PPPoE-LLC nFCS, el overhead queda en:

ppp: 2 bytes
pppoe: 6 bytes
mac sin fcs: 14 bytes
rfc (LLC): 10 bytes
aal5: 8 bytes

Para que no haya padding no podemos usar 32 celdas porque éstas llevarían 1536 bytes y el tamaño total con MTU=1492 es 1492+2+6+14+10+8=1532 bytes. En 31 celdas ATM podemos llevar 1488 bytes. 1488-8-10-14-6-2= 1448 de MTU.

Rendimiento con MTU 1492: 1452 / 1696 (32 celdas 53 bytes cada una) = 85.6% de rto.
Rendimiento con MTU 1448: 1408 / 1643 = 85.7% de rto.

- Que telefónica use PPPoE-LLC FCS:

ppp: 2 bytes
pppoe: 6 bytes
mac: 18 bytes
rfc (LLC) 10 bytes
aal5: 8 bytes

Con mtu=1492 es igual, se usan 32 celdas, rendimiento 85.6%
Para 31 celdas 1488-8-10-18-6-2 = 1444. Rendimiento 1404 / 1643 = 85.5% rto.

Conclusión: yo me quedo con mtu = 1492 ya que no sabemos qué usa telefónica exactamente. Las celdas están llenas o prácticamente llenas en ambos casos, PPPoE es un protocolo con muy mal rendimiento en cualquier caso.

Info? en este pdf: (link roto)

Creo que no me he dejado nada..

edito: ese link que pones no tiene en cuenta la encapsulación LLC, telefónica usa esa, verdad?

🗨️ 2
Pishu

entonces es mejor PPPoA que PPPoE? y bueno el RFC 1483 es más estable por lo que he aprendido en el curso de formación :P

Ya que con el protocolo RFC 1483, no hay que pasar por RADIUS ninguno, y directamente te valida la IP fija que tienes y sales a Internet. Esto dará mas estabilidad en el momento en el que algun Radius pueda estar dando problemas...

Habría que configurar algun MTU específico para RFC 1483?

🗨️ 1
Luke
Luke

Prueba esta descarga, si te va bien no hace falta que toques nada:

ftp://ftp1.optonline.net/pub/test64

🗨️ 5
Pishu

oK, va de lujo... el jc net meter marca 222 224 sostenidos, aunque la descarga en el firefox la velocidad que marca son 219-220 sostenidos... es normal que haya 2-3 KB de más en la gráfica?

🗨️ 1
Luke
Frankie2004

Este es el resultado con mi línea de Ya.com de 4 MB y el supuesto MTU optimizado. Lo que me jode es que no estoy utilizando eMule. Acabo de encender el ordenador y el router después de estar apagados 9 horas.

Una media de solo 207 KB/s con los altibajos que podéis observar en la gráfica. :-(

Imagen original en http://img244.imageshack.us/img244/6771/testoptonline64mb0rl.png

Seguro que en CF iría a tope todo el rato ... joer, cada día estoy más harto de mi línea en RIMA, con lo bien que iba NURIA.

🗨️ 2
Intrad
Pishu
BocaDePez
BocaDePez

He solicitado mi alta en Conexion Futura llevo esperando 1 mes y medio y todavia no me dieron la conexion =(

Saludos.