Es geht um einen Unitymedia TV-Kabel Anschluss mit der klobigen weißen Connect-Box, 1/60 Mbit. Unser Internet Anschluss fällt sehr häufig für einige Minuten aus. Als er vor 1,5 Jahren einmal ganz besonders schlecht funktionierte und Unitymedia mir nicht glauben wollte, besorgte ich einen Raspberry Pi, mit dem ich die Verfügbarkeit protokollieren wollte. Und schwupps: Keine Ausfälle mehr! Nach drei Monaten habe ich das Ding wieder eingemottet, prompt begannen wieder massive Ausfälle. Damit meine ich jetzt nicht mal kurz eine Minute, sondern richtig lange Totalausfälle, in denen länger als 15 Minuten nichts mehr erreichbar war. Also habe ich den Raspberry Pi wieder angeschlossen, schwupps sind die Fehler weg. So geht das nun schon seit 1,5 Jahren. Ich habe das Ding 4 mal abgebaut und dann einen Monat später wieder aufgebaut. Es ist immer das Gleiche. Mein Internet Anschluss läuft nur stabil, wenn der Raspberry Pi mit dran hängt. Nun fragte ich mich, wie das sein kann. Gibt es für dieses "Phänomen" eine technische Erklärung? Vielleicht bin ich paranoid, aber kann es sein, dass Unitymedia mir eine bessere Verfügbarkeit verschafft, sobald sie den Testautomaten erkennen? Quasi wie Volkswagen auf dem Prüfstand. Dazu noch ein paar weitere Detail- Infos: Ich lasse seit vielen Jahren zusätzlich einen ESP8266 laufen, der die Verfügbarkeit meiner Homepage jede Minute testet und mit einer farbigen LED anzeigt. Dass der Anschluss wegen Nicht-Benutzung ein schläft, kann ich daher ausschließen. Ich teste nur mit Kabel, WLAN Ausfälle zähle ich nicht mit. Diverse empfohlene Einstellungen an der Connect Box und an den Laptops, welche zur stabilisierung beitragen könnten, habe ich alle durch. Ich habe auch alternative DNS Server auf den Endgeräten eingestellt. Inzwischen habe ich Modem, Router, Switche und alle Kabel (sogar die Stromkabel) ausgetauscht und den Standort der Geräte geändert (andere Ecke im Raum, andere Steckdose). Aber das hat nichts gebracht. Auf dem Raspi läuft ein Shell Script, das jede Minute die Connect-Box und das dahinter liegende Gateway anpingt, sowie von 6 Webservern eine kleine Datei abruft. Da kommen hübsche Protokolle bei heraus, die ich als Beweis verwenden wollte. Doch Unitymedia kann damit nichts anfangen. Aus deren Sicht ist der Anschluss immer tadellos in Ordnung, außer ich schaffe es, während eines Ausfalls anzurufen. Dann schicken sie immer jemanden, der das Problem nicht reproduzieren kann. Gehen Sie zurück auf Los... Ich hatte früher mal einen DSL Anschluss von Vodafone, der funktionierte leider nicht besser. Angeblich seien die Kabel im Haus marode die müsse der Hausbesitzer erneuern lassen. Der tut das aber nicht. Insofern ist DSL keine gute Alternative für mich. Mobiles Internet über Smartphone ist um Welten stabiler - nur leider zu langsam und zu teuer, wenn man damit auch noch zwei Teenager versorgen muss.
Stefan ⛄ F. schrieb: > kann es sein, dass Unitymedia mir eine > bessere Verfügbarkeit verschafft, sobald sie den Testautomaten erkennen? Es ist kein Geheimnis, dass Provider z.B. bei den bekannten Speedtests den Traffic anders priorisieren – aber bei dem geschilderten Szenario würde ich den Fehler eher im heimischen LAN suchen. Soweit ich das verstanden habe, tritt das Problem nicht auf, sobald der Pi auch nur im Netz erscheint? Der Provider sollte™ nicht mal wissen, was bei dir im Netz ist. Noch weniger sollte er wissen, welchem Zweck eines der hunderttausendfach verkauften Platinchen in deinem Netz dient.
:
Bearbeitet durch User
Ich würde in der Netzkonfiguration suchen. Also DHCP o. vielleicht irgendwo eine "feste" IP. So regelmäßige Ausfälle (15 Minuten) klingen nach eine Art "Netzrefresh". Oder nach eine Abwehrmaßnahme der Firewall. Im schlimmsten Fall opfere 5 Euro im Monat, schick die Box zurück und ordere eine Fritzbox-C. Ist aber nur eine Vermutung. Gruß Pucki
Jack V. schrieb: > Soweit ich das verstanden habe, tritt das Problem nicht auf, > sobald der Pi auch nur im Netz erscheint? Fast: Sobald das Test-Script läuft. Speed Tests verlaufen immer gut, auch meine eigenen (Up- und Download zu meiner Homepage). Auch können wir ohne Probleme auf 4 Geräten gleichzeitig Video-Streaming gucken. Über mangelnde Geschwindigkeit kann ich überhaupt nicht klagen. Problem sind unregelmäßige Totalasufälle. Kürzere im Bereich von 1-3 Minuten habe ich mehrmals täglich. Längere eher seltener. Kommen aber auch vor.
Stefan ⛄ F. schrieb: > Fast: Sobald das Test-Script läuft. Da wär’s höchst interessant zu wissen, was dieses Testscript macht. Ob das dann für das Verschwinden des Fehlers verantwortlich ist, lässt sich ja einfach prüfen: eine VM (oder dieses WSL – soll ja auch ganz gut gehen, für einfache Sachen; ich selbst habe da aber keinerlei Erfahrung mit, deswegen in Klammern) hernehmen und das Script dort laufen lassen. Behebt das den Fehler, liegt’s vermutlich am Script.
Alexander K. schrieb: > Ich würde in der Netzkonfiguration suchen. > Also DHCP o. vielleicht irgendwo eine "feste" IP. Danke für den Vorschlag, das habe ich schon lange hinter mir. > Im schlimmsten Fall opfere 5 Euro im Monat, schick die > Box zurück und ordere eine Fritzbox-C. Ich hatte die Probleme schon vorher mit einem Cisco Modem + Fritzbox anstelle der Connect Box. Jetzt nur so auf Verdacht 200€ für eine weitere Fritzbox ausgeben mag ich nicht. Ich habe nicht so viel Geld auf der hohen Kante.
Ergänzung: auch immer ’nen Blick wert ist das Log des Plastikrouters (ich unterstelle mal einfach dessen Vorhandensein – wenn es nur ein „dummes“ Modem gibt, ist dieser Hinweis gegenstandslos).
Jack V. schrieb: > Da wär’s höchst interessant zu wissen, was dieses Testscript macht. >> Auf dem Raspi läuft ein Shell Script, das jede Minute die Connect-Box >> und das dahinter liegende Gateway anpingt, sowie von 6 Webservern eine >> kleine Datei abruft. Da kommen hübsche Protokolle bei heraus, die ich >> als Beweis verwenden wollte. Siehe Anhang. Im angehängten Logfile sieht man in der Spalte "Madrid" einen Aussetzer. Als Ausfall im Sinne der Störmeldung werte ich aber nur, wenn alle Webseiten gleichzeitig nicht mehr erreichbar sind. > eine VM hernehmen und das Script dort laufen lassen. > Behebt das den Fehler, liegt’s vermutlich am Script. Wenn das Script auf meinem Laptop läuft bleibt der Anschluss stabil. Ich habe das dort aber bisher nur einige Stunden laufen lassen, nicht Monatelang am Stück. Ich denke, dass nicht der Raspi selbst ausschlaggebend ist, sondern das, das das Script tut.
Ich bin bei Unitymedia. Aber ich kenne die Box nicht (hab noch ein kleines schwarzes Modem). Aber wenn ein Ping-prg. die Leitung offen hält fällt mir nur noch ein sehr hart eingestellter Energiesparmodus ein. Tritt das Problem auch mit LAN auf (nicht W-lan). Ich hab mal den Fall gehabt, das ein bestimmtes Gerät nicht benutzt werden durfte, sonst war W-Lan gestört. Und keine Gigaset-Telefone an der selben Steckdose wie die Box. Die brauchen Corona-Abstandsregeln. KEIN WITZ. Vielleicht rückt die Box ja Protokolle raus. Also einfach mal die Box durchsuchen. Ansonsten bin ich (per Ferndiagnose) mit meine Latein am Ende. Gruß Pucki
Alexander K. schrieb: > Aber wenn ein Ping-prg. die Leitung offen hält fällt mir nur noch ein > sehr hart eingestellter Energiesparmodus ein. Wie gesagt hält auch der ESP8266 die Leitung im Minutenintervall offen. Aber der reicht nicht aus, um den Anschluss zu stabilisieren. Ich habe mal zur Info ein Logfile vom letzten mal angehängt, wo ich die Hotline anrufen wollte (was mir nicht gelang). Solche Ausfälle habe ich fast jeden Monat.
Dann würde ich als Nächstes prüfen, ob die Verbindung nach außen neu aufgebaut wurde – das würde sich ganz gut zur Fehlersuche heranziehen lassen. Dann würde ich schauen, ob nicht schon ein einfacher Ping einmal in der Minute zum Router das Problem unterbindet, wenn nein, ob ein Ping einmal in der Minute nach draußen es tut, und wenn nein, ob’s der HTTPS-Verbindungsaufbau tut. Früher™ gab’s in den Plastikroutern auch die Option, die Verbindung bei Inaktivität zu trennen und bei Bedarf neu aufzubauen. Ich denke mal, diesbezüglich hast du schon geschaut?
Alexander K. schrieb: > Tritt das Problem auch mit LAN auf (nicht W-lan). Wie gesagt ignoriere ich WLAN, da das funktechnisch schlecht ist. Es geht hier nur um Störungen an Kabeln. > Vielleicht rückt die Box ja Protokolle raus. Tut sie, aber nur wenige Stunden. Und ja, die Ausfälle sind dort erkennbar, hat auch Unitymedia bestätigt. > Und keine Gigaset-Telefone an der selben Steckdose wie die Box. > Die brauchen Corona-Abstandsregeln. KEIN WITZ. Ja mir ist klar, das Netzteile und defekte Geräte Störungen verursachen können. Das habe ich umfangreich durchgespielt - ohne Besserung zu erreichen.
Hast du auch TV. ? Schau mal in die TV-Box. Das Leitungssignal sollte bei 89% liegen. Hast du schon mal die Box getauscht. ? UM hat da einige Probleme mit, liest man in diversen Foren. Ach ja, du sollst keine neue Fritzbox KAUFEN. Man kann für 5 Euro /Monat eine Fritzbox leihen von UM. Gruß Pucki
Jack V. schrieb: > Dann würde ich als Nächstes prüfen, ob die Verbindung nach außen neu > aufgebaut wurde – das würde sich ganz gut zur Fehlersuche heranziehen > lassen. Ja, die Box versucht im Fehlerfall neue Verbindungen aufzubauen und im wiederholten Fehlerfall rebootet sie sogar automatisch, bis der Anschluss wieder läuft. Das kann man in ihrem Protokoll sehen. Leider zeigt sie immer nur die letzten 24 Stunden an. Aber in meinem Log vom Raspberry Pi kann die Reboots auch erkennen. > Dann würde ich schauen, ob nicht schon ein einfacher Ping einmal > in der Minute zum Router das Problem unterbindet Ich muss wohl nochmal wiederholen, dass mein ESP8266 bereits seit Jahren jede Minute die Erreichbarkeit meiner Homepage testet. Der Anschluss ist nie länger als eine Minute Idle. > Dann würde ich schauen, ob nicht schon ein einfacher Ping einmal > in der Minute zum Router das Problem unterbindet, wenn nein, ob ein Ping > einmal in der Minute nach draußen es tut, und wenn nein, ob’s der > HTTPS-Verbindungsaufbau tut. Das macht mein Script auf dem Raspberry Pi ja. Jede Minute 2x Ping und 6x HTTPS.
Alexander K. schrieb: > Hast du auch TV. ? > Schau mal in die TV-Box. Das Leitungssignal sollte bei 89% liegen. Habe ich nicht. Mein TV hängt mit Ethernet an der Connect Box. > Hast du schon mal die Box getauscht. Ja habe ich. Und davor hatte ich ein Cisco Modem + Fritzbox mit den gleichen Problemen. > Ach ja, du sollst keine neue Fritzbox KAUFEN. > Man kann für 5 Euro /Monat eine Fritzbox leihen von UM. Mir haben sie gesagt, dass ich sie nur mit 2 Jahren Mindestlaufzeit für ca 200€ Mieten könne. Selber kaufen sei aber besser, weil etwas billiger und ich dann keine beschränkte Firmware drauf habe. Vielleicht das regional unterschiedlich.
Stefan ⛄ F. schrieb: > Ja, die Box versucht im Fehlerfall neue Verbindungen aufzubauen und im > wiederholten Fehlerfall rebootet sie sogar automatisch, bis der > Anschluss wieder läuft. Das kann man in ihrem Protokoll sehen. Leider > zeigt sie immer nur die letzten 24 Stunden an. Aber in meinem Log vom > Raspberry Pi kann die Reboots auch erkennen. Vielleicht spinnt die Box einfach herum. Irgend ein Kondensator/Elko oder was auch immer unsauber und die Box dreht am Rad weil sie falsche Ströme bekommt. Frage : wurde die mal getauscht. ? Gruß Pucki
Stefan ⛄ F. schrieb: > Das macht mein Script auf dem Raspberry Pi ja. Jede Minute 2x Ping und > 6x HTTPS. Ja, aber halt alles auf einmal. Zumindest ich würde erstmal gucken, welche der drei Sachen denn genau dafür verantwortlich ist, dass die Box die Verbindung nicht terminiert. Ping nach draußen fällt also schonmal raus, wenn du auch deine Seite in diesen Intervallen pingst.
Alexander K. schrieb: > Vielleicht spinnt die Box einfach herum. > Frage : wurde die mal getauscht. ? Ja, wurde sie. ich hatte wie gesagt auch vorher ein Cisco Modem + Fritzbox, die hatten das gleiche Problem.
Jack V. schrieb: > Ja, aber halt alles auf einmal. Zumindest ich würde erstmal gucken, > welche der drei Sachen denn genau dafür verantwortlich ist, dass die Box > die Verbindung nicht terminiert. Ach so meinst du das. Ja das könnte ich mal versuchen. Blöderweise muss ich dann wochenlang auf das Ergebnis warten um sicher zu sein und wenn der Anschluss dann wieder ausfällt, fehlt mir das gewohnte Protokoll mit dem ich Unitymedia bisher immer zur Mitarbeit bewegen konnte. Ohne Protokoll sagen die immer nur, dass ich mal an den Steckern wackeln soll oder meine Computer neu installieren soll - als ob sich das nicht schon mehrmals gemacht hätte. Ohne Protokoll halten die einen für doof. Ping nach draußen fällt also schonmal > raus, wenn du auch deine Seite in diesen Intervallen pingst. Ich rufe die Startseite per HTTP ab.
https://www.onlinekosten.de/news/unitymedia-komfort-option-nur-noch-mit-fritzbox-6591-cable_221708.html Das meine ich. Gruß Pucki
Alexander K. schrieb: > https://www.onlinekosten.de/news/unitymedia-komfort-option-nur-noch-mit-fritzbox-6591-cable_221708.html > Das meine ich. Gut zu wissen. Das fällt bei mir aber raus, denn ich habe nur Internet. kein TV, kein Telefon. Solange der Anschluss schlecht funktioniert, will ich denen auch nicht langfristig noch mehr Geld geben. Es reicht schon, dass ich auf 60 Mbit aufgerüstet habe weil die mir versprochen haben, dass ich dann an eine andere "Leitung" gehängt würde die neu sei und ganz bestimmt zuverlässiger sei.
Stefan ⛄ F. schrieb: > Es reicht schon, dass ich auf 60 Mbit aufgerüstet habe weil die mir > versprochen haben, dass ich dann an eine andere "Leitung" gehängt würde > die neu sei und ganz bestimmt zuverlässiger sei. Purer Blödsinn. Meine schnellere Leitung hatte ich 30 Minuten nach den Telefonat. In der Zeit rennt kein Techniker in einen Keller. Die modifizieren einfach per Software den Lastbegrenzer das ist alles. Gruß Pucki
Wir hatten am Anfang auch Probleme mit dem Internet. Ständig Verbindungsabbrüche, ab und an war es einfach langsam. Von Kabel wurde dann ein Verstärker installiert und die Probleme waren weg. So ganz passen tut das vielleicht nicht da das Script die Probleme ja "behebt" aber man weiß ja nie.
Alexander K. schrieb: > Purer Blödsinn. Mag ja sein, aber wenn man so verzweifelt ist, versucht man halt alles, was nicht allzu teuer ist. Die vorherigen 16 Mbit waren eh knapp.
Ich bin immer noch der Meinung das, das Script etwas am "einschlafen" hindert. Aber ansonsten SORRY mit gehen die Ideen aus. Gruß Pucki
Alexander K. schrieb: > Ich bin immer noch der Meinung das, das Script etwas am "einschlafen" > hindert. Der Meinung schließe ich mich weiterhin an. Wäre halt gut, rauszufinden, welcher Teil genau vom Script das tut. Dann könnte man z.B. irgend’nen ESP oder so für den Job herrichten und irgendwo ins Netz hängen, so dass Stromverbrauch und Wartungsaufwand für den Workaround minimal wären.
Guest schrieb: > Von Kabel wurde > dann ein Verstärker installiert und die Probleme waren weg. Zu viel Verstärker ist auch nicht gut. Ich hatte vor UM ein reinen TV-Anschluss von Tele-Columbus. Als dann der UM-Techniker im Haus die Anlage hochgerüstet hat, lief bei mir nix mehr. Grund waren die fetten Verstärker von der Tele-Columbus. Fakt ist, das muss alles passen. Gruß Pucki
Alexander K. schrieb: > Ich bin immer noch der Meinung das, das Script etwas am "einschlafen" > hindert. Jack V. schrieb: > Der Meinung schließe ich mich weiterhin an. Wäre halt gut, rauszufinden, > welcher Teil genau vom Script das tut. Ja ich denke, das muss ich wohl schrittweise einkreisen - auch wenn ich dabei zeitweise mein hübsches Protokoll verliere. Andererseits: Mal angenommen ich finde heraus, welcher der 8 Befehle das Problem behebt... was nützt mir das dann? Ich werden dann immer noch einen Testautomaten brauchen, um den Internet-Anschluss zu stabilisieren. Eigentlich interessiert mich mehr die Frage, ob Unitymedia womöglich Testautomaten erkennt und dann die betroffenen Anschlüsse besser behandelt. Wenn das so wäre, wie lange würde das wohl ein Geheimnis bleiben?
Stefan ⛄ F. schrieb: > Eigentlich interessiert mich mehr die Frage, ob Unitymedia womöglich > Testautomaten erkennt und dann die betroffenen Anschlüsse besser > behandelt. Das erkennen ist kein Problem. Allerdings erkennt es nicht den Automaten sondern den Test. Es merkt ja, (wenn sie es merken), wie hoch und wie genau der Traffic auf der Leitung ist. Ob sie das auswerten. KEINE AHNUNG. Das erkennen ist jedenfalls kein Problem. Gruß Pucki
Stefan ⛄ F. schrieb: > Eigentlich interessiert mich mehr die Frage, ob Unitymedia womöglich > Testautomaten erkennt und dann die betroffenen Anschlüsse besser > behandelt. Unwahrscheinlich. Wahrscheinlicher ist, dass dein Script wie ’ne Art „Keepalive“ wirkt. Und, wie gesagt, wenn das einwandfrei festgenagelt ist, kann man sich ja ’n kleines Device ins Netz hängen, welches den Job übernimmt. Natürlich wär’s schöner, das Problem selbst zu beheben. Aber wenn es in oder hinter dem Router sitzt, befindet es sich weit außerhalb deiner Reichweite.
Alexander K. schrieb: > Ob sie das auswerten. KEINE AHNUNG. Das erkennen ist jedenfalls kein > Problem. Ich hatte zwischenzeitlich mal die Webserver gewechselt, das hatte nichts verändert.
Stefan ⛄ F. schrieb: > Ich hatte zwischenzeitlich mal die Webserver gewechselt, das hatte > nichts verändert. Wen juckt das ? Ich dachte dabei an eine Funktion auf den Route-Server von UM. Gruß Pucki
Stefan ⛄ F. schrieb: > Solche Ausfälle habe ich > fast jeden Monat. Was ich anstreben würde um den Fehler "deines" Gateways einzukreisen: Auf einem externen Rechner ebenfalls loggen, etwa so in der bash: while [ 1 ]; do date; ping -c1 109.91.12.1 | grep "time="; if [ $? = 0 ]; then echo ""; else echo "NIX"; fi; sleep 1; done >>/tmp/109.91.12.1_ping laufenlassen. Dann siehst du ob diese Maschine zeitgleich auch anderen Teilnehmern gegenüber Probleme zeigt, oder ob nur die Richtung deines eigenen Netzwerkes betroffen ist. Pure spekulation: Letzteres könnte möglicherweise durch Mantelströme zustandekommen. Stichworte/Brainstorming -Hausinstallation: Erdung oder klassische Nullung -Mantelstromfilter an der Koaxdose vorhanden (zwei kleinkondensatoren wirken oft Wunder) -Hochstromverbraucher (Kaffeemaschine/Durchlauferhitzer) legen dein NW lahm HTH PS: Deine Logs jittern ja wirklich heftig. Eine DSL in Frankfurt am Main spricht: ping -i0.2 -c1000 109.91.12.1 --- 109.91.12.1 ping statistics --- 1000 packets transmitted, 1000 received, 0% packet loss, time 200301ms rtt min/avg/max/mdev = 19.449/20.670/23.147/0.537 ms
2 Cent schrieb: > Dann siehst du ob diese Maschine zeitgleich auch anderen > Teilnehmern gegenüber Probleme zeigt Habe ich längst gemacht. Ja, es sind immer alle Clients gleichzeitig betroffen und es spielt auch keine Rolle, wohin ich mich connecten will. Aber: bereits offene Verbindungen bleiben meist funktionstüchtig. Deswegen hatte ich lange Zeit in Richtung DNS gesucht. > Deine Logs jittern ja wirklich heftig Ja, finde ich auch. Darauf habe ich Unitymedia auch schon einmal hingewiesen. Aber einen Kabeltausch scheinen die gar nicht in Erwägung zu ziehen - obwohl sie dafür zuständig sind - sagt jedenfalls die Hausverwaltung.
Beim Kabelanschluss kann es sich lohnen, mal in der Nachbarschaft rumzufragen. Ich hatte bis vor Kurzem ein Problem, das die halbe Strasse hatte.
Stefan ⛄ F. schrieb: > 2 Cent schrieb: >> Dann siehst du ob diese Maschine zeitgleich auch anderen >> Teilnehmern gegenüber Probleme zeigt > > Habe ich längst gemacht. Ja, es sind immer alle Clients gleichzeitig > betroffen und es spielt auch keine Rolle, wohin ich mich connecten will. Ich bin mir unsicher ob du mich richtig verstanden hast. Mit externem Rechner meine ein weiteres Log, welches im Nachbarhaus, oder auch in der Nachbarstadt erzeugt wird, nicht auf deinen LAN-clients. Die 109.91.12.1 kann doch auch selbst Probleme haben; dieses (falls dem denn so währe) liesse sich dem Provider viel besser um die Ohren hauen. Also Gedacht zum geographischen einkreisen der Ursache...andere Teilnehmer deiner Strasse wären dann ebenfalls betroffen.
2 Cent schrieb: > Ich bin mir unsicher ob du mich richtig verstanden hast. Mit externem > Rechner meine ein weiteres Log, welches im Nachbarhaus, oder auch in der > Nachbarstadt erzeugt wird Ach so, das hatte ich in der Tat anders verstanden. Gute Idee, das kann ich mal probieren. Ich lasse das gleiche Script einfach mal im Büro laufen.
So, das Script läuft jetzt auch im Büro auf einem "echten" Server. Praktischerweise ist das auch ein Unitymedia Anschluss (aber natürlich ein größerer) und im selben Stadtteil. Jetzt muss es ein paar Monate laufen, dann habe ich Daten zum Vergleichen. Oder eben bis zum nächsten großen Ausfall.
Stefan ⛄ F. schrieb: > So, das Script läuft jetzt auch im Büro auf einem "echten" Server. > Praktischerweise ist das auch ein Unitymedia Anschluss (aber natürlich > ein größerer) und im selben Stadtteil. Also auch per Koaxialkabel angebunden? Sicherlich nicht dasselbe Gateway (109.91.12.1) wie bei dir zu Hause, also Route von "aussen". Neugier (und vielleicht ein Lösungsansatz ---> Problemstelle doch deine Kaox-seite zuhause): jittern die Antworten in deinem Büro auch so heftig wie bei dir zuhause, ist das also typisch für Koax? Im Moment nochmal an einer DSL in FFM getestet, recht "saubere" 21ms: $ ping -i0.2 -c1000 109.91.12.1 1000 packets transmitted, 1000 received, 0% packet loss, time 200279ms rtt min/avg/max/mdev = 19.898/20.575/23.957/0.496 ms Route: $ sudo -k traceroute -I -N1 109.91.12.1 traceroute to 109.91.12.1 (109.91.12.1), 30 hops max, 60 byte packets 1 easy.box (192.168.2.1) 0.327 ms 0.351 ms 0.324 ms 2 ipservice-092-217-064-001.092.217.pools.vodafone-ip.de (92.217.64.1) 14.613 ms 14.595 ms 14.262 ms 3 88.79.8.48 (88.79.8.48) 14.442 ms 4 92.79.214.178 (92.79.214.178) 14.918 ms 16.194 ms 15.190 ms 5 145.254.2.195 (145.254.2.195) 15.206 ms 16.292 ms 15.917 ms 6 ae32-100-pcr1.fnt.cw.net (195.2.18.217) 15.258 ms 15.503 ms 15.326 ms 7 ae59.xcr1.fix.cw.net (195.2.20.225) 15.131 ms 15.865 ms 15.431 ms 8 as6830-gw-xcr1.fix.cw.net (195.2.22.210) 15.243 ms 15.724 ms 14.440 ms 9 de-fra04d-rc1-ae-43-0.aorta.net (84.116.130.101) 23.260 ms 25.296 ms 28.772 ms 10 de-dus01a-rd02-ae-1-0.aorta.net (84.116.196.30) 20.994 ms 20.306 ms 20.921 ms 11 ip-109-91-12-1.hsi12.unitymediagroup.de (109.91.12.1) 20.272 ms 20.695 ms 20.921 ms > Jetzt muss es ein paar Monate laufen, dann habe ich Daten zum > Vergleichen. Oder eben bis zum nächsten großen Ausfall. Vielleicht kannst du mit Ping (und einem auftretendem packet loss) die Sache beschleunigen. Wie auch immer: ich drück dir die Daumen beim einkreisen, finden, und ggf Beweisen der Problemstelle ggü Vodafone.
Wow, das ist ja eine echt schnelle Leitung ... verstehe nicht was daran unzuverlässig sein soll.
:
Bearbeitet durch User
Ben B. schrieb: > Wow, das ist ja eine echt schnelle Leitung ... verstehe nicht was > daran unzuverlässig sein soll. Ich schrieb bereits mehrfach, dass Geschwindigkeit nicht mein Problem ist.
So meinte ich es nicht, habe gerade mal geschaut, aktuell habe ich 14ms zu 8.8.8.8 (Google-DNS) mit DSL-100 und einer WLAN-Strecke am Anfang. Ich meinte eher die Leitung ist konstant schnell, keine Sprünge oder Ausreißer wie man es bei Unzuverlässigkeiten erwarten würde.
So sieht das bei mir aus:
1 | stefan@stefanpc:~$ ping 8.8.8.8 |
2 | PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. |
3 | 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=25.2 ms |
4 | 64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=24.8 ms |
5 | 64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=15.3 ms |
6 | 64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=15.6 ms |
7 | 64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=14.10 ms |
8 | 64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=15.4 ms |
9 | 64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=14.6 ms |
10 | 64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=15.0 ms |
11 | 64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=22.3 ms |
12 | 64 bytes from 8.8.8.8: icmp_seq=10 ttl=55 time=32.0 ms |
13 | 64 bytes from 8.8.8.8: icmp_seq=11 ttl=55 time=16.8 ms |
14 | 64 bytes from 8.8.8.8: icmp_seq=12 ttl=55 time=15.5 ms |
15 | 64 bytes from 8.8.8.8: icmp_seq=13 ttl=55 time=15.5 ms |
16 | 64 bytes from 8.8.8.8: icmp_seq=14 ttl=55 time=16.2 ms |
17 | 64 bytes from 8.8.8.8: icmp_seq=15 ttl=55 time=14.3 ms |
18 | 64 bytes from 8.8.8.8: icmp_seq=16 ttl=55 time=14.7 ms |
19 | 64 bytes from 8.8.8.8: icmp_seq=17 ttl=55 time=16.1 ms |
20 | 64 bytes from 8.8.8.8: icmp_seq=18 ttl=55 time=14.8 ms |
21 | 64 bytes from 8.8.8.8: icmp_seq=19 ttl=55 time=15.10 ms |
22 | 64 bytes from 8.8.8.8: icmp_seq=20 ttl=55 time=15.3 ms |
23 | 64 bytes from 8.8.8.8: icmp_seq=21 ttl=55 time=14.3 ms |
24 | 64 bytes from 8.8.8.8: icmp_seq=22 ttl=55 time=15.8 ms |
25 | 64 bytes from 8.8.8.8: icmp_seq=23 ttl=55 time=16.5 ms |
26 | ^C |
27 | --- 8.8.8.8 ping statistics --- |
28 | 23 packets transmitted, 23 received, 0% packet loss, time 55ms |
29 | rtt min/avg/max/mdev = 14.256/17.259/32.033/4.369 ms |
Solange der Anschluss funktioniert, ist das nichts auffälliges zu sehen. Aber es gibt halt immer wieder Phasen, wo einige Minuten lang schlagartig gar nichts mehr geht. Und dann läuft er plötzlich wieder von alleine.
Verfügbarkeitsminimum ist nicht in Zahlen erfasst, in deinem Vertrag? Paketorientierte Verbindungen (E.g. Ethernet, IP, usw.) erreichen nie die Verfügbarkeit von SwitchedCircuits und weisen immer irgendein Verlust auf. HW ist halt nur Consumerware, niemals Carrier-Grade und letztere hat nun mal andere Preise. Jede Verbindung umfasst 2 Endpunkte: ev. sitzt der Käfer nicht in deinem Haus/Geräte sondern auf der anderen Seite der Leitung und da kommste nicht ran. Wieso kommst Du nicht auf die Idee, das Intervall deiner ESP8266-Ampel von 60s auf 30s (wie im Raspi-script) zu verkürzen? Kannst die Funktionalität deines Raspi-script nicht gleich auf die ESP8266-Ampel portieren? Lass doch den RasPi mit Script dauern an. Nicht schön aber scheinbar nützlich... Sorry, ich weiss: hilft alles nicht dem Problem auf den Grund zu kommen.
Local Area Notwork schrieb: > Wieso kommst Du nicht auf die Idee, das Intervall deiner ESP8266-Ampel > von 60s auf 30s (wie im Raspi-script) zu verkürzen? Sie war ursprünglich bei 10s, das löste mein Problem aber nicht.
Local Area Notwork schrieb: > Wieso kommst Du nicht auf die Idee, das Intervall deiner ESP8266-Ampel > von 60s auf 30s (wie im Raspi-script) zu verkürzen? Sie war ursprünglich bei 10s, das löste mein Problem aber nicht. Local Area Notwork schrieb: > Lass doch den RasPi mit Script dauern an. Nicht schön aber scheinbar > nützlich... Tue ich ja jetzt. Ab und zu nutze ich ihn ohnehin auch noch für andere Spielereien.
Ein kleines Update: Der Anschluss hatte in den vergangenen zwei Monaten keine grö0ßere Aussetzer mehr. Geändert habe ich nicht. Den Testautomaten (Raspberry pi) habe ich zur Gegenprobe vor zwei Wochen entfernt, läuft immer noch alles weitgehend stabil. Irgendwie hat sich das Problem in Luft aufgelöst.
Stefan ⛄ F. schrieb: > Ein kleines Update: Der Anschluss hatte in den vergangenen zwei Monaten > keine grö0ßere Aussetzer mehr. Geändert habe ich nicht. Aber vielleicht der Anbieter. Wie ich oben schon schrieb hatte bei mir die halbe Strasse den gleichen immer wieder kurzzeitig auftretenden Ausfall. Hatte wohl eine ziemlich Weile gedauert, bis die Kabler Ersatz für die Baugruppe hatten, denn gewusst hatten die das schon länger.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.