Wie dieser Test deine Verbindung misst

Diese Seite beschreibt genau, was PingPacketTest.com sendet, wie daraus die drei Zahlen auf der Startseite werden und — im letzten Abschnitt — was diese Zahlen nicht sagen können. Wenn du nur einen Teil liest, dann den letzten.

Was der Test wirklich sendet

Der Browser öffnet einen WebRTC-DataChannel zu einem der Messserver und schickt darüber kleine Pakete. Der Kanal ist mit ordered: false und maxRetransmits: 0 konfiguriert, und genau das ist der Punkt: Der Browser darf ein Paket weder erneut senden noch eines zurückhalten, weil ein Vorgänger fehlt. Damit ist es echtes UDP — dieselbe Übertragungsart, die praktisch jedes Onlinespiel für seinen laufenden Datenverkehr benutzt.

Jedes Paket trägt eine fortlaufende Nummer und den Zeitpunkt seines Abgangs, aufgefüllt auf die Paketgröße des gewählten Spiels. Der Server tut damit genau eine Sache: Er schickt es unverändert zurück. Die Rundlaufzeit wird deshalb vollständig in deinem Browser gegen eine einzige Uhr gemessen — es gibt keinen Synchronisationsfehler zwischen zwei Maschinen. Ein Paket, dessen Echo nie eintrifft, zählt als verloren.

Warum ein Speedtest diese Frage nicht beantworten kann

Ein Speedtest im Browser misst Bandbreite über TCP. TCP ist dazu gebaut, genau das Problem zu verstecken, das du suchst: Geht ein Paket verloren, überträgt TCP es still erneut, und was am Ende übrig bleibt, ist ein etwas kleinerer Durchsatzwert. Der Verlust hat stattgefunden, die Verbindung hat sich erholt, und die Zahl am Ende lautet „92 Mbit/s“.

Ein Spiel macht das nicht. Es schickt ein Positionsupdate in festem Takt und geht weiter. Geht eines verloren, wird es nicht nachgereicht — bis es ankäme, würde es beschreiben, wo du einmal warst. Deshalb kann eine Leitung jeden Speedtest bestehen und trotzdem Rubberbanding erzeugen: Die Bandbreite stimmt, einzelne Pakete kommen nicht an. Über eine unzuverlässige Übertragung zu messen ist der einzige Weg, das zu sehen, und der Grund, warum es dieses Werkzeug gibt.

Taktrate: warum das gewählte Spiel die Messung verändert

Ein Spielserver verarbeitet Eingaben nicht fortlaufend. Er schreibt die Welt in festen Schritten fort — Ticks — und der Client sendet und empfängt in passender Frequenz. Counter-Strike 2 fährt seine offiziellen Server mit 64 Ticks pro Sekunde, Valorant mit 128, Apex Legends mit 20. Diese Rate bestimmt zweierlei: wie oft Pakete über deine Leitung gehen, und wie teuer eine gegebene Verzögerung ist. Bei 128 Ticks sind 60 ms Rundlaufzeit fast acht Serverupdates, bei 20 Ticks knapp eines.

Ein Spiel hier auszuwählen ist deshalb keine Beschriftung des Ergebnisses. Es ändert Senderate und Paketgröße der Messung selbst, sodass das Verkehrsmuster auf deiner Leitung dem entspricht, was dieses Spiel wirklich erzeugt. Welche Rate für welchen Titel gilt, woher sie stammt und ob sie eine Entwicklerangabe oder eine Schätzung ist, steht in der Tickraten-Datenbank — und sie ist als Schätzung markiert, wo sie eine ist.

Wo die Messserver stehen

Es sind vier: New York, San Jose, Frankfurt und Singapur. Dein Browser misst standardmäßig gegen den nächstgelegenen, und du kannst manuell umschalten, um eine bestimmte Route zu prüfen — eine deutsche Leitung gegen Singapur zu messen ist sinnvoll, wenn du dort spielst. Der Server, gegen den gemessen wurde, steht auf jedem Ergebnis, denn ein Ping-Wert ohne Ziel bedeutet nichts.

Wie die Zahlen entstehen

Die erste Sekunde zählt nicht. Jede Messung beginnt mit einer Aufwärmsekunde: Pakete werden gesendet, aber nichts davon wird gezählt oder gezeichnet. Einen Verbindungsaufbau gibt es nicht umsonst — die ersten Pakete auf einem Weg sind langsamer, und die Route kann sich währenddessen noch ändern —, und diese Kosten gehören zum Verbindungsaufbau, nicht zu deiner Leitung. Das ist in der Netzwerkmessung üblich, und es steht hier, statt stillschweigend zu passieren: Eine nicht offengelegte Aufwärmphase ist nichts anderes als eine schöngerechnete Zahl. Sie gilt ausschließlich am Anfang. Bricht deine Verbindung mitten in der Messung ein, steht das in voller Höhe im Ergebnis.

Der Ping ist ein Median, mit der vollen Spanne dahinter. Das Diagramm zeichnet einen Punkt je 100 ms. Bei der Taktrate eines Spiels können darin viele Pakete liegen — bei 128 Hz etwa dreizehn —, und der Punkt zeigt deren Median, damit die Linie lesbar bleibt. Das schattierte Band dahinter ist das niedrigste und das höchste Paket derselben Scheibe. Es wird nichts wegge­glättet: Wenn ein Paket in einer Scheibe 400 ms gebraucht hat, reicht das Band bis 400 ms, auch wenn die Linie flach bleibt. Zoomst du heraus, werden Punkte zusammengefasst, und die Gruppe trägt den höchsten Wert, den sie enthält — eine Spitze verschwindet also nie beim Herauszoomen.

Paketverlust wird niemals gemittelt. Verlust ist eine Liste von Ereignissen, keine Messreihe. Ein einzelnes verlorenes Paket zeichnet seine Markierung auf jeder Zoomstufe in voller Stärke. Ein als verloren gezähltes Paket, das später doch eintrifft, bekommt seinen Verlust zurückgenommen — es war spät, nicht weg.

Jitter wird über feste Ein-Sekunden-Fenster gemessen (die Standardabweichung der Rundlaufzeiten in jeder Sekunde, über die Messung gemittelt). Stattdessen den Abstand aufeinanderfolgender Pakete zu nehmen, würde den Wert vom gewählten Spiel abhängig machen: Bei 128 Hz liegen zwei Pakete 7,8 ms auseinander, bei 10 Hz volle 100 ms. Feste Fenster bedeuten, dass dieselbe Leitung bei jeder Taktrate denselben Jitter meldet.

Eine Rundlaufzeit über 1000 ms zählt als Verlust. Für ein Spiel ist das die ehrliche Lesart: Ein Paket, das so spät kommt, hat keinen Wert mehr.

Wie Urteil und Perzentil zustande kommen

Das Urteil nimmt die schlechteste der drei Zahlen, nicht den Durchschnitt. Eine Verbindung mit 20 ms Ping und 2 % Paketverlust ist keine gute Verbindung, und das wegzumitteln wäre genau die Beschönigung, die der Rest dieser Seite entfernt. Die Größe, die das Urteil entscheidet, ist auch die, die im Satz genannt wird — du kannst sie also gegen das Diagramm prüfen.

Die Jitter-Schwellen sind aus der Taktrate abgeleitet, nicht gewählt. Ein Server mit 128 Hz aktualisiert alle 7,8 ms, einer mit 30 Hz alle 33 ms. Jitter über einem ganzen Tick-Abstand heißt, dass deine Eingaben nicht mehr in einem vorhersehbaren Tick landen — die Grenze für „gut“ ist deshalb ein halber Tick, die für „spielbar“ ein ganzer. Beide sind bei 15 bzw. 30 ms gedeckelt: Für ein 10-Hz-Spiel würde die reine Tick-Rechnung 90 ms Jitter für unbedenklich erklären, was für die Taktrate stimmt und für einen Menschen nutzlos ist.

Die Ping-Schwellen sind eine Wertung, und hier steht sie. Unter 30 / 60 ms ab 100 Hz, 40 / 80 ms bei 60–64 Ticks, 60 / 100 ms bei 30 Ticks, 80 / 150 ms darunter. Höhere Taktraten lösen kleinere Zeitunterschiede auf, dieselbe Laufzeit kostet dort also mehr davon. Beim Paketverlust ist die Schwelle überall gleich: alles über null heißt „verliert Eingaben“, über 1 % heißt „nicht gut genug“. Ein verlorenes Paket ist bei jeder Taktrate eine verlorene Eingabe.

Das Perzentil vergleicht dich mit hier gelaufenen Messungen, nicht mit dem Internet. „Besser als 72 % der hier gegen Frankfurt gelaufenen Tests“ heißt genau das: Von den gespeicherten abgeschlossenen Messungen gegen diesen Server hatten 72 % einen höheren Ping als deine. Es ist keine Aussage über alle Verbindungen in einem Land — wer einen Paketverlust-Test aufruft, ist keine Zufallsstichprobe, und viele kommen gerade deshalb, weil etwas nicht stimmt. Die Tabelle wird einmal täglich neu berechnet, aus abgeschlossenen Messungen von mindestens zehn Sekunden aus dem letzten Jahr; ein Server mit weniger als 500 gespeicherten Messungen bekommt lieber gar kein Perzentil als ein wackliges.

Was die NAT-Typ-Zeile bedeutet

Während der Messung nennt die Statuszeile über dem Diagramm die Art der Netzwerkverbindung, über die gemessen wird. Das ist weder geraten noch nachgeschlagen: Es ist der Typ des ICE-Kandidatenpaars, das die Verbindung tatsächlich benutzt — host für einen direkten öffentlichen Weg, server-reflexiv für eine Verbindung durch ein NAT, das trotzdem eine direkte Route zugelassen hat, und relay für eine, die nur über einen Vermittler zustande kam. Angezeigt wird das als Offen, Moderat und Streng, weil das die Wörter aus den Konsolenmenüs sind — und weil es in der Praxis übereinstimmt.

Zwei ehrliche Grenzen. Ein Browser kann den NAT-Typ, den eine Spielkonsole in ihren eigenen Einstellungen anzeigt, nicht auslesen; das hier ist die entsprechende Beobachtung, nicht diese Zahl. Und wenn UDP vollständig blockiert ist, steht das da statt eines Typs — dann kam nie ein Kandidatenpaar zustande. Die NAT-Typ-Seite erklärt, was bei welchem Ergebnis zu tun ist (englisch).

Wie Aussetzer und Verfügbarkeit gezählt werden

Ab einer Minute Laufzeit sagt das Werkzeug nicht mehr nur, was die Leitung gerade tut, sondern was sie über diese Zeit getan hat. Ein Aussetzer ist ein Abschnitt von mindestens einer vollen Sekunde, in dem in jedem 100-ms-Fenster mindestens ein Paket verloren ging. Die Verfügbarkeit ist der Anteil der gemessenen Zeit, der nicht in einem solchen Abschnitt lag.

Zwei bewusste Entscheidungen stecken darin. Die Untergrenze von einer Sekunde gibt es, damit einzelne verlorene Pakete nicht zu Ausfällen aufgeblasen werden — ein einzelnes fehlendes Paket wird als Paketverlust gemeldet, und das ist es auch. Und die Verfügbarkeit ist ein Anteil der gemessenen Zeit, nicht der Pakete: Eine Leitung, die zu 99,98 % antwortet, aber zweimal am Abend für vier Sekunden verstummt, hat genau den Fehler, den ein Spiel merkt und den ein Mittelwert verdeckt. Die Werte werden einmal berechnet, wenn die Messung endet, und mit dem Ergebnis gespeichert — die Zusammenfassung auf einer geteilten Seite und die im PDF-Bericht sind deshalb immer dieselben Zahlen.

Was dieser Test nicht sagen kann

Jede Messung hat eine Grenze. Das sind unsere, und keine davon ist ein Grund, den Test nicht zu machen — sie sind der Unterschied zwischen einem Ergebnis, mit dem man arbeiten kann, und einem, das man nur zitieren kann.

Gemessen wird der Weg zu unserem Server, nicht der zum Spielserver. Ist die Route nach Frankfurt sauber und dein Spiel stockt trotzdem, kann das Problem auf dem Stück zwischen deinem Anbieter und dem Rechenzentrum des Spiels liegen, das kein Browser erreicht. Was ein sauberes Ergebnis hier belegt: Deine eigene Leitung, dein Router und die ersten Abschnitte deines Anbieters waren in diesem Moment in Ordnung — und genau das ist die Hälfte, für die ein Anbieter zuständig ist.

Eine Rundlaufzeit verrät nicht, in welcher Richtung ein Paket verloren ging. Wir senden ein Paket und warten auf sein Echo. Kommt es nicht zurück, hat es jemand verworfen — auf dem Hinweg oder auf dem Rückweg, und von einem Ende aus lässt sich das nicht unterscheiden. Werkzeuge, die aus einem Browser heraus eine Richtung behaupten, schließen sie, sie messen sie nicht.

Er sagt nicht, welcher Zwischenschritt schuld ist. Das ist eine Messung von Ende zu Ende, kein Traceroute. Sie belegt, dass es auf der Strecke als Ganzes Verlust oder Verzögerung gibt. Sie einzugrenzen erfordert Zugriff auf die Zwischenstationen, den ein Browser nicht hat — und deshalb ist der Bericht, den du exportieren kannst, an die Stelle adressiert, die ihn hat.

Ist UDP blockiert, fällt der Test auf eine TCP-Verbindung zurück. Manche Firmennetze und VPN-Konfigurationen lassen einen WebRTC-DataChannel gar nicht erst zustande kommen. Statt nichts anzuzeigen, misst der Test dann über einen WebSocket — also über TCP, das erneut überträgt. Auf einer solchen Verbindung bleibt der Ping-Wert aussagekräftig, der Paketverlust fällt aber niedriger aus als die Wirklichkeit, weil die Neuübertragungen genau so vor uns verborgen bleiben, wie weiter oben beschrieben. Dasselbe gilt, wenn deine Verbindung nur über einen Relaisserver (TURN) zustande kommt: Der Weg ist dann länger als deine echte Strecke, und der Ping enthält diesen Umweg.

Gemessen wird deine Verbindung, wie sie gerade ist — einschließlich allem, was sie sonst noch benutzt. Ein Download in einem anderen Fenster, eine Konsole, die im Hintergrund aktualisiert, oder jemand im Haushalt, der streamt, landen alle in deinem Ergebnis. Das ist ein Vorteil, wenn du Bufferbloat suchst, und eine Falle, wenn du nicht daran denkst. Sieht eine Messung schlecht aus, wiederhole sie mit allem anderen ausgeschaltet, bevor du Schlüsse ziehst.

Ein Browser ist keine Echtzeitumgebung. Das Timing läuft über einen eigenen Web Worker statt über einen Timer im Hauptstrang, genau damit Zeichenarbeit die Senderate nicht verzerrt — aber ein Browser wird weiterhin vom Betriebssystem eingeplant. Eine stark ausgelastete Maschine, ein aggressiv gedrosseltes Notebook oder ein Hintergrundtab können ein bis zwei Millisekunden Jitter hinzufügen, die deine sind und nicht die deines Anbieters. Gegenüber einem echten Netzwerkfehler ist das wenig, aber es ist nicht null.

Es ist kein Bandbreitentest und kann keinen ersetzen. Die Pakete hier sind absichtlich winzig. Eine Verbindung kann diesen Test einwandfrei bestehen und trotzdem zu langsam sein, um irgendetwas herunterzuladen — das ist kein Widerspruch, sondern eine andere Frage.

Nichts auf dieser Seite ist eine Zufallsstichprobe des Internets. Wer einen Paketverlust-Test aufruft, hat ganz überwiegend ein Problem. Jeder Vergleich, den wir veröffentlichen — die Perzentilzeile, die Auswertungsseite — sagt „von den hier gelaufenen Tests“ und meint das auch so. Eine Zahl von dieser Seite als „die durchschnittliche Verbindung in Land X“ zu zitieren, wäre falsch, und wir sagen das lieber, als es stillschweigend geschehen zu lassen.

Weiter von hier

Die Tickraten-Datenbank listet jedes unterstützte Spiel mit der Rate, die dieser Test sendet, ihrer Quelle und der Angabe, ob sie belegt oder geschätzt ist. Die Auswertung aller Messungen zeigt, wie sich die hier gelaufenen Tests verteilen, mit demselben Vorbehalt wie oben (englisch). Die Live-Statistik zeigt, was gerade gemessen wird, die Seite über dieses Projekt erklärt, wer es betreibt (englisch), und der Test selbst startet, sobald du ihn öffnest.

Jede abgeschlossene Messung lässt sich als PDF-Bericht exportieren — Zeitstempel, Route, Diagramm und eine Kurzfassung dieser Methodik — zum Weitergeben an einen Anbieter. Eine IP-Adresse steht nicht darin.

Fragen, Korrekturen oder ein Methodikfehler, den du gefunden hast: info@pingpackettest.com. Korrekturen sind willkommen und werden gemacht.