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.
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.
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.
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.
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.
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.
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.
