Ein Zugriff ueber Laendergrenzen, der ploetzlich kriecht, ein Sprachgespraech, das immer wieder abbricht, eine Spielverbindung mit schwankender Verzoegerung: all das teilt ein Merkmal, naemlich dass niemand sagen kann, auf welchem Abschnitt es klemmt. WinMTR legt ping und traceroute in ein Fenster und breitet den ganzen Pfad als Tabelle je Station aus, sodass die Stelle des Problems zeigbar wird.

Warum Daten je Station noetig sind

Zwischen dem eigenen Rechner und einem Zielserver laufen Pakete meist durch ein Dutzend oder gar zwei Dutzend Zwischenpunkte: den Router zu Hause, die Anschlusstechnik des Anbieters, Vermittlungsknoten im Backbone, den Eingang des fernen Rechenzentrums. Stockt oder verliert einer davon, wird das ganze Erlebnis schlechter, doch von aussen sieht alles gleich aus, naemlich langsames Laden, Ruckeln, ein abbrechender Strom.

Ping allein sagt, ob das Ziel antwortet und wie viele Millisekunden es im Mittel braucht. Traceroute allein sagt, welche Knoten der Pfad kreuzt. Keines von beiden beantwortet, ab welcher Station es schlechter wird. Beide Zahlen in eine Tabelle legen und Station fuer Station vergleichen, und die Frage hat eine Antwort.

Eine Tabelle, die sagt, welche Station schuld ist

Der Hauptteil der Oberflaeche ist eine Tabelle, die sich laufend erneuert. Jede Zeile ist eine Station auf dem Pfad, und von links nach rechts stehen Nummer, Verlust in Prozent, Zahl der gesendeten Sonden, mittlere Antwortzeit sowie Name und IP Adresse des Knotens. Die Werte aktualisieren sich im Sekundentakt, die Tabelle folgt.

Gelesen wird meist bei der Verlustspalte beginnend. Zeigt eine Zeile ploetzlich deutlichen Verlust und halten die Zeilen danach dasselbe Niveau, sitzt die Stoerung an dieser Station oder oberhalb von ihr. Kehren die folgenden Zeilen zurueck, steckt eher die Antwortpolitik des Knotens dahinter. Die Dokumentation erwaehnt ausdruecklich, dass manche Router ICMP Anfragen ignorieren und solche leeren Zeilen normal sind.

Mitlaufende Beobachtung und wie gezaehlt wird

Neben der Tabelle kreist die offizielle Funktionsliste um wenige Punkte. Mitlaufende Beobachtung heisst, dass das Werkzeug fortlaufend Sonden zum Ziel schickt und die Statistik weiter auffuellt; die Verlusterkennung findet, auf welchem Abschnitt Pakete verloren gehen; die Latenzverfolgung nennt Unter und Obergrenze sowie Mittelwert je Station, woraus sich die Stelle der Schwankung bestimmen laesst.

Die Aussage der Statistik haengt an der Zahl der Stichproben. Die Dokumentation empfiehlt, einen Durchlauf ein bis zwei Minuten laufen zu lassen, denn je mehr Sonden, desto ruhiger werden Verlust und Latenz. Wenige Sonden ueber ein paar Sekunden lassen sich von einem kurzzeitigen Ausschlag leicht taeuschen.

Das Ergebnis weitergeben

Bei einer Stoerung muss die Feststellung meist zum Anbieter oder zum Support des Rechenzentrums. WinMTR kopiert das Ergebnis in die Zwischenablage oder schreibt es als Text oder HTML Datei, sodass sich ein vollstaendiger Stationsbericht einem Ticket beilegen laesst. Das spart das Abschreiben der Tabelle und laesst die Gegenseite die Rohdaten sehen.

Ohne Installation, und mit Kommandozeile

Die Einrichtung bleibt leicht. Das offizielle Paket ist ein Archiv: entpacken, die Datei darin starten, ohne Assistenten, ohne Administratorrechte, ohne Eintrag in der Registrierung. Die Dokumentation merkt an, dass sich die Datei in ein Systemverzeichnis kopieren laesst, wonach sie direkt von der Kommandozeile aufrufbar ist.

Die Kommandozeile deckt skriptgesteuerte Ablaeufe ab. Neben dem Fenster bietet das Werkzeug einen vollstaendigen Satz Parameter, sodass eine Stapeldatei oder ein Skript Tests gegen ein festes Ziel starten und die Ergebnisse fuer einen langen Vergleich sammeln kann.

Das Projekt und seine offene Lizenz

Die Zeitachse ist lang. Das Projekt entstand im Jahr 2000 durch Vasile Laurentiu Stanimir, zunaechst als Windows Fassung von Matt Traceroute aus der Linux und UNIX Welt, woher auch das MTR im Namen kommt. Seither wird es unter GPL v2 mit offenem Code veroeffentlicht, die offizielle Seite wurde im November 2025 umgestellt, und die Entwicklung zog zugleich auf eine oeffentliche Plattform.

Betreut wird es derzeit von Dragos Manac. Sowohl die Seite als auch die Notizen im Ablageort erwaehnen, dass weiter Entwickler gesucht werden, die mitpflegen. Fuer ein kleines Werkzeug, das seit ueber zwanzig Jahren laeuft, ist dieser Satz selbst ein Bild seines Zustands.

Wann man es hervorholt

Der passende Fall ist klar: ein Netz mit anhaltenden Auffaelligkeiten, bei dem das Problem einem bestimmten Abschnitt zugeordnet werden muss. Die Aussage haengt an ausreichender Messzeit, deshalb taugt es eher als Werkzeug zur Beweissicherung waehrend einer Untersuchung denn als schneller Geschwindigkeitstest.

Ping und traceroute in eine Tabelle je Station legen und sie laufend erneuern: WinMTR loest ein noch immer haeufiges Raetsel mit einem Ansatz, der sich in ueber zwanzig Jahren kaum geaendert hat.

In der Praxis zuerst den Test auf ein bis zwei Minuten strecken, damit die Werte zur Ruhe kommen, dann vergleichen, an welcher Station Verlust auftritt und wie die folgenden Knoten sich verhalten, um zwischen Leitungsfehler und Antwortpolitik zu unterscheiden. Ist die Auffaelligkeit bestaetigt, den vollstaendigen Bericht per Export an das Ticket haengen.