GrandDixence
Danke für die drei Hinweise — ich habe alle geprüft. Kurz zusammengefasst: keiner der lokalen Ansätze bestätigt sich, dafür ist zwischenzeitlich etwas passiert, das die Ursache aus meiner Sicht ziemlich eindeutig eingrenzt.
Messaufbau: kabelgebundener Linux-Host (Debian 13, Standard-TCP-Tuning), Single-Stream-Download per curl, automatisiert alle 2 Stunden seit 04.08. — insgesamt 59 Messreihen.
TCP-Empfangsfenster / japanische Server
Der Test besteht deutlich:
- ftp.iij.ad.jp (RTT 275 ms): 77 Mbit/s
- ftp.jaist.ac.jp (RTT 275 ms): 45 Mbit/s
Für 77 Mbit/s bei 275 ms RTT müssen ca. 2,6 MB gleichzeitig “in flight” sein — Window Scaling funktioniert also nachweislich weit über 64 KB hinaus (tcp_window_scaling=1, tcp_rmem max 6 MB, Autotuning aktiv, cubic, MTU 1500).
Ethernet-CRC-Fehlerzähler (Laufzeit 62 Tage, empfangsseitig)
Messaufbau: kabelgebundener Linux-Host (Debian 13, Standard-TCP-Tuning), Single-Stream-Download per curl, automatisiert alle 2 Stunden seit 04.08. — insgesamt 59 Messreihen.
| Interface | rx_errors | rx_crc_errors | Pakete |
|———————————–|———–|—————|————-|
| Proxmox-Host eno1 (2.5GbE Uplink) | 0 | 0 | 293′828′090 |
| Raspberry Pi 5 eth0 | 0 | 0 | 98′971′169 |
| VM ens18 | 0 | 0 | 47′641′381 |
Auch sämtliche CRC-/FCS-/Alignment-Zähler aus ethtool -S sind 0. (rx_dropped ist auf den Bridge-Interfaces hoch, das sind aber verworfene Multicast-Pakete, keine Fehler.)
Glasfaser
PON-Statistiken des Sagemcom: PON Mode XGS-PON, Connection mode IPOE, Modem Online.
ONT receive power: -13,0 dBm (Spezifikationsbereich ca. -8 bis -28 dBm → ~15 dB Reserve)
ONT transmit power: +5,7 dBm · Transceiver 43 °C / 3,296 V · Laser bias current 11
Ein verschmutzter Stecker zeigt sich genau in einer schwachen Empfangsleistung Richtung -25 dBm. Davon ist
nichts zu sehen. Das 1-Gbit/s-Limit aus dem verlinkten Thread trifft bei mir ebenfalls nicht zu — nach Zürich messe ich konstant ~2′250 Mbit/s (limitiert durch meine 2.5GbE-Karte, nicht durch die Leitung).
Und jetzt das Entscheidende:
Über 5 Tage waren die Werte pro Ziel extrem stabil — aber völlig unterschiedlich zwischen den Zielen (Median aus 59 Messungen):
| Ziel | RTT | Median |
|—————|——-|————–|
| Init7, Zürich | 7 ms | 2′252 Mbit/s |
| Hetzner, DE | 22 ms | 593 Mbit/s |
| Tele2, SE | 38 ms | 18 Mbit/s |
| OVH, FR | 19 ms | 4,9 Mbit/s |
Heute Morgen hat sich OVH dann ohne jede Änderung auf meiner Seite sprunghaft erholt:
- 04.08. 21:43 – 09.08. 08:07 3,1 – 6,3 Mbit/s (ca. 50 Messungen, konstant)
- 09.08. 10:07 34,6 Mbit/s
- 09.08. 12:07 312,7 Mbit/s
- 09.08. 14:07 343,4 Mbit/s
- 09.08. 16:07 175,1 Mbit/s
Gleichzeitig ist Schweden unverändert schlecht geblieben (7–23 Mbit/s, auch heute Nachmittag).
Ein Faktor-70-Sprung bei genau einem Ziel, während ein anderes Ziel gleich schlecht bleibt — und das ohne Änderung an Hardware, Verkabelung, Router oder TCP-Einstellungen. Weder ein Empfangsfenster noch CRC-Fehler noch ein verschmutzter Glasfaserstecker können ziel-selektiv wirken oder sich von selbst um 08:00 morgens reparieren. Das lässt sich meines Erachtens nur durch eine Änderung im Routing/Peering ausserhalb meines Anschlusses erklären.
Die Messungen laufen weiter (neu auch mit dem japanischen Server als Referenz für hohe RTT). Traceroutes zu den betroffenen Zielen liefere ich gerne nach.