Starlink ping spikes: picos de latencia segundo a segundo en casa

En una sesión, los tiempos de ida y vuelta por IPv4 cambiaron más en los segundos 12, 27, 42 y 57 de cada minuto

La prueba se hizo en octubre de 2026 desde un equipo conectado por cable a la red de casa, en la misma conexión que trazó la página 1. Todas las rutas hacia los destinos salían por la interfaz cableada, así que ni un túnel, ni un nodo de salida ni el Wi-Fi llevaron los pings. Los pings salieron de ping de iputils: cinco solicitudes de eco por segundo a cada uno de los cuatro destinos durante una hora, un proceso por destino, los cuatro en paralelo. Esa hora se hizo dos veces, en dos sesiones en dos días de octubre de 2026. El reloj del equipo se sincronizó antes y después de cada sesión, así que sus segundos de cada minuto coinciden con la hora real.

Los destinos fueron dos resolutores DNS públicos de cada familia de direcciones:

• el de Cloudflare, 1.1.1.1 por IPv4 y 2606:4700:4700::1111 por IPv6;
• el de Quad9, 9.9.9.9 por IPv4 y 2620:fe::fe por IPv6.

Un destino en una sesión es una lectura; ocho en total.

El tiempo de ida y vuelta (RTT) de un ping es lo que tarda en volver su respuesta. Cada respuesta cuenta en el segundo del minuto en que se envió su solicitud. Para cada minuto, el cambio en un segundo es la mediana del RTT de las respuestas de ese segundo menos la mediana del segundo anterior, donde la mediana es el valor central. La cifra de un segundo es la mediana del tamaño de esos cambios a lo largo de la hora, y los cuatro segundos con las cifras más altas salen de los datos: no se supuso ningún segundo de antemano.

Las reglas de cada veredicto se fijaron antes de la primera sesión:

• Un patrón exige que los cuatro segundos con los mayores cambios estén separados por 15 segundos, y que la mediana del cambio en esos segundos sea al menos el doble de la mediana del cambio entre otros segundos vecinos. Cuatro segundos de 60 quedan separados por 15 segundos por azar en 15 de 487 635 casos.
• Un pico exige que p99 menos la mediana en esos segundos sea al menos el doble que en los demás segundos, o que se pierdan allí 5 pings o más, con al menos el doble de la tasa de pérdida del resto. p99 es el RTT por debajo del cual llegaron 99 de cada 100 respuestas.

En la segunda sesión, los dos resolutores IPv4 cumplieron las dos reglas en los mismos cuatro segundos: 12, 27, 42 y 57 de cada minuto, separados por 15 segundos. Ahí fue donde más cambió el RTT, y ahí tuvo picos: p99 menos la mediana fue más del doble que en los demás segundos, +46 frente a +21 ms hacia Cloudflare y +50 frente a +22 ms hacia Quad9. En la primera sesión, para los cuatro destinos, y por IPv6 en la segunda, la regla de la prueba no encontró ningún patrón.

Todas las cifras de la tabla 1 están en ms enteros. La regla comparó las medianas de los cambios antes de redondearlas, y por eso los 3 y 2 ms de Quad9 cumplen "al menos el doble".

La tabla 2 da la dispersión de cada lectura: cuánto se alejaron las respuestas de la propia mediana de ese destino en la sesión. pN es el RTT por debajo del cual llegaron N de cada 100 respuestas, así que p10 menos la mediana es negativo. En todas las lecturas, p99 estuvo entre 22 y 28 ms por encima de la mediana, y la respuesta más lenta, entre 144 y 754 ms por encima.

Los resolutores responden desde el sitio más cercano de su operador, así que cada RTT cruza también la red de ese operador. Donde los dos resolutores IPv4 cambiaron en los mismos segundos, en la segunda sesión, los cambios están en la parte de la ruta que comparten los dos: la red y el router de casa, el enlace por satélite y la red de Starlink hasta donde se separan las dos rutas. La prueba no puede separar esas partes, y no muestra qué causó los cambios.

Los investigadores informan de cambios cada 15 segundos, en los segundos 12, 27, 42 y 57 de cada minuto

Tanveer et al. midieron desde cuatro antenas de Starlink, una en Europa occidental y tres en Estados Unidos (noreste, medio oeste y noroeste), cada una con un equipo conectado por Ethernet, hacia servidores en los puntos de presencia (PoP) de Starlink que daban servicio a esas antenas, con granularidad de milisegundos. Informan de grandes cambios de latencia en los segundos 12, 27, 42 y 57 de cada minuto ("at the 12th, 27th, 42nd, and 57th second past every minute"), observados desde todas sus ubicaciones medidas y en todos los periodos ("from all our measured locations for all periods of time"; preprint de arXiv, v1, julio de 2023, sección 3, consultado en octubre de 2026). Atribuyen los cambios a un controlador de red global ("a global network controller") que asigna a cada antena su satélite, y escriben que esas asignaciones se hacen cada 15 segundos, de forma global ("these allocations are made every 15-seconds, globally"; resumen).

Mohan et al., en un trabajo publicado en la ACM Web Conference 2024, midieron desde antenas en Edimburgo y Múnich. Encontraron que Starlink hace reconfiguraciones de red cada 15 s ("performs network reconfigurations every 15 s"), y que las reconfiguraciones están sincronizadas globalmente y probablemente son independientes de los traspasos entre satélites ("globally synchronized and likely independent of satellite handovers"; sección 1). Los RTT eran comparativamente estables dentro de cada intervalo de reconfiguración de Starlink, pero podían cambiar entre intervalos ("comparatively stable within each Starlink reconfiguration interval but potentially changing between intervals"), y seguían cambiando entre intervalos en tramos en los que la antena del Reino Unido solo podía recibir servicio de un satélite. Su conclusión es que los traspasos entre satélites no son la causa de estos efectos ("Hand-offs between satellites are not the cause of these effects."; sección 6.2; arXiv v2, febrero de 2024, consultado en octubre de 2026). El mismo equipo presentó el trabajo en IRTF Open, IETF 123, en julio de 2025, y sus diapositivas dicen que las reconfiguraciones cada 15 segundos predominan en todas las ubicaciones ("15-secs reconfigurations are prevalent at all locations") y que los intervalos de 15 segundos están sincronizados globalmente ("15-secs intervals are globally synchronized"; consultadas en octubre de 2026).

En la segunda sesión de esta prueba, por IPv4, los cambios de los dos resolutores cayeron en los segundos 12, 27, 42 y 57 de cada minuto, los segundos que publicaron Tanveer et al. En la primera sesión, y por IPv6 en la segunda, la regla de la prueba no encontró ningún patrón. La explicación de los cambios cada 15 segundos es de los investigadores, no de esta página.

Las cifras de latencia que publica Starlink se construyen a partir de promedios de 15 segundos. Su documento Improving Starlink's Latency dice que Starlink recoge mediciones de sus routers cada 15 segundos, y que esas latencias promedio de 15 segundos ("15 second average latencies") dan sus cifras de mediana y del peor caso. El PDF no tiene fecha en su texto; el archivo se creó en marzo de 2024 (consultado en octubre de 2026). Un pico de menos de 15 segundos queda dentro de uno de esos promedios.

Puedes repetir la misma prueba desde un equipo de tu red

La prueba necesita un equipo con Linux, con ping de iputils y Python 3, conectado por cable a tu router.

1. Comprueba que su reloj está sincronizado antes de empezar y otra vez al terminar la hora, como hizo la prueba. En un sistema con systemd, esto imprime yes cuando lo está:

   timedatectl show -p NTPSynchronized --value

2. Después lanza los cuatro pings a la vez, cada uno escribiendo en su propio archivo:

   ping -D -O -n -i 0.2 -w 3600 1.1.1.1 > cloudflare-ipv4.txt &
   ping -D -O -n -i 0.2 -w 3600 9.9.9.9 > quad9-ipv4.txt &
   ping -D -O -n -i 0.2 -w 3600 2606:4700:4700::1111 > cloudflare-ipv6.txt &
   ping -D -O -n -i 0.2 -w 3600 2620:fe::fe > quad9-ipv6.txt &
   wait

   Cada línea ping es el comando que la prueba ejecutó para un destino, con solo la redirección a un archivo y el & añadidos. & lanza cada uno en segundo plano para que los cuatro funcionen en paralelo, y wait termina cuando los cuatro se han detenido. Qué hace cada opción, según ping(8) (iputils 20250605, consultado en octubre de 2026):

   • -D imprime una marca de tiempo antes de cada línea, en tiempo Unix más microsegundos, como en gettimeofday ("unix time + microseconds as in gettimeofday").
   • -O informa de una solicitud que sigue esperando su respuesta antes de que salga la siguiente, así que un ping perdido también deja una línea. Sin esta opción, los recuentos de pérdidas salen a cero.
   • -n da solo salida numérica ("numeric output only"), sin búsquedas de nombres.
   • -i 0.2 envía un ping cada 0.2 segundos. Solo el superusuario puede fijar intervalos de menos de 2 ms ("Only super-user may set interval to values less than 2 ms"), así que esto no necesita root.
   • -w 3600 detiene ping tras 3600 segundos, una hora.

3. Guarda este script como latency_fold.py. Solo usa la biblioteca estándar de Python 3 y no imprime ningún RTT. Para cada segundo del minuto, da los pings enviados, los pings perdidos y la mediana del cambio respecto al segundo anterior, con precisión de 0.1 ms, en las columnas second, sent, lost y change_ms, y después una última línea con los cuatro segundos que tuvieron los mayores cambios.

   El script latency_fold.py

   #!/usr/bin/env python3
   """Fold the output of `ping -D -O -n -i 0.2 <target>` by second past the minute.
   
   For each second past the minute, by the time each request was sent on this computer's clock, it prints
   how many requests were sent, how many never got a reply, and the median size of the change in the
   round trip from the second before, in ms (round trips read in whole ms). Usage: python3 latency_fold.py < ping.txt
   """
   import re
   import statistics
   import sys
   from collections import defaultdict
   
   INTERVAL_US = 200_000                     # ping -i 0.2
   sent_at, rtt = {}, {}                     # request number -> send time, round trip (microseconds)
   for line in sys.stdin:
       m = re.match(r"\[(\d+)\.(\d{6})\] .* icmp_seq=(\d+) .*time=([\d.]+) ms$", line)
       if m:                                 # a reply: it was sent one round trip before it was printed
           seq, us = int(m[3]), int(float(m[4]) + 0.5) * 1000  # in whole ms, as ping prints 100 ms or more
           rtt[seq], sent_at[seq] = us, int(m[1]) * 10**6 + int(m[2]) - us
       m = re.match(r"\[(\d+)\.(\d{6})\] no answer yet for icmp_seq=(\d+)", line)
       if m:                                 # printed as the next request goes out, one interval later
           sent_at.setdefault(int(m[3]), int(m[1]) * 10**6 + int(m[2]) - INTERVAL_US)
   by_second = defaultdict(list)             # whole second of sending -> round trips (None: no reply)
   for seq, t in sent_at.items():
       by_second[t // 10**6].append(rtt.get(seq))
   sent, lost, changes = [0] * 60, [0] * 60, defaultdict(list)
   for t, trips in by_second.items():
       sent[t % 60] += len(trips)
       lost[t % 60] += trips.count(None)
       now = [x for x in trips if x is not None]
       before = [x for x in by_second.get(t - 1, []) if x is not None]
       if len(now) >= 3 and len(before) >= 3:
           changes[t % 60].append(abs(statistics.median(now) - statistics.median(before)))
   change = {s: statistics.median(c) for s, c in changes.items()}
   print("second  sent  lost  change_ms")
   for s in range(60):
       print(f"{s:6}  {sent[s]:4}  {lost[s]:4}  " + (f"{change[s] / 1000:9.1f}" if s in change else "        -"))
   print("largest changes at seconds:", *sorted(sorted(change, key=lambda s: (-change[s], s))[:4]))

4. Cuando los pings se hayan detenido, ejecútalo con cada archivo:

   python3 latency_fold.py < cloudflare-ipv4.txt
   python3 latency_fold.py < quad9-ipv4.txt
   python3 latency_fold.py < cloudflare-ipv6.txt
   python3 latency_fold.py < quad9-ipv6.txt

   Con la salida de ping de la propia prueba, en las dos sesiones, este script dio las mismas filas por segundo y los mismos cuatro segundos que el script de la prueba, para cada destino.

5. La última línea siempre nombra cuatro segundos. Si no están separados por 15 segundos, la hora no mostró ningún patrón según la regla de esta página, y los cuatro segundos no significan nada por sí solos. Si lo están, la otra mitad de la regla compara la mediana del cambio de cada minuto en esos cuatro segundos con la misma mediana en los demás segundos, y latency_fold.py no imprime esas dos cifras. Su columna change_ms da en cambio la mediana propia de cada segundo, así que las cifras de los cuatro segundos frente al valor central de los otros 56 son una comprobación aproximada, no la regla en sí, y cuando salen cerca del doble del resto, la comprobación puede caer de cualquiera de los dos lados.

Estos son los comandos de iputils de Linux; el ping de otros sistemas usa otras opciones, y esta página no las da. Por Wi-Fi, el enlace de radio dentro de tu casa también forma parte de cada RTT, y esta prueba no lo cubrió.

901 de 143 462 pings quedaron sin respuesta, más a menudo en los segundos 12, 27, 42 y 57 de cada minuto

En las dos sesiones y los cuatro destinos, 901 de 143 462 pings quedaron sin respuesta: 417 de 71 733 por IPv4 y 484 de 71 729 por IPv6. De los 901, 109 se enviaron en los segundos 12, 27, 42 o 57 de cada minuto, de 9567 enviados en esos segundos. Es 1.9 veces la tasa de pérdida en los demás segundos, donde 792 de 133 895 quedaron sin respuesta: 2.1 veces por IPv4 y 1.8 veces por IPv6. Aun así, la mayoría de los pings perdidos no se enviaron en esos segundos: lo fueron 109 de los 901, aproximadamente 1 de cada 8.

Estos recuentos usan los mismos cuatro segundos para todos los destinos en las dos sesiones, fuera cual fuera el veredicto de cada lectura, así que no dependen de que se encontrara un patrón.

Un ping sin respuesta puede haberse perdido a la ida, a la vuelta o en el destino. El resolutor de ningún operador perdió varias veces más pings que el del otro en la misma familia, así que nada apunta a que un resolutor limite ICMP.

Sin probar aquí

• Juegos, llamadas y streaming. No se probó ninguna aplicación, así que esta página no da veredicto sobre ninguno de ellos.
• Soluciones. No se probó ningún ajuste, producto ni segunda conexión.
• Wi-Fi y otras conexiones. Las dos sesiones se hicieron por un enlace cableado, en una sola conexión doméstica.
• La causa en esta línea. La explicación de la sección de investigación es de los investigadores. Esta prueba no puede decir por qué el patrón apareció en la segunda sesión y no en la primera, ni por IPv4 y no por IPv6, ni si otra hora lo mostraría.
• Las estadísticas propias de la antena, las obstrucciones y el clima.
• Los propios tiempos de ida y vuelta. Todas las cifras en milisegundos de esta página son diferencias, porque el RTT hasta el sitio más cercano de un resolutor público dice dónde está ese sitio. Starlink publica sus propias cifras, y su documento está enlazado en la sección de investigación. La cifra de latencia típica de la etiqueta de Starlink para Estados Unidos está junto al viaje de ida y vuelta mínimo a través de un satélite geoestacionario en la comparación de internet satelital.
• Cortes a lo largo de días. Dos horas de pings no pueden mostrar con qué frecuencia se corta una conexión a lo largo de una semana.

Consulta el veredicto para un homelab a partir de las cinco pruebas.