Bufferbloat RTF8316VW (Ultimo firmware)

Hola! muchas gracias de nuevo por la explicacion de el bufferbloat, que es, cuando ocurre etc

Los test, estan hechos con QoS y sin QoS. Que pasa, que la QoS de el GE550 es automatica, y tiene priorizado el puerto de el PC que es un puerto dedicado, y luego tambien consolas. 

Cuando he hecho los test con los HGU5 Y HGU7 en modo router, la QoS que estuviera por defecto (si la trae activa) es la que estaba puesta, ya que los test los hice haciendo reset de fabrica a ambos.

Y cuando los he realizado en monopuesto y el GE550 como router, la QoS de el GE550 estaba activa (probe desactivandola y mismo resultado)

Otra cosa es, que el HGU7 tiene mejor hardware y puerto 10Gb por tanto soporta mucho mejor la conexion. El caso es que es con este el cual tengo los ms altos y dispares de bufferbloat subida. Con el HGU5 en monopuesto y el GE550 detras, los ms de bufferbloat de subida son casi siempre los mismos.(0-2ms)

Ahora bien, si que es cierto que el HGU7 me da mas velocidad al menos en el test de movistar. 

Por tanto entiendo que sin QoS bien puesta etc llegue a saturarse la linea pero, no llego a comprender por que el HGU5 no se satura y el HGU7 si...

Es porque la linea llega a su maximo teorico con el HGU7 y con el HGU5 nunca llega a ese maximo? (aunque Gpon soporte 2.5Gbps , y el puerto 10Gb)(teniendo contratados 1Gbps)

Vamos que todo esto, mas alla de que pueda ocasionarme cualquier problema, es curiosidad. Quiero llegar a entender por que el HGU7 siendo mas potente se comporta "raro" y el hgu5 no. 

Y claro, entender por que antes con el HGU7 no me ocurria este problema y ahora si!

Gracias!

Buenas califc​ 

Es totalmente normal que varíe compañero, sin QoS por detrás que mantenga los picos más o menos allanados, es lo esperable, es el motivo por el cual existe el Bufferbloat.

Como te decía previamente, el Bufferbloat no es una "dolencia", no es un "fallo" o una "anomalía", es una consecuencia directa que no puede evitarse por diseño, que sucede simple y llanamente cuando tienes básicamente una "manguera" que está limitada a 1Gbps en este caso, y tú le quieres meter más. Es un cuello de botella en toda regla, a medida que sigue esa "presión", los dispositivos no pueden hacer otra cosa que almacenarlos en los buffer de recepción/transmisión (de ahí el nombre de BufferBloat) esos paquetes a la espera de que les llegue su turno para poder salir. Puedes ver esos buffer (memorias) como una cola a la que van llegando y tienen que esperar. 

Sin QoS, que pueda hacer uso de planificadores como Codel, CAKE, gestión de colas y otros, por lo general se usa la ley más simple y básica: FIFO. Primer paquete en llegar, primer paquete en salir, se acabó. Dependiendo de, se puede aplicar además "TailDrop", es decir, que si el buffer se llena el paquete nuevo se descarta sin más. El buffer, a más lleno, más latencia. Y esto causa un segundo problema rebote, si los paquetes de subida se retrasan, los paquetes de control imprescindibles pueden retrasarse hasta el punto de provocar incluso timeouts, tanto de una conexión cualquiera a incluso la propia conexión de Internet. 

Repito, eso no se puede evitar. Poner un buffer más grande? Vale, haces la cola más grande y evitas más descartes pero no solucionas nada. Y los protocolos de congestión como Cubic, Reno y otros?? Actúan en capa de transporte, en TCP en esencia, son muy importantes pero no vienen ahora al caso, además desde hace años casi el 100% de dispositivos (Linux)( usan el mismo: CUBIC

QoS cambia todo esto. En vez de una cola tienes varias colas, cada una de las colas con pesos (importancia) diferentes. Cuando uno configura QoS de forma adecuada lo que hace primero es configurar el clasificador, es decir, que tráfico concreto va a cada una de las diferentes colas. Después configura las políticas y algoritmos de las colas, donde va actuar por lo general protocolos como AQM/SQM... que vigilarán además que el tráfico en las colas no se eternicen sin llevan mucho tiempo, y para terminar como va a salir el tráfico de las propias colas, que lo gestionan otros protocolos/algoritmos, en función del peso de cada cola... habitualmente alguna variante de Round Robin.

Todo eso no nace de capricho, nace precisamente para amortiguar los casos donde aparece el cuello de botella por saturación de buffers. A medida que han ido pasando los años, sobre todo a nivel doméstico, han ido tomando menos importancia por dos motivos como ya te he comentado:

1º. A mayor caudal (velocidad de línea), mucho más complicado llegar a saturarlo
2º. A mayor caudal, el procesamiento necesario para seguir clasificando y gestionado de forma adecuada QoS se va multiplicando, haciendo que los Router domésticos, a día de hoy, les sea muy muy complicado ser capaces de gestionar dichos caudales por QoS... sin achicharrarse, o provocando una disminución en la descarga/carga.

-------

Si el test está bien diseñado, siempre te van a dar valores diferentes, tanto en uno como en otro, por la propia entropía del sistema, a veces mejor a veces peor. 

Si existe no obstante un detalle "importante" que sí puede tener cierto impacto, y es realmente el lugar diferente donde se puede producir el Bufferbloat. El Bufferbloat aparece simplemente si se llena un buffer... ¿donde?

El HGU5, todas sus interfaces Ethernet son 1Gbps, en el HGU7 no, el HGU7 tiene 2 interfaces 10Gbit, tanto un puerto físico, como el puerto WAN. En el HGU5 el propio hardware jamás podrá siquiera intentar escupir tráfico a más de 940Mbps, la interfaz WAN está limitada a ello. Sí, la ONT interna técnicamente puede escupirlo a 1.2Gbps, con lo que por ella no hay problema alguno. En estos equipos el bufferbloat aparece por lo general en el propio Router en su propia interfaz WAN, simplemente tu quieres que escupa más tráfico del que puede tirar él. Cuando el tráfico llega a la ONT, puede lidiar con 1.2Gbps incluso, con 1Gbps contratado y asignado no es problema, no hay llenado de buffer aquí.

En el HGU7 esto no es así, técnicamente por el puerto WAN podría pasar tráfico incluso de 10Gbits!! Significa que si está recibiendo por un lado o por otro una tasa de, por ejemplo, 1050Mbps, por la interfaz WAN no hay problema alguno. Es más, si haces un test de velocidad con el HGU7 conectado al puerto 10Gbit desde algún equipo con interfaz de 2.5Gbit por ejemplo, verás que el viejo 930Mbps aprox desaparece, y llega más. ¿Ves ahora la diferencia? Ahora, no necesariamente o únicamente se va a acumular tráfico en el propio adaptador físico del Router, sino que puedes estar llenando también los buffer de recepción/transmisión de la ONT. La OLT le dice en todo momento a la ONT en que momento exacto puede transmitir, es quien por así decirlo regula la cantidad de tráfico que puedes transmitir aproximadamente. Problema? SI "alimentas" la ONT interna con tráfico que supera lo que la ONT más o menos gestionará y se le permitirá, el bufferbloat se puede empezar a acumular también en este punto, doble cuello de botella.

----------------

En todos los casos el problema es el mismo y sistemático. Sin QoS, si saturas cualquier punto donde hay buffer intermedios para no tirar la conexión, el tráfico empezará a demorarse, no importa la firmware que uses, Router, ONT... dependiendo del momento del test, el test, los dispositivos conectados a la red en ese momento y otros factores, tendrás un resultado algo mejor o algo peor. Es más, ya has visto por ejemplo el resultado que tengo yo sin QoS usando el mismo Router, y lo tengo desde la firmware b2 creo recordar. 

Si realmente se quiere cero Bufferbloat, con independencia de que como digo a día de hoy me parezca en el 99.99% de los casos algo a ser casi "descartable", las dos únicas soluciones que existen son: QoS o limitación artificial de tráfico en el/los equipos que hagan uso masivo. Y normalmente la segunda opción es mucho mejor, porque en una red doméstica, por muchos dispositivos que existan, que puedan realmente saturar un enlace son en esencia equipos cableados con aplicaciones/servicios de fondo "controlados", es decir, ya sea que te digo yo... un PC descargando un juego de 100GB, haciendo una copia Cloud masiva, un NAS transmitiendo como si no existiese un mañana, P2P... y en todos esos casos suele ser mucho más simple limitar ligeramente la subida/descarga, ya que es verdad que intentar hacer QoS a tasas tan altas es en esencia poner una presión en el SoC del Router innecesaria, aunque el HGU7 tenga capacidad para ello ojo.

De todos si tengo la semana "tranquila" lo paso a modo normal y te hago igualmente test configurando QoS para mis necesidades en el HGU7 y sin él, para que veas la belleza de estos... de paso ver si le sale humo o no de intentar hacer QoS a un stream tan alto...

Saludos.

Hola! gracias por el test, tienes bastante menos que yo con el RTF8316VW y cada vez me da una medida diferente desde 16ms a 200ms sube y baja todo el rato (en monopuesto y router). 

La cosa es, como bien dices, que en monopuesto gestionaria el trafico de internet mi equipo y el HGU seria ONT y trafico iptv y voip. 

Por eso, no entiendo por que con el firmware 2.16/17 iba bien y ahora no. Y por que con el RTF3505VW va bien el bufferbloat y con el RTF8316VW,  Hardware en teoria bastante superior me da esa "inconsistencia".

Si supuestamente el HGU solo pasa el trafico al router, como le esta añadiendo latencia? En teoria deberia darme el 3505 y el 8316 el mismo valor no? ambos en monopuesto. Ya que unicamente pasan el trafico al GE550. 

Por si fuera relevante, el RTF8316VW me da -19db y el RTF3505VW -21db.

Y bueno, entiendo que no llevandola al maximo constantemente no debiera encontrar este "bufferbloat inconsistente" pero me intriga saber por que ambos router en modo monopuesto actuan tan diferentes, y por que un hardware nuevo, no es superior al antiguo :)

Buenas califc​ 

Yo mismo uso siempre mi propio Router compañero:

RTF8316VW en Monopuesto + Router (sin QoS)

No te puedo ver ahora mismo sólo con HGU en modo normal porque no puedo tirar ahora mismo la red, pero el resultado ya te digo que será similar, y con QoS pues simplemente el resultado será aun mejor.

En mi propio Router aunque tengo QoS totalmente adaptado a mis necesidades, lo suelo tener deshabilitado por una sencilla razón: Fibra 1Gbps. Clasificar tráfico a velocidad de 1Gbps implica una sobrecarga importante en los núcleos del Router, y por otro lado como ya te he comentado, es cuanto menos complicado sobrecargar un enlace de fibra de 1Gbpps, a menos que de la casualidad que en el momento concreto de estar jugando o viendo streaming estés por otro lado subiendo de forma masiva algo "gordo" y sostenido. Si con la fibra 300Mbps e incluso 600Mbps el 80% del tiempo lo mantenía habilitado para aplanar curvas aunque el impacto fuese totalmente marginal, a día de hoy es al revés, el 80% está deshabilitado, solo momentos o días concretos que precisamente tengo que mover una enorme cantidad de datos lo habilitado, y solo cuando pasa directamente al Router y no por el Switch intermedio, porque si pasa por el Switch con CoS es más que suficiente.

Como te digo, en Monopuesto el tráfico lo gestiona tu equipo, no el HGU ya que has delegado la conexión, absolutamente todo lo relativo a Internet pasa a ser controlado por tu propio Router. Para el HGU en monopuesto es totalmente indiferente que uses QoS o no, que limites la subida o no. El HGU no abre ni gestiona las conexiones TCP, no  entran en juego los algoritmos de congestión... nada. Sí, internamente el HGU al entrarle el tráfico desde diferentes vías (Internet/VoIP/IPTV) lo clasifica y lo envía cada uno por su respectiva interfaz WAN, pero poco más. 

Saludos.

Hola Theliel​ Muchas gracias por la respuesta.

Entiendo todo lo que me dices, y tal vez deberia haber formulado de otra forma la queja/problema. Ya que, aunque no llegara a afectarme (aunque si que lo noto) el problema es mas la inconsistencia de el RTF8316VW. 

Quitando el TPLink GE550 de la ecuacion, y usando el RTF8316VW como router, sigue presentando el problema de bufferbloat e inconsistencia con el mismo.

El RTF3505VW, modelo mucho mas antiguo (por tanto maduro de firmware) da siempre un buen resultado en los test, ms arriba o abajo.

El problema con el RTF8316VW es que, una vez da 15ms, la otra 55ms, y he llegado a ver 150ms. Esto no pasaba con el firmware 2.16/17 creo recordar que es.

He limitado el enlace a 100Mbps para hacer pruebas y es mucho peor (220ms), me temo que aqui lo que sucede es que el enlace se satura. 

Por tanto, me gustaria que le echen un vistazo, ya que antes iba perfecto, como el RTF3505VW y en los ultimos firmware aparece esta inconsistencia.

Volviendo al monopuesto + GE550, tengo activado el QoS, antes dejaban configurarlo manualmente, pero actualizaron el firmware y ahora es un QoS automatico con IA (IA hasta en la sopa). El problema de bufferbloat persiste con esta configuracion y el RTF8316VW monopuesto. 

Por esto mismo y por las pruebas con el RTF3505VW me decanto por que el RTF8316VW tenga algun bug en el firmware en el lado de las subidas. (en bajada es consistente)

No se si el problema estara en el controlador de los puertos ethernet, en la ram o donde, pero es extraño ya que como dices el HGU en monopuesto deberia quedar invisible y el GE550 manejar todo el trafico.

Pruebas que he realizado:

--------------------------------------------------------------------------------------------------------------------------------------------------

RTF8316VW modo router: bufferbloat (subida) inconsistente

RTF8316VW modo router, enlace 100Mbps: bufferbloat (subida) inconsistente y +200ms (problablemente saturacion de enlace)

RTF8316VW modo router, otros puertos ethernet: bufferbloat (subida) inconsistente

RTF8316VW modo monopuesto + GE550: bufferbloat (subida) inconsistente

----------------------------------------------------------------------------------------------------------------------------------------------------

RTF3505VW modo monopuesto + GE550: bufferbloat (subida) consistente
RTF3505VW modo router: bufferbloat (subida) consistente
-----------------------------------------------------------------------------------------------------------------------------------------------------

En las pruebas he usado los test anteriores, 3 veces cada uno para comprobar que no es fallo de el test en si, o del momento. y algunos test estan hechos a diferentes horas. Tambien he probado 2 cables de red, el que trae el router y uno propio. 

Asi que, quitando que aunque no sature la linea, no deberia notar nada, algo pasa! 

Muchas gracias!

(Si alguien que lea esto con el RTF8316VW ya sea en monopuesto o router puede hacer el test en waveform mismo seria de ayuda)

Buenas califc​ 

Me temo que el BufferBloat es uno de esos terminos muy mal comprendido, explicados....por el público general, donde se mezclan leyendas urbanas, soluciones mágicas y otros. 

En primer lugar, hay que dejar meridianamente claro que es y que no es el BufferBloat, ya que a fin de cuenta más del 99% del tiempo un usuario jamás experimentará Bufferbloat. 

Lo que el BufferBloat no es:
No mide la "calidad" de una conexión
No mide la estabilidad ni la latencia de una línea
No es una característica intrínseca de la línea
No se experimenta en el 99.9% del tiempo

Lo que el BufferBloat si es:
Es una consecuencia real de tener una línea "limitada" en una red local más rápida potencialmente.
Es un "test" de "peor escenario posible"
Mide la gestión de Colas

O dicho de un modo simple y resumido... el Bufferbloat no tiene nada que ver con la calidad de tu conexión, es simplemente la cola que se forma en tu Router cuando la demanda en subida/descarga de tu red hacia Internet satura en esencia la subida/descarga de tu línea. En el 99.9% del tiempo, da igual que hagas uso normal de Internet, Streaming, jugar.... el ping que vas a tener es exactamente el mismo tenga un test de bufferbloat de A+ o de F.

---------------

El Bufferbloat puede ser mayor o menor dependiendo del Router? Sí, es más, es de lo que depende. La linea importa en esencia el caudal que tengas, únicamente... si tienes fibra de 1Gbps potencialmente es mucho más complicado disparar BufferBloat que en una linea de 100Mbps. Simplemente el caudal es mayor con lo que tu red puede meter paquetes hacia dentro de ella o sacarlos de forma que sea infinitamente más complicado saturar el enlace. Esto se aplica a tu propio Router también, y esto es otra cuestión a tener en cuenta... en el momento que usas el HGU en monopuesto, automáticamente el HGU queda invisible a dicho problema, ahora es tu propio Router quien gestiona el tráfico, y por ende sus colas y políticas.

Por qué esto es generalmente irrelevante? Porque el Bufferbloat solo aparece cuando el caudal de la línea se ve comprometido. Mientras esto no ocurra el bufferbloat no existe. Dicho de otro modo, únicamente vas a experimentar bufferbloat en la práctica si tienes un equipo en la red que esté subiendo/descargando (especialmente subiendo) a una tasa muy cercana al límite de tu conexión de Fibra, y de forma simultánea estás con otro equipo (o con el mismo) con alguna aplicación que sea sensible a la latencia. Por ejemplo, tienes tu línea de 1Gbps de fibra y estás jugando online, y a la vez tienes en el equipo una subida sostenida sincronizando por ejemplo un servicio Cloud a  una velocidad de 900Mbps. Aquí sí experimentarás bufferbloat mientras dicha subida se mantenga en ese umbral!! 

Ahora bien, el 99% del tiempo nadie en su casa usa siquiera un 20-40% de la capacidad de su línea. A menos que sean momentos puntuales y concretos, simplemente esto no pasa. Además las velocidades son tan altas que aun cuando subes un fichero se da una paradoja:

1º. La velocidad es tan rápida que no da tiempo, el archivo se sube en cuestión de 1 segundo? 2?
2º. La velocidad se va escalando, para lograr una descarga/subida estable, tienen que pasar varios segundo en la que origen y destino van incrementando la ventana de escalado para adecuar la velocidad. En es tempo por lo general la descarga o subida ha terminado y el bufferbloat no se ha disparado

Así que a menos que seas un usuario que de forma constante estés realizando subidas/descargas masivas y sostenidas... no tienes nada de lo que preocuparte. 

----------

Bien, pero vamos a suponer que sí, ya que hay usuarios que si que hacen un uso masivo de su línea a todas horas, en subida y descarga, se pasan media vida subiendo y descargando datos. El bufferbloat en este escenarios puede darse? Sí, en este escenario es algo a tener en cuenta, si estas todo el día saturando tu línea, y quieres a la vez no tener problemas con la latencia pues si tienes que hacer los deberes.

Cual es la solución en estos casos? Bueno, existen dos soluciones "universales", y repito que todo esto es con total independencia del Router a usar.

-La primera solución, rápida, simple y cuasi universal: Limitar la subida/descarga de la aplicación que se dedica a saturarlo. SI es un programa P2P o un programa Cloud... se limita al 80% por ejemplo la subida/descarga. Problema solucionado, ese 20% restante es margen de sobra para que la red no sature. 

-La segunda, la adecuada pero requiere de altos conocimientos: QoS. Un Router con QoS correctamente configurado para nuestras necesidades, ya sea simplemente con Diffserv o mezcla de tecnologías, soluciona el problema de raíz, ya que somos nosotros los que configuramos la prioridad de cada uno de los paquetes. Así pues podemos poner como la prioridad más baja el tráfico masivo de fondo por HTTP, y por ejemplo como máxima prioridad paquetes de control, DNS, tráfico sensible a la latencia... etc etc etc. La ventaja es que aquí se aplica de forma directa a toda la red... pero repito configurar adecuadamente QoS implica tener por lo general conocimientos avanzados, y no existe una configuración universal porque cada uno tiene sus propias exigencias y prioridades. 

Así que, puedes estar tranquilo. El test sintético puede decir que tienes lo que sea, que a menos que estés saturando tu red constantemente, no vas a tener bufferbloat jamás. Y si así lo tienes porque si hagas un uso exajerado de tu red día y noche, simplemente limita a un 80% las subidas/descargas en el equipo que sea.

Saludos.

Hola buenas, si ese es el numero. El router tiene la ultima version que si no recuerdo mal es la 2.19. Creo que en la 2.17 era que no tenia este problema de bufferbloat y el valor era igual o similar al de el RTF3505VW

Actualmente he dejado conectado el RTF3505VW en monopuesto con la ES_g20.7_R3505VWSTD203_n85

Muchas gracias

Hola califc 

Muchas gracias por el detalle de los datos suministrados. Da gusto leer un análisis técnico tan completo y bien diagnosticado. Para poder revisar a fondo la línea, comprobar la versión exacta que tiene instalada tu router y verificar con nuestro equipo de soporte si hay alguna actualización pendiente o anomalía reportada con el firmware del RTF8316VW, ¿nos podrías confirmar si el número 952***516 es el asociado a tu contrato?

Un saludo, Esaú.