Tu speed-test miente.
Mide responsiveness en su lugar.

La mentira del número grande

Cualquier sitio de speed-test abre con un medidor. Sube, se posa en una cifra impresionante (480 de bajada, 510, 940 si tienes fibra) y esa cifra se vuelve la historia. La historia casi siempre está mal. No deshonesta, exactamente. Solo la pregunta equivocada, contestada con precisión.

El throughput es una medida de capacidad: cuánta agua puede mover la tubería cuando no pasa nada más. El problema es que las redes reales casi nunca parecen "no pasa nada más". Las redes reales se parecen a una videollamada familiar, un respaldo en la nube, una sincronización de Slack, una actualización y una niña viendo dibujos animados, todo a la vez. En esa escena lo que te importa no son los litros por minuto totales. Te importa si tu paquete de voz puede colarse en la cola y llegar a tiempo.

Esa segunda pregunta es responsiveness, y durante veinte años apenas tuvimos forma de medirla en un navegador. Ahora la tenemos. Está integrada en macOS. Solo que nadie te lo había dicho.

Qué es el bufferbloat, en un párrafo

Cada router y módem entre tu portátil e internet tiene un búfer: un poco de memoria donde los paquetes esperan turno. Cuando el enlace delante del búfer es más lento que el de detrás (tu uplink de 40 Mbps detrás de una LAN gigabit, por ejemplo), el búfer empieza a llenarse. Los fabricantes hicieron esos búferes absurdamente grandes porque tirar paquetes parece un bug. Pero un búfer demasiado grande mantiene tu paquete de voz de Zoom detrás de cada otro paquete que llegó un milisegundo antes. La tubería mueve bytes de sobra. Los bytes que importan están haciendo cola. Ese retraso (medido en cientos de milisegundos bajo carga) es bufferbloat. Por eso pasa tu speed-test y se descose tu llamada.

Aparece RPM: Round-trips Per Minute

En 2021, el equipo de redes de Apple propuso una métrica en lenguaje claro: RPM, o Round-trips Per Minute. La idea es casi vergonzosamente sencilla. Mientras la tubería está saturada (estás bajando y subiendo a tope), cuenta cuántos viajes de ida y vuelta de petición/respuesta puedes completar en un minuto. Una red responsiva hace miles. Una red bloated cae a cientos. La misma tubería de 500 Mbps en ambos casos.

Apple lanzó una herramienta para esto en macOS Monterey. Se llama networkQuality, vive en /usr/bin/networkQuality, y si abres un Terminal y la lanzas, verás algo así:

$ networkQuality
==== SUMMARY ====
Uplink capacity:   38.412 Mbps
Downlink capacity: 476.185 Mbps
Responsiveness:    Medium (540 RPM)
Idle Latency:      18 ms

Lee esa salida con calma. La tubería es ancha, casi medio gigabit de bajada. La responsividad es medium. 540 idas y vueltas por minuto son unas nueve por segundo: tu paquete de voz espera unos 111 ms en una red cargada, frente a 18 ms en reposo. Esa diferencia es exactamente por qué tu llamada suena bien cuando no hay nadie en casa y se rompe cuando toda la familia está streaming.

High, Medium, Low, ¿qué significan?

Apple agrupa el RPM en tres categorías legibles:

• High, 2.000 RPM o más. La red es responsiva. El trabajo en tiempo real (llamadas, juego, edición colaborativa) se siente nítido pase lo que pase a la vez.
• Medium, aproximadamente 600–2.000 RPM. La red sigue siendo usable, pero las apps interactivas se sentirán perezosas bajo carga. Aquí están la mayoría de las redes del hogar en horario punta, y de aquí salen las quejas.
• Low, por debajo de 600 RPM. Los búferes están llenos. Las llamadas de voz se cortan, el vídeo se congela, las teclas en SSH llegan en bloques. Ninguna cantidad extra de ancho de banda lo arregla hasta que los búferes se vacíen.

Por qué un speed-test no ve esto

Un speed-test sólo mide la mitad fácil del problema: idle throughput, normalmente en una ráfaga corta, normalmente sobre una conexión que tu operadora ha aprendido a priorizar. Te dice qué puede hacer tu tubería cuando va ligera, y nunca hace la pregunta siguiente sobre latencia bajo carga. Bufferbloat es, por definición, invisible a ese test, porque el test es la carga: no hay otro tráfico que haga cola detrás.

El síntoma para el usuario es familiar. El técnico de la operadora viene, lanza el speed-test, pasa, y te dicen que la conexión está bien. La siguiente videollamada vuelve a entrecortarse. El técnico no mintió. Sólo midió lo que no era.

El test de RPM en la práctica

El networkQuality de Apple es elegantemente brutal. Abre varias conexiones paralelas a endpoints de CDN, las satura en ambos sentidos y luego cronometra cuánto tarda un parecito de petición/respuesta HTTP/2 en completarse mientras ocurre la saturación. Eso es el valor RPM. Las medidas de capacidad caen de propina, por eso la herramienta devuelve los tres números en una sola ejecución.

El test dura unos quince segundos. Aporrea tu enlace, así que no lo lances durante una llamada. También expone cosas que tu operadora preferiría que no vieras: canales Wi-Fi que chocan con los vecinos, un router con un bug de firmware que duplica la profundidad de cola, un VPN que añade 200 ms de latencia en cada ida y vuelta. Muy a menudo, descubrirás que el eslabón débil no es tu operadora. Está dentro de tu propia casa.

Qué hacer cuando el RPM está Low

No hay una solución mágica, pero la lista es finita:

1. Prueba primero por cable. Conecta un cable Ethernet al Mac y vuelve a lanzar networkQuality. Si el RPM salta a High, tu problema es el Wi-Fi (congestión, solapamiento de canales o distancia), no la operadora.
2. Activa Smart Queue Management. Los routers que soportan SQM, CAKE o fq_codel aplastan el bufferbloat de forma drástica. Un router de 100 $ con fq_codel activado le gana a uno de 600 $ sin él.
3. Limita tu upload. Si SQM no está disponible, limita el upload del Mac a un 90 % de la capacidad de uplink que mediste. Sólo ese cambio impide que tus propios uploads llenen el búfer y dejen sin ACK a tus descargas.
4. Sustituye el combo módem-router de la operadora. Muchos equipos del operador están ajustados para benchmarks de throughput, no para responsividad. Poner el equipo del operador en modo bridge y meter tu propio router delante es la mayor mejora aislada de RPM que verá la mayoría.

Tres mitos persistentes

"Más ancho de banda lo arregla." A veces, la mayoría de las veces no. Si tu uplink ya se satura con un solo backup, subir de 40 a 100 Mbps de subida ayuda. Pero si el verdadero culpable es el búfer, chocarás con el mismo techo el doble de rápido y los síntomas vuelven. La solución es vaciar la cola, no engordar la tubería de delante.

"Mi ping es de 12 ms, así que estoy bien." Ping mide latencia en reposo: cuánto tarda un paquete cuando no hay nada en el camino. Bufferbloat sólo aparece bajo carga. Un ping en reposo de 12 ms en un enlace bloated se convierte rutinariamente en un ping bajo carga de 350 ms. Lanza ping en un terminal y un upload grande en otro, y lo verás en tiempo real.

"La operadora ya optimizó esto." Algunas, sí. Muchas, no. La ingeniería no es difícil, pero el incentivo comercial apunta al revés: una red ajustada para speed-test gana en mercados que compran por números de throughput. La responsividad casi nunca aparece en una página de marketing.

Dónde encaja WiFi & IP Info

Pusimos el motor networkQuality a un clic de distancia en la barra de menús. El panel Network Quality del nivel Pro lanza el mismo test de Apple, muestra capacidad uplink/downlink, reporta el bucket de RPM y la línea base de RTT, y, crucialmente, lleva un registro. Puedes pulsar "volver a ejecutar" una vez por hora durante una semana y ver el patrón: High un sábado por la mañana, Medium en la cena, Low cuando los críos vuelven del cole. Ese gráfico es lo que hace que la operadora se mueva de verdad, porque la reproducibilidad es lo que convierte una queja en un ticket.

Combínalo con el gráfico de Historial de latencia y el Registro de conexiones de la app, y le mandas a tu proveedor un ticket de treinta segundos: "El RPM baja de 2.400 a 410 entre las 18:00 y las 21:00 hora local, correlacionado con un RTT mediano tres veces más alto hasta vuestra propia pasarela. Adjunto CSV." Es una conversación muy distinta de "mi internet va lento."

La versión corta

Tu speed-test mide capacidad. La capacidad es real, y a veces es el problema. La mayoría de las veces, sin embargo, el problema es responsiveness: si tu tráfico puede entrar y salir a tiempo mientras la tubería está ocupada. RPM es la métrica para eso. Apple construyó una herramienta de primer nivel para medirlo. Nosotros pusimos esa herramienta en tu barra de menús y guardamos el historial.

Si te llevas una sola frase de esta página, que sea esta: el ancho de banda es lo ancha que es la carretera; la responsividad es lo que esperas en los semáforos. Las dos importan. Sólo una de ellas está en tu página de speed-test.