Starlink-Ping-Spitzen: Latenz Sekunde für Sekunde, von zu Hause

In einem Durchgang änderten sich die IPv4-Umlaufzeiten am stärksten 12, 27, 42 und 57 Sekunden nach der vollen Minute

Der Test lief im Oktober 2026 auf einem per Kabel angeschlossenen Computer im Heimnetz, am selben Anschluss, dessen Route Seite 1 verfolgt hat. Jede Route zu den Zielen lief über die kabelgebundene Schnittstelle, kein Tunnel, kein Exit-Node und kein WLAN trug also die Pings. Die Pings kamen von iputils ping: fünf Echo-Anfragen pro Sekunde an jedes von vier Zielen, eine Stunde lang, ein Prozess pro Ziel, alle vier nebeneinander. Diese Stunde lief zweimal, in zwei Durchgängen an zwei Tagen im Oktober 2026. Die Uhr des Computers war vor und nach jedem Durchgang synchronisiert, seine Sekunden nach der vollen Minute stimmen also mit der echten Zeit überein.

Die Ziele waren zwei öffentliche DNS-Resolver pro Adressfamilie:

• der von Cloudflare, 1.1.1.1 über IPv4 und 2606:4700:4700::1111 über IPv6;
• der von Quad9, 9.9.9.9 über IPv4 und 2620:fe::fe über IPv6.

Ein Ziel in einem Durchgang ist eine Messreihe, acht insgesamt.

Die Umlaufzeit (Round-Trip-Time, RTT) eines Pings ist die Zeit, bis seine Antwort zurückkommt. Jede Antwort zählt zu der Sekunde nach der vollen Minute, in der ihre Anfrage gesendet wurde. Für jede Minute ist die Änderung an einer Sekunde die mediane Umlaufzeit der Antworten dieser Sekunde minus den Median der Sekunde davor, wobei der Median der mittlere Wert ist. Der Wert einer Sekunde ist die mediane Größe dieser Änderungen über die Stunde, und die vier Sekunden mit den größten Werten ergeben sich aus den Daten: Keine Sekunde wurde vorab angenommen.

Die Regeln für jedes Urteil standen vor dem ersten Durchgang fest:

• Ein Muster verlangt, dass die vier Sekunden mit den größten Änderungen 15 Sekunden auseinanderliegen und dass die mediane Änderung an diesen Sekunden mindestens doppelt so groß ist wie die mediane Änderung zwischen anderen benachbarten Sekunden. Dass vier von 60 Sekunden zufällig 15 Sekunden auseinanderliegen, kommt in 15 von 487.635 Fällen vor.
• Eine Spitze verlangt, dass p99 minus Median an diesen Sekunden mindestens doppelt so groß ist wie an anderen Sekunden, oder dass dort 5 oder mehr Pings verloren gingen, bei mindestens der doppelten Verlustrate wie anderswo. p99 ist die Umlaufzeit, unter der 99 von 100 Antworten lagen.

Im zweiten Durchgang erfüllten beide IPv4-Resolver beide Regeln an denselben vier Sekunden: 12, 27, 42 und 57 nach der vollen Minute, 15 Sekunden auseinander. Dort änderte sich die Umlaufzeit am stärksten, und dort gab es Spitzen: p99 minus Median war mehr als doppelt so groß wie an anderen Sekunden, +46 gegenüber +21 ms zu Cloudflare und +50 gegenüber +22 ms zu Quad9. Im ersten Durchgang, für alle vier Ziele, und über IPv6 im zweiten fand die Regel des Tests kein Muster.

Jeder Wert in Tabelle 1 ist in ganzen ms angegeben. Die Regel verglich die medianen Änderungen vor dem Runden, so erfüllen die 3 und 2 ms von Quad9 „mindestens doppelt“.

Tabelle 2 zeigt die Streuung jeder Messreihe: wie weit die Antworten vom eigenen Median des jeweiligen Ziels im Durchgang entfernt lagen. pN ist die Umlaufzeit, unter der N von 100 Antworten lagen, p10 minus Median ist also negativ. In jeder Messreihe lag p99 22 bis 28 ms über dem Median und die langsamste einzelne Antwort 144 bis 754 ms darüber.

Die Resolver antworten von den nächstgelegenen Standorten ihrer Betreiber, jede Umlaufzeit durchquert also auch das Netz des jeweiligen Betreibers. Wo sich beide IPv4-Resolver im zweiten Durchgang an denselben Sekunden änderten, liegen die Änderungen auf dem Teil des Weges, den beide teilen: das Heimnetz und der Router, die Satellitenverbindung und das Netz von Starlink bis dorthin, wo sich die beiden Routen trennen. Der Test kann diese Teile nicht trennen, und er zeigt nicht, was die Änderungen verursacht hat.

Forschende berichten von Änderungen alle 15 Sekunden, jeweils 12, 27, 42 und 57 Sekunden nach der vollen Minute

Tanveer et al. maßen von vier Starlink-Antennen aus, einer in Westeuropa und drei in den USA (Nordosten, Mittlerer Westen und Nordwesten), jede mit einem per Ethernet angeschlossenen Computer, zu Servern an den Points of Presence (PoPs) von Starlink, die diese Antennen versorgten, mit Millisekunden-Auflösung. Die Forschenden berichten von großen Änderungen der Latenz „at the 12th, 27th, 42nd, and 57th second past every minute“, zu den Sekunden 12, 27, 42 und 57 jeder Minute, gesehen „from all our measured locations for all periods of time“, an allen gemessenen Orten und zu allen Zeiten (arXiv-Preprint, v1, Juli 2023, Abschnitt 3, abgerufen im Oktober 2026). Die Änderungen führen sie auf „a global network controller“ zurück, eine weltweite Netzsteuerung, die jeder Antenne ihren Satelliten zuteilt, und schreiben, dass „these allocations are made every 15-seconds, globally“, diese Zuteilungen also weltweit alle 15 Sekunden erfolgen (Zusammenfassung).

Mohan et al., veröffentlicht auf der ACM Web Conference 2024, maßen von Antennen in Edinburgh und München aus. Das Team fand, dass Starlink „performs network reconfigurations every 15 s“, sein Netz also alle 15 Sekunden neu konfiguriert, und dass diese Neukonfigurationen „globally synchronized and likely independent of satellite handovers“ sind, weltweit synchronisiert und wahrscheinlich unabhängig von Satellitenwechseln (Abschnitt 1). Die Umlaufzeiten waren „comparatively stable within each Starlink reconfiguration interval but potentially changing between intervals“, innerhalb jedes Intervalls also vergleichsweise stabil, zwischen den Intervallen aber möglicherweise anders, und sie änderten sich zwischen Intervallen auch in Zeitabschnitten, in denen die Antenne in Großbritannien nur von einem Satelliten versorgt werden konnte. Die Schlussfolgerung der Forschenden: „Hand-offs between satellites are not the cause of these effects.“ Satellitenwechsel sind also nicht die Ursache dieser Effekte (Abschnitt 6.2; arXiv v2, Februar 2024, abgerufen im Oktober 2026). Dasselbe Team stellte die Arbeit im Juli 2025 bei IRTF Open auf der IETF 123 vor, mit „15-secs reconfigurations are prevalent at all locations“ und „15-secs intervals are globally synchronized“ auf seinen Folien (abgerufen im Oktober 2026).

Im zweiten Durchgang hier fielen über IPv4 die Änderungen beider Resolver auf 12, 27, 42 und 57 Sekunden nach der vollen Minute, die Sekunden, die Tanveer et al. berichteten. Im ersten Durchgang und über IPv6 im zweiten fand die Regel des Tests kein Muster. Die Erklärung für die 15-Sekunden-Änderungen ist die der Forschenden, nicht die dieser Seite.

Starlinks eigene Latenzwerte beruhen auf 15-Sekunden-Mittelwerten. Starlinks Dokument Improving Starlink's Latency sagt, dass Starlink alle 15 Sekunden Messwerte von seinen Routern sammelt und dass diese „15 second average latencies“, die über 15 Sekunden gemittelten Latenzen, seine Median- und Worst-Case-Werte ergeben. Das PDF nennt in seinem Text kein Datum; die Datei wurde im März 2024 erstellt (abgerufen im Oktober 2026). Eine Spitze, die kürzer als 15 Sekunden ist, steckt in einem dieser Mittelwerte.

Denselben Test kannst du auf einem Computer in deinem Netz laufen lassen

Für den Test brauchst du einen Linux-Computer mit iputils ping und Python 3, per Kabel mit deinem Router verbunden.

1. Prüfe vor dem Start und noch einmal am Ende der Stunde, ob seine Uhr synchronisiert ist, wie es der Test tat. Auf einem System mit systemd gibt dieser Befehl yes aus, wenn sie es ist:

   timedatectl show -p NTPSynchronized --value

2. Starte dann die vier Pings gleichzeitig, jeden mit seiner eigenen Datei:

   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

   Jede ping-Zeile ist der Befehl, den der Test für ein Ziel ausführte, nur mit der Umleitung in eine Datei und dem angehängten &. & startet jeden im Hintergrund, sodass die vier nebeneinander laufen, und wait kehrt zurück, sobald alle vier beendet sind. Was die Optionen tun, laut ping(8) (iputils 20250605, abgerufen im Oktober 2026):

   • -D gibt vor jeder Zeile einen Zeitstempel aus, „unix time + microseconds as in gettimeofday“.
   • -O meldet eine Anfrage, die noch auf ihre Antwort wartet, bevor die nächste hinausgeht, ein verlorener Ping hinterlässt also auch eine Zeile. Ohne diese Option kommen die Verlustzahlen als null heraus.
   • -n liefert „numeric output only“, nur numerische Ausgabe, ohne Namensauflösung.
   • -i 0.2 sendet alle 0,2 Sekunden einen Ping. „Only super-user may set interval to values less than 2 ms“: Nur root darf Intervalle unter 2 ms setzen, dafür braucht es also kein root.
   • -w 3600 beendet ping nach 3.600 Sekunden, einer Stunde.

3. Speichere dieses Skript als latency_fold.py. Es nutzt nur die Standardbibliothek von Python 3 und gibt keine Umlaufzeit aus. Für jede Sekunde nach der vollen Minute nennt es die gesendeten Pings, die verlorenen Pings und die mediane Änderung gegenüber der Sekunde davor, auf 0,1 ms genau, in den Spalten second, sent, lost und change_ms, dann eine letzte Zeile mit den vier Sekunden, die die größten Änderungen hatten.

   Das Skript, 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. Wenn die Pings beendet sind, lass es auf jede Datei laufen:

   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

   Auf der eigenen ping-Ausgabe des Tests lieferte dieses Skript in beiden Durchgängen für jedes Ziel dieselben Zeilen pro Sekunde und dieselben vier Sekunden wie das eigene Skript des Tests.

5. Die letzte Zeile nennt immer vier Sekunden. Liegen sie nicht 15 Sekunden auseinander, zeigte die Stunde nach der Regel dieser Seite kein Muster, und die vier Sekunden bedeuten für sich allein nichts. Liegen sie so, vergleicht die andere Hälfte der Regel den Median der Änderungen jeder Minute an diesen vier Sekunden mit demselben Median an den anderen Sekunden, und latency_fold.py gibt diese beiden Werte nicht aus. Seine Spalte change_ms nennt stattdessen den eigenen Median jeder Sekunde, die Werte der vier Sekunden gegenüber der Mitte der anderen 56 sind also eine Annäherung, nicht die Regel selbst, und wenn sie nahe beim Doppelten des Rests liegen, kann die Annäherung auf jeder der beiden Seiten davon landen.

Das sind die iputils-Befehle von Linux; ping auf anderen Systemen nimmt andere Optionen, und diese Seite nennt sie nicht. Über WLAN ist die Funkverbindung in deinem Zuhause ebenfalls Teil jeder Umlaufzeit, und dieser Test hat sie nicht abgedeckt.

901 von 143.462 Pings blieben unbeantwortet, häufiger 12, 27, 42 und 57 Sekunden nach der vollen Minute

Über beide Durchgänge und alle vier Ziele blieben 901 von 143.462 Pings unbeantwortet: 417 von 71.733 über IPv4 und 484 von 71.729 über IPv6. Von den 901 wurden 109 zu den Sekunden 12, 27, 42 oder 57 nach der vollen Minute gesendet; zu diesen Sekunden wurden insgesamt 9.567 gesendet. Das ist das 1,9-Fache der Verlustrate an anderen Sekunden, wo 792 von 133.895 unbeantwortet blieben: das 2,1-Fache über IPv4 und das 1,8-Fache über IPv6. Die meisten verlorenen Pings wurden aber nicht zu diesen Sekunden gesendet: 109 der 901 waren es, etwa 1 von 8.

Diese Zählungen nutzen für jedes Ziel in beiden Durchgängen dieselben vier Sekunden, egal, wie das Urteil der jeweiligen Messreihe ausfiel, sie hängen also nicht davon ab, dass ein Muster gefunden wurde.

Ein Ping ohne Antwort kann auf dem Hinweg, auf dem Rückweg oder am Ziel verloren gegangen sein. Bei keinem der beiden Betreiber verlor ein Resolver ein Mehrfaches der Pings des anderen in derselben Familie, nichts deutet also darauf hin, dass ein Resolver ICMP begrenzt.

Hier nicht getestet

• Spiele, Anrufe und Streams. Keine Anwendung wurde getestet, diese Seite gibt also zu keiner ein Urteil ab.
• Abhilfen. Keine Einstellung, kein Produkt und kein zweiter Anschluss wurde ausprobiert.
• WLAN und andere Anschlüsse. Beide Durchgänge liefen über eine Kabelverbindung, an einem Anschluss zu Hause.
• Die Ursache auf dieser Leitung. Die Erklärung im Abschnitt zur Forschung ist die der Forschenden. Dieser Test kann nicht sagen, warum das Muster im zweiten Durchgang auftrat und nicht im ersten, über IPv4 und nicht über IPv6, oder ob eine weitere Stunde es zeigen würde.
• Die eigenen Statistiken der Antenne, Sichthindernisse und Wetter.
• Die Umlaufzeiten selbst. Jeder Millisekundenwert auf dieser Seite ist eine Differenz, denn eine Umlaufzeit zum nächstgelegenen Standort eines öffentlichen Resolvers sagt, wo dieser Standort liegt. Starlink veröffentlicht eigene Werte, und sein Dokument ist im Abschnitt zur Forschung verlinkt. Starlinks Label-Wert für die typische Latenz in den USA stellt der Satelliten-Internet-Vergleich neben die minimale Umlaufzeit über einen geostationären Satelliten.
• Ausfälle über Tage. Zwei Stunden Pings können nicht zeigen, wie oft ein Anschluss über eine Woche ausfällt.

Mehr dazu im Homelab-Urteil aus allen fünf Tests.