Belege, die dein Provider nicht wegwischen kann
„Abends ist mein Internet langsam“ ist ein Gefühl, und der Support ist darauf trainiert, Gefühle mit einem Router-Neustart zu beantworten. Eine Zahl mit Ort und Uhrzeit ist ein anderes Gespräch: Paketverlust beginnt jeden Abend nach neun an meinem dritten Hop, hier sind die Messläufe. Drei Messungen leisten das — wo der Verlust beginnt, wie sich die Latenz unter Last verhält und wie weit und wie instabil die Server sind, die du wirklich nutzt — und seit NetDiag+ 1.4.6 lässt sich jede davon als reiner Text exportieren, den du in ein Ticket, einen Forumspost oder das Formular der Regulierungsbehörde einfügen kannst.
Drei Messungen, die Ort und Zeit benennen
- Finde den Verlust mit MTR. Eine Traceroute, die jeden Hop dauerhaft anpingt, zeigt, wo Pakete zu verschwinden beginnen. Verlust, der an einem Hop beginnt und bis zum Ende bestehen bleibt, ist echt, und dieser Hop benennt das verantwortliche Netz. Verlust an nur einem Hop, der am nächsten verschwindet, ist dieser Router, der seine eigenen Antworten drosselt — normal, kein Beleg. Zur schlechten Stunde laufen lassen und den Hop notieren.
- Ergänze Latenz unter Last und die Latenztabelle. Ein Bufferbloat-Test zeigt, wie stark die Latenz bei belegter Leitung steigt und in welche Richtung: eine Upload-Spitze zeigt auf deinen eigenen Router, eine Download-Spitze auf die Technik des Providers — und diese Richtung entscheidet, wessen Problem es ist. Das Latenz-Dashboard ergänzt Median, Jitter und Verlust zu den benannten Servern, die du nutzt, und misst deinen Router zuerst — damit niemand dein WLAN beschuldigen kann, wenn es sauber ist.
- Als Text exportieren, zur richtigen Stunde, mehr als einmal. Jedes Werkzeug hat Teilen → Textbericht: Ziele, Zeitstempel, jede Zahl. Ein Lauf beweist nichts; drei zur schlechten Stunde an verschiedenen Tagen plus einer zur ruhigen Stunde als Kontrolle sind ein Muster. Das Bufferbloat-Trenddiagramm behält die schlimmste Spitze jedes Laufs über 7, 30 oder 90 Tage, sodass das Muster ohne Notizen sichtbar wird. Der Verlauf behält alles, was du gemessen hast.
Kostenlos · 27 Werkzeuge · Einmalkauf entfernt Werbung · kein Abo
Fragen, die wirklich gestellt werden
Was gehört konkret ins Ticket?
Datum und Uhrzeit jedes Laufs. Der Hop, an dem der Verlust beginnt, und sein Prozentsatz. Latenz im Leerlauf gegen Latenz unter Download und unter Upload. Median und Jitter zu zwei oder drei Servern, die euer Haushalt nutzt. Welcher Test die Kontrolle war. Alles als Text eingefügt, nicht beschrieben — ein Techniker kann mit einer Hop-Liste arbeiten, nicht mit „es ruckelt“.
Der Support sagt, die Leitung sei in Ordnung. Lügen die?
Meist nicht. Ihre Tests prüfen Signalpegel, Fehlerzähler und Durchsatz, und all das kann perfekt sein, während eine Warteschlange 300 ms hinzufügt oder ein überlasteter Peering-Link um 21 Uhr 2% der Pakete verwirft. Du misst etwas, das sie nicht messen. Sag das, und gib ihnen die Zahlen.
Screenshots oder Text?
Text. Er lässt sich durchsuchen, zitieren, in ein internes Tool einfügen und an den Techniker weiterleiten, der wirklich etwas repariert; ein Screenshot nicht. Text überlebt auch die Bildkompression eines Forums und das Webformular einer Behörde. Die Screenshots behältst du für dich.
Wie viele Läufe braucht ein Fall?
Genug, um zu zeigen, dass das Problem wiederholbar und zeitgebunden ist. Drei Läufe zur schlechten Stunde an zwei oder drei Tagen plus einer zur guten Stunde, der sauber zurückkommt, ist das Minimum, das aus einer Beschwerde einen Bericht macht. Ist auch der Lauf zur guten Stunde schlecht, ist die Ursache keine Überlastung — auch das ist nützlich.
Wird dadurch wirklich etwas repariert?
Es bringt das Ticket von der ersten Ebene zu jemandem, der eine Hop-Liste lesen kann — der Schritt, an dem es meist hängt. Wo es eine Regulierungsbehörde gibt, fragen die Beschwerdeformulare genau danach: Daten, Messungen, was der Provider geantwortet hat. Belege garantieren keine Reparatur; sie nehmen die Gründe für ein Nein.
Die stärkste einzelne Zahl in all dem ist die Latenz unter Last. Weiter: welcher Server weit weg ist und welcher instabil →