Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Update: Die ~5000 FEC-Fehler pro Minute, werden wahrscheinlich vom RJ11/RJ45 Adapter verursacht. Ich habe ein neues Kabel angeschlossen, aber die Anzahl der Fehler liegt immer noch bei ~5000 pro Minute.
Wir haben jetzt knapp 15.00 Uhr. Mein Ping ist auffällig niedrig (sehr stabil) und die Anwendung läuft wieder deutlich schlechter als heute morgen.
Das aussagekräftigste Monitoring für Ursachen im öffentlichen Netz findet extern statt. Das passende tool dafür ist smokeping, das von Extern (einem Freund) auf die DynDNS des eigenen Anschlusses beobachtet. Für smokeping reicht ein RaspberryPi aus. Die DNS-Namensauflösung sollte man dabei im Blick behalten, deshalb habe ich zusätzlich auch die IP-Adresse überwacht (und ggfs. geändert).
SmokePing ist ein leistungsstarkes Open-Source-Tool zur Überwachung der Netzwerkperformance, das Latenz (Ping-Zeiten), Paketverlust und Jitter misst, indem es regelmäßig Ziel-Hosts anpingt und die Ergebnisse mit RRDtool in interaktiven Graphen visualisiert, um Netzwerkprobleme wie Überlastung oder Ausfälle zu identifizieren. Es besteht aus einem Daemon zur Datenerfassung und einem Web-Interface zur Darstellung, wodurch es sowohl die Verbindung zum Internetanbieter als auch zu lokalen Geräten überwachen kann.
Hier im Thread wurde das Stichwort "Paketverlust" nur einmal in #96 erwähnt und PingTools (Monitoring) bereits genannt. Pingplotter.com wurde mehrfach erwähnt, ist ein grafisch ansprechendes Tool zum Kauf und kann in der Testperiode (30 Tage, inzwischen abgelaufen) genutzt werden. Meine Empfehlung für Windows ist von Nirsoft.net das Tool PingInfoView (für internes Monitoring immer noch im Einsatz). Auch Peering #137 hatte ich auf meinem Verdachtszettel.
Das A und O bei externen Paketverlusten ist ein ordentliches Monitoring, auch um zw. Paketverlusten auf Layer 1/2 (Technik, Hardware) und auf Layer 3 (Überlast) unterscheiden zu können. Zusammen mit traceroute ergibt sich ein belastbares Monitoring als starke Argumentation beim Vertragspartner / Netzbetreiber (Telekomhilft), um über die Brandmauer zur Kundenabwehr (Servicehotline) zu den wirklichen Fachleuten durchgereicht zu werden. Abhilfe kann im öffentlichen Netz nur dein Vertragspartner / Netzbetreiber schaffen. Für dich bleibt trotz eigenem Monitoring und Analyse das öffentliche Netz eine black box, an dem du nichts verändern kannst. Ein Anbieterwechsel bringt nur mit eigenem Netzbetrieb Besserung für dich. Das hast du ausreichend recherchiert und ausgeschlossen.
Als Erfahrung aus meinem Abenteuer habe ich mir diese Merksätze formuliert. hth
Paketverlust auf Layer 1/2 hat eine technische Ursache (Defekt).
Paketverlust auf Layer 3 ist immer einer (Über-)Last geschuldet, z.B. in der Route.
Paketverlust auf höheren Layern wird in der Anwendung vom user "gefühlt".
Paketverlust auf den unteren Layern kann kann man messen und analysieren.
ICMP-Echo Pakete müssen NICHT beantwortet werden. (z.B. bei traceroute)
Die adressierten Netzelemente können auf die Beantwortung verzichten.
Nicht adressierte Netzelemente können auf die Bearbeitung verzichten, nicht auf die Weiterleitung.
Ein IP-Netz (ohne Defekt auf Layer 1/2) verliert keine ICMP-Pakete!
Außer, wie die BNetzA ausführt, bei Überlast (Layer 3).
Ich werde mich mit dem Thema auf jeden Fall mal auseinandersetzen.
Jetzt gerade (18.30 Uhr) sind Echtzeitanwendungen wieder komplett unbrauchbar. Es ist als würden meine Aktionen zwar auf meinem Clienten (Bildschirm) ausgeführt, aber nicht auf dem AWS-Server ankommen.
Es fühlt sich so an, als würde etwas mit den Paketen passieren.
Ich hatte damals (Intel 8700K Zeiten) ein ähnliches Problem und dort war es die Packet-Coalescing Funktion der Netzwerkkarte. Nach dem deaktivieren, waren alle Probleme gelöst. Leider funktioniert es jetzt nicht (völlig anderes System). Ich habe mit sämtlichen Optionen der NIC rumgespielt, welche teilweise auch Wirkung zeigen, aber sobald DIESES Problem aktiv ist, hilft nichts mehr.
Das ist der Win11 "Not Support Power Saving" Treiber. Hat es mit der anderen Variante Probleme gegeben?
Es gibt auch noch den Win10/Win11 (NDIS) Treiber. Wurde dieser Treiber jemals vorher genutzt und wenn ja mit welchem Ergebnis?
Gestern lief es nicht gut. Es lief sogar außerordentlich schlecht. Dann gegen 02.30 Uhr nachts, als hätte jemand einen Schalter umgelegt, lief es plötzlich wieder bestens.
Wenn man ein paar Tage am Stück mit diesem Problem zu kämpfen hat, dann fällt es nicht so auf, aber sobald es besser ist, merkt man sofort, dass sich jede Bewegungen, jede Handlung, einfach alles flüssiger anfühlt.
Es ist zu 100% das Netz.
Daraus ergibt sich die Frage: Wie überbrücke ich - so - die Zeit bis zum FTTH-Anschluss?
EDIT:
Wir bekommen wohl einen FTTH XGS PON Anschkuss über ONT oder so.
Da in Ddorf die Funknetzabdeckung besser sein dürfte als in ländlichen Umgebungen, einfach einmal in einen W1220 investieren (ca.15€, Bucht/Kleinanzeigen). Eine SIM rein und als Fallback an der Fritz!Box konfigurieren. Wie gut das dann bei den jeweiligen Echtzeitanwendungen funktioniert, kann man nur austesten.
Ich habe seit 2 Tagen wieder das Kabel der FritzBox 5690 Pro dran und die FEC-Fehler sind deutlich zurückgegangen.
Aktuell sind es ~1072 FEC-Error pro Minute bzw. ~17 FEC-Error pro Sekunde.
Was ich anders gemacht habe? Ich habe das Kabel immer wieder in den RJ45/RJ11 Adapter gesteckt, abgesteckt, wieder eingesteckt usw. Scheint geholfen zu haben.
Ich habe die letzten Tage meine Echtzeitanwendungen aufgezeichnet und dabei ist mir etwas aufgefallen, was kein Zufall sein kann. Es ist mir auch vorher aufgefallen, aber jetzt als Video, kann ich es klar und deutlich sehen.
Man kann eine Info-Bar einschalten, wo diverses Zeug wie Latenz, Tickrate usw. angezeigt wird.
Während die Echtzeitanwendung läuft, zeigt die Anwedung folgende Werte an:
Bandbreite Inbound: 400-600 kbps (~500 kbps im Durchschnitt)
Bandbreite Outbound: 120-160 kbps (~150 kbps im Durchschnitt)
Ich starte die Echtzeitanwendung und zunächst läuft alles gut. Die Anzeige für Bandbreite Outbound zeigt alles mögliche zwischen 120 und 160 kbps an. Nach ein paar Minuten, sinkt diese auf 40-80 kbps und dann funktioniert nichts mehr wie es sollte.
Ich habe heute bei meinem Nachbarn die Echtzeitanwendung installiert und dort ist es 1:1 das gleiche.
Ich kann mir aber nicht erklären, wieso das so ist. Die Anzeige für Paketloss bleibt bei 0% in beide Richtungen.
Pünktlich zum Wochenende läuft es hier wieder total beschissen.
Speedtest zeigt auch nur 10 MBit im Upload.
Ich wechsel zu net.D
Selbst wenn es nichts bringt. Die von O2 reagieren auf nichts. Tickets werden nicht bearbeitet.
Ich verstehe auch nicht wirklich wie ein FTTC-Anschluss so ausgelastet sein kann. Gefühlt haben hier 9 von 10 Haushalte einen Docsis-Anschluss. Mein DSLAM ist laut Techniker quasi leer. Ich verstehe hier nichts mehr.
Ich vermute, dass es an der Telekom-Infrastruktur liegt.
EDIT:
1 Tag später.
Sobald die Dunkelheit eingebrochen ist, funktionieren Echtzeitanwendungen schon wieder nicht richtig.
Speedtest zeigt im Download um die 190 MBit mit hohen Latenzen (Download-Latenz), was ich so bewerte, dass die Leitung ausgelastet ist. Sonst sind diese immer sehr niedrig.
Mein neuer ISP (net.d) hat meinen Vertrag bei O2 gekündigt. Ab März bin ich dann bei net.d. Ich erwarte keine Verbesserung der Leitung, dafür aber eine Verbesserung im Umgang mit Problemen. Mal schauen.
Um mein Problem etwas verständlicher Auszudrücken: Meine Echtzeitanwendung zeigt 9ms an, aber es ist, als wären es min. 200ms.
@stoney Ich wollte in #155 eigentlich nur einen Link posten, aber der Link wird jetzt "verunfallt" dargestellt. Hat es im Forum Änderungen gegeben oder warum wird der Link so komisch dargestellt?
Der Anbieter ist neu und hatte wohl auch eingeräumt, dass am Anfang nicht alles optimal lief. Ist eine Tochter von NetCologne.
Mein Schwager bekommt jetzt FTTH 5000/2500 von denen.
Er hat sogar seinen eigenen Berater.
Wie das mit VDSL bei denen aussieht (Telekom Infrastruktur) weiss ich noch nicht. Ich kann halt nichts mit einem Anbieter anfangen, der sich kein bisschen um mich kümmert.
Ich wiederhole mich ja gerne (wie so einige hier) - wir sitzen alle im selben Boot @Novize ud ich haben auch keinerlei Infos ob und wenn ja wann und was irgendwie am Board geändert wurde.
Ich würde wirklich von sonst so, allgmein, "angagierten" Usern mir wirklich wünschen, sich einfach bei solchen Sachen auch einfach mal ausreichend vorab zu informieren, ob es nicht bereits "Fundestellen" gibt.
Das immer wieder in über die Threads verstreut zu ventilieren bringt nichts - maximal in vorhandenen oder neuen Threads welche sich im Topic darum drehen.
