Picos de ping na Starlink: latência segundo a segundo em casa

Em uma sessão, o RTT por IPv4 mudou mais aos 12, 27, 42 e 57 segundos de cada minuto

O teste rodou em outubro de 2026 a partir de um computador ligado por cabo à rede de casa, na mesma conexão que a página 1 rastreou. Todas as rotas até os alvos saíam pela interface cabeada, então nenhum túnel, exit node ou Wi-Fi levou os pings. Os pings vieram do ping do iputils: cinco pedidos de eco por segundo para cada um de quatro alvos, durante uma hora, um processo por alvo, os quatro lado a lado. Essa hora rodou duas vezes, em duas sessões, em dois dias de outubro de 2026. O relógio do computador foi sincronizado antes e depois de cada sessão, então os segundos de cada minuto dele batem com a hora real.

Os alvos foram dois resolvedores de DNS públicos em cada família de endereços:

• o da Cloudflare, 1.1.1.1 por IPv4 e 2606:4700:4700::1111 por IPv6;
• o da Quad9, 9.9.9.9 por IPv4 e 2620:fe::fe por IPv6.

Um alvo em uma sessão é uma leitura, oito ao todo.

O tempo de ida e volta (RTT) de um ping é quanto a resposta demora para voltar. Cada resposta conta no segundo do minuto em que o pedido dela foi enviado. Para cada minuto, a mudança num segundo é o RTT mediano das respostas desse segundo menos a mediana do segundo anterior, sendo a mediana o valor do meio. O valor de um segundo é o tamanho mediano dessas mudanças ao longo da hora, e os quatro segundos com os maiores valores saem dos dados: nenhum segundo foi suposto de antemão.

As regras de cada veredito foram fixadas antes da primeira sessão:

• Um padrão exige que os quatro segundos com as maiores mudanças fiquem a 15 segundos um do outro, e que a mudança mediana nesses segundos seja pelo menos o dobro da mudança mediana entre os outros segundos vizinhos. Quatro segundos de 60 caem a 15 segundos um do outro por acaso em 15 de 487.635 casos.
• Um pico exige que o p99 menos a mediana nesses segundos seja pelo menos o dobro do que é nos outros segundos, ou 5 ou mais pings perdidos ali, com pelo menos o dobro da taxa de perda dos outros segundos. O p99 é o RTT abaixo do qual chegaram 99 de cada 100 respostas.

Na segunda sessão, os dois resolvedores IPv4 cumpriram as duas regras nos mesmos quatro segundos: 12, 27, 42 e 57 de cada minuto, a 15 segundos um do outro. O RTT mudou mais ali, e teve picos ali: o p99 menos a mediana foi mais que o dobro do que era nos outros segundos, +46 contra +21 ms para a Cloudflare e +50 contra +22 ms para a Quad9. Na primeira sessão, para os quatro alvos, e em IPv6 na segunda, a regra do teste não encontrou padrão.

Todos os valores da Tabela 1 estão em ms inteiros. A regra comparou as mudanças medianas antes de serem arredondadas, e é por isso que os 3 e 2 ms da Quad9 cumprem o “pelo menos o dobro”.

A Tabela 2 dá a dispersão de cada leitura: a que distância as respostas ficaram da mediana do próprio alvo na sessão. O pN é o RTT abaixo do qual chegaram N de cada 100 respostas, então o p10 menos a mediana é negativo. Em todas as leituras, o p99 ficou de 22 a 28 ms acima da mediana, e a resposta mais lenta, de 144 a 754 ms acima dela.

Os resolvedores respondem a partir do local mais próximo do respectivo operador, então cada ida e volta também atravessa a rede desse operador. Onde os dois resolvedores IPv4 mudaram nos mesmos segundos, na segunda sessão, as mudanças estão na parte do caminho que os dois compartilham: a rede e o roteador de casa, o enlace de satélite e a rede da Starlink até onde as duas rotas se separam. O teste não consegue separar essas partes e não mostra o que causou as mudanças.

Pesquisadores relatam mudanças a cada 15 segundos, aos 12, 27, 42 e 57 segundos de cada minuto

Tanveer et al. mediram a partir de quatro antenas Starlink, uma na Europa Ocidental e três nos EUA (Nordeste, Meio-Oeste e Noroeste), cada uma com um computador ligado por Ethernet, até servidores nos pontos de presença (PoPs) da Starlink que atendiam essas antenas, com granularidade de milissegundos. Eles relatam grandes mudanças de latência “at the 12th, 27th, 42nd, and 57th second past every minute” (em tradução nossa, no 12º, 27º, 42º e 57º segundo de cada minuto), vistas “from all our measured locations for all periods of time” (em todos os locais que medimos, em todos os períodos; preprint no arXiv, v1, julho de 2023, seção 3, verificado em outubro de 2026). Eles atribuem as mudanças a “a global network controller” (um controlador de rede global), que designa um satélite para cada antena, e escrevem que “these allocations are made every 15-seconds, globally” (essas alocações são feitas a cada 15 segundos, globalmente; resumo).

Mohan et al., em artigo publicado na ACM Web Conference 2024, mediram a partir de antenas em Edimburgo e Munique. Eles concluíram que a Starlink “performs network reconfigurations every 15 s” (faz reconfigurações de rede a cada 15 s), e que as reconfigurações são “globally synchronized and likely independent of satellite handovers” (sincronizadas globalmente e provavelmente independentes das trocas de satélite; seção 1). Os RTTs eram “comparatively stable within each Starlink reconfiguration interval but potentially changing between intervals” (relativamente estáveis dentro de cada intervalo de reconfiguração da Starlink, mas podendo mudar entre os intervalos), e continuaram mudando entre intervalos em trechos em que a antena do Reino Unido só podia ser atendida por um satélite. A conclusão deles: “Hand-offs between satellites are not the cause of these effects.” (As trocas entre satélites não são a causa desses efeitos; seção 6.2; arXiv v2, fevereiro de 2024, verificado em outubro de 2026.) A mesma equipe apresentou o trabalho no IRTF Open, no IETF 123, em julho de 2025, com “15-secs reconfigurations are prevalent at all locations” (reconfigurações de 15 s predominam em todos os locais) e “15-secs intervals are globally synchronized” (os intervalos de 15 s são sincronizados globalmente) nos slides (verificado em outubro de 2026).

Na segunda sessão daqui, por IPv4, as mudanças dos dois resolvedores caíram aos 12, 27, 42 e 57 segundos de cada minuto, os segundos que Tanveer et al. relataram. Na primeira sessão, e em IPv6 na segunda, a regra do teste não encontrou padrão. A explicação para as mudanças de 15 em 15 segundos é dos pesquisadores, não desta página.

Os próprios números de latência da Starlink são montados a partir de médias de 15 segundos. O documento Improving Starlink's Latency da Starlink diz que ela coleta medições dos seus roteadores a cada 15 segundos, e que essas “15 second average latencies” (latências médias de 15 segundos) dão os números de mediana e de pior caso dela. O PDF não traz data no texto; o arquivo foi criado em março de 2024 (verificado em outubro de 2026). Um pico mais curto que 15 segundos fica dentro de uma dessas médias.

Você pode rodar o mesmo teste num computador da sua rede

O teste precisa de um computador Linux com o ping do iputils e Python 3, ligado por cabo ao seu roteador.

1. Confira se o relógio dele está sincronizado antes de começar e de novo quando a hora terminar, como o teste fez. Num sistema com systemd, este comando imprime yes quando está:

   timedatectl show -p NTPSynchronized --value

2. Depois, inicie os quatro pings juntos, cada um gravando no seu próprio arquivo:

   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 linha de ping é o comando que o teste rodou para um alvo, só com o redirecionamento para um arquivo e o & acrescentados. O & inicia cada um em segundo plano para que os quatro rodem lado a lado, e o wait retorna quando os quatro tiverem parado. O que as opções fazem, segundo o ping(8) (iputils 20250605, verificado em outubro de 2026):

   • -D imprime um timestamp antes de cada linha, “unix time + microseconds as in gettimeofday” (tempo unix + microssegundos, como em gettimeofday).
   • -O informa um pedido que ainda espera a resposta antes de o próximo sair, então um ping perdido também deixa uma linha. Sem essa opção, as contagens de perda saem zeradas.
   • -n dá “numeric output only” (só saída numérica), sem resolução de nomes.
   • -i 0.2 envia um ping a cada 0,2 segundos. “Only super-user may set interval to values less than 2 ms” (só o superusuário pode definir o intervalo com valores menores que 2 ms), então isto não precisa de root.
   • -w 3600 para o ping depois de 3.600 segundos, uma hora.

3. Salve este script como latency_fold.py. Ele usa só a biblioteca padrão do Python 3 e não imprime nenhum RTT. Para cada segundo do minuto, ele dá os pings enviados, os pings perdidos e a mudança mediana em relação ao segundo anterior, com precisão de 0,1 ms, nas colunas second, sent, lost e change_ms, e depois uma última linha com os quatro segundos que tiveram as maiores mudanças.

   O 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. Quando os pings tiverem parado, rode o script em cada arquivo:

   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

   Na própria saída de ping do teste, nas duas sessões, este script deu as mesmas linhas por segundo e os mesmos quatro segundos que o script do próprio teste, para todos os alvos.

5. A última linha sempre cita quatro segundos. Se eles não ficarem a 15 segundos um do outro, a hora não mostrou padrão pela regra desta página, e os quatro segundos não significam nada sozinhos. Se ficarem, a outra metade da regra compara a mediana das mudanças de todos os minutos nesses quatro segundos com a mesma mediana nos outros segundos, e o latency_fold.py não imprime esses dois valores. A coluna change_ms dá, em vez disso, a mediana de cada segundo, então os valores dos quatro segundos contra o meio dos outros 56 são uma verificação aproximada, e não a própria regra, e quando eles saem perto do dobro do resto, a verificação pode cair de qualquer um dos lados.

Estes são comandos do iputils do Linux; o ping de outros sistemas usa outras opções, e esta página não as dá. Por Wi-Fi, o enlace de rádio dentro da sua casa também faz parte de cada ida e volta, e este teste não cobriu isso.

901 de 143.462 pings ficaram sem resposta, mais vezes aos 12, 27, 42 e 57 segundos de cada minuto

Somando as duas sessões e os quatro alvos, 901 de 143.462 pings ficaram sem resposta: 417 de 71.733 por IPv4 e 484 de 71.729 por IPv6. Dos 901, 109 foram enviados aos 12, 27, 42 ou 57 segundos de cada minuto, de 9.567 enviados nesses segundos. Isso é 1,9 vezes a taxa de perda nos outros segundos, onde 792 de 133.895 ficaram sem resposta: 2,1 vezes por IPv4 e 1,8 vezes por IPv6. Mas a maioria dos pings perdidos não foi enviada nesses segundos: 109 dos 901, cerca de 1 em cada 8, foram.

Essas contagens usam os mesmos quatro segundos para todos os alvos nas duas sessões, qualquer que tenha sido o veredito de cada leitura, então não dependem de um padrão ter sido encontrado.

Um ping sem resposta pode ter se perdido na ida, na volta ou no alvo. O resolvedor de nenhum dos operadores perdeu várias vezes mais pings que o do outro na mesma família, então nada indica um resolvedor limitando o ICMP.

Não testado aqui

• Jogos, chamadas e streaming. Nenhum aplicativo foi testado, então esta página não dá veredito sobre nenhum deles.
• Soluções. Nenhuma configuração, produto ou segunda conexão foi testada.
• Wi-Fi e outras conexões. As duas sessões rodaram num enlace cabeado, numa só conexão de casa.
• A causa nesta conexão. A explicação da seção de pesquisas é dos pesquisadores. Este teste não consegue dizer por que o padrão apareceu na segunda sessão e não na primeira, ou em IPv4 e não em IPv6, nem se outra hora o mostraria.
• As estatísticas da própria antena, obstruções e o clima.
• Os próprios tempos de ida e volta. Todo valor em milissegundos desta página é uma diferença, porque o RTT até o local mais próximo de um resolvedor público diz onde fica esse local. A Starlink publica números próprios, e o documento dela está no link da seção de pesquisas. O número de latência típica da etiqueta de banda larga da Starlink nos EUA é posto ao lado do tempo mínimo de ida e volta por um satélite geoestacionário na comparação de internet via satélite.
• Quedas ao longo de dias. Duas horas de pings não conseguem mostrar com que frequência uma conexão cai ao longo de uma semana.

Veja o veredito para homelab a partir dos cinco testes.