Cortes nocturnos FFTH Askey RTF3505VW

[Haru Ijima]

Buenos días,

tengo una línea con 50Mb simétricos, por la mañana va perfecta, hasta con 8 equipos a la vez conectados, pero es llegar la noche (con sólo 1 equipo conectado) configurado para hacer copias de seguridad en la nube, y se corta la conexión, hay mañanas que hasta amanecemos en casa sin teléfono, aunque el router dice que hay conexión (ni Internet ni teléfono).

He estado haciendo pruebas, y limitando la subida de las copias de seguridad (a partir de 4098Kb/s empiezan los cortes), deja de sufrir cortes, pero no estoy conforme, ya que siendo simétricos, debería de subir archivos sin problema y sin limitación alguna de la subida, igual que al descargarlos no sufre ningún corte.

Información adicional: QoS está deshabilitado, y la temperatura del router no excede los 30ºC.

Gracias.

[JuanC-Movistar]

Buenos dias Haru Ijima, pásame por privado el nº de teléfono, nif del titular y reviso el circuito. Deja el router encendido.

Saludos.

[Theliel]

La velocidad es simétrica, pero dependiendo de diferentes condiciones/factores, la subida puede tirar la conexión entera. No digo que sea este el problema, pero si limitando la velocidad dices que funciona, muy posiblemente lo sea.

Este fenómeno se conoce como bufferbloat, y las líneas son muchísimo mas sensibles a él en el canal de subida, debido a que siempre es más limitado que el de descarga, debido alas ventanas de recepción que se usan... explicado a groso modo:

Cuanto más cerca está la subida o la bajada de su límite (mucho más visible en subida), el Router quiera o no quiera sufre de saturación en los buffer, que se van llenando más rápido de lo que puede dar salida/entrada a la información. Eso produce retrasos en la información que estás enviando/recibiendo, y por sí mismo no es demasiado malo, el problema es que si ese retraso es indiscriminado y no se prioriza de ningún modo porque se "fija" (prevalece) la velocidad, el retraso afecta igualmente a paquetes de control como TCP SYN SYN/ACK, e incluso a los paquetes de control PADI/PADO de la conexión PPPoE, que la mantienen activa.

Si dichos paquetes no llegan al otro lado en un tiempo razonable, pasan cosas feas. En caso de conexiones TCP, los paquetes SYN SYN/ACK son esenciales, el emisor al no obtener confirmación supondría que la información no ha llegado y procedería a volver a enviar el paquete con lo que la saturación empeoraría incluso. También afecta a como se escala la ventana de recepción... a todo. En conexiones UDP casi peor, se perderían paquetes, aunque con suerte la conexión no se caería. Y para colmo de males, si la saturación es grande, incluso puede saltar la conexión PPPoE por timeout, el juniper al otro lado o tu propio Router al no recibir en el tiempo estimado los paquetes que mantienen la conexión abierta, cerrarían la conexión por timeout.

Este problema es común a muchos, sobre todos a los que usamos de forma importante el canal de subida. Y sí, en caso de que este sea el problema claro que hay soluciones. Precisamente la mejor solución y más efectiva es usar QoS. Sin QoS, digamos que el Router se preocupa de sacar el tráfico a la velocidad que pueda, sin importar como afecte a todo lo demás, y los retrasos que produce esto mata la conexión. QoS prioriza, y gestiona infinitamente mejor todo ello. QoS bien configurado, en tu caso priorizaría como es natural cualquier paquete de control sobre cualquier otro, incluso subidas/descargas casi de cualquier tipo excepto la de la subida gorda, de este modo a efectos prácticos, en el peor de los casos de picos que producen las saturaciones, la velocidad de subida se ponderaría de forma dinámica, porque ese tráfico tendría menos prioridad. Sin QoS, un simple pico puede tirarte la conexión, con QoS puedes tener una velocidad media (no máxima) muy similar, pero todo suave como el culito de un niño, hasta el punto que puedes estar con las copias de seguridad a cualquier hora del día, y ningún equipo notar un decremento en el rendimiento de la red en un uso normal, y simplemente las copias de seguridad posiblemente tardarían algo más, siendo ese algo más obviamente dependiendo del uso intenso (o no) que se haga de la red en cada momento.

El como configurar correctamente QoS para cada necesidad particular, es otra cuestión, porque precisamente tiene ese... "problema", que cada persona requiere generalmente necesidades muy diferentes. Mis ajustes QoS seguro que no serían buenos para ti, al igual que si configurases QoS de forma efectiva en tu Router, no serían buenos para mi.

[JuanC-Movistar]

Buenos dias Haru Ijima, he revisado todo el circuito y está todo configurado correctamente. Como comentas, tu conexión funciona correctamente, el problema te viene por la saturación del buffer de subida. Como muy bien ha explicado Theliel, el canal de subida es más sensible que el de bajada y la forma en que puedes solucionarlo es configurarte el QoS de la forma que mejor se ajuste a tus necesidades.

Saludos. 

[Haru Ijima]

Entiendo...

Lo que me parece un poco extraño, más si cabe, es que, probando a subir un archivo de bastantes gigas a Mega, va al máximo de velocidad de subida, y en 30 min no se corta, pero es programar el backup y a los 10 min se colapsa todo, estoy empezando a pensar que el Cloud Sync de Synology está haciendo más estragos que una simple subida a Mega o incluso Dropbox (ambas a máxima velocidad)

[JuanC-Movistar]

Parece evidente que algo hace que lo satura; te dejo el hilo abierto a ver si alguien que tenga ese equipo puede aportarte algo más de luz.

Saludos.

[Haru Ijima]

JuanC-Movistar escribió:

Parece evidente que algo hace que lo satura; te dejo el hilo abierto a ver si alguien que tenga ese equipo puede aportarte algo más de luz.

Saludos.

---

¡Ok! Gracias.

Saludos.

[Theliel]

Buenas @Haru Ijima

Es mucho más habitual de lo que imaginas, cada aplicación se diseña/programa de muchas formas diversas. Algunas pueden hacer uso de algunos sistemas propios que podríamos verlos como QoS.  Otras por ejemplo, sólo con el pensamiento de hacer transferencias a lo bruto, fuerzan al límite las conexiones. Los clientes FTP por ejemplo, por regla general les pasa lo mismo, habitualmente se preocupan más en que en los benchmark aparezcan como los más rápidos transfiriendo que suelen matar las conexiones.

[Haru Ijima]

Buenas @Theliel

Sí, lo de los clientes FTP lo sabía, pero que una aplicación tipo Dropbox funcione así... a otra gente le va de maravilla con la misma versión de la app y DSM, sí es verdad, que al único que conozco de primera mano, que le va genial, es porque eliminó el router de su compañía, dejó el ONT y lo conectó a un Mikrotik, que, siendo una versión profesional, gestionará mejor las conexiones, me imagino.

[Theliel]

El router es importantísimo, pero no porque gestione mejor/peor las conexiones. Realmente depende mucho más por ejemplo del algoritmo que usen para la congestión TCP (Cubic para el ASKEY que es actualmente el que por defecto hay en Linux desde hace tiempo), si usa o no usa algún tipo de QoS y otros... ese tipo de cosas si influye enormemente.

Sobre que los amigos de Dropbox lo hagan así... bueno, es que los programadores (y no los estoy defendiendo) tienes que optar por un compromiso entre prestaciones/rendimiento/... hay mil formas de implementar algo, y a veces el problema sólo aparece cuando sumas A+B+C+D. Otras veces por supuesto claro que es culpa totalmente de los programadores que se preocupan más de quedar bien que en hacer su trabajo.

Te diría que configurases QoS, pero puede ser una tarea complicada en el ASKEY. Siempre he dicho qeu es una de las tareas pendientes que tengo, hacer un manual muy a lo groso para el ASKEY sobre QoS

[Haru Ijima]

Pues sí, me gustaría configurar QoS pero ya veo que es algo tedioso en el Askey...