Seit 4 Wochen Probleme mit Internet und Telefon

[ExOdUs]

Nur die Ruhe, natürlich habe ich es wieder so eingestellt wie es vorher war, brachte ja keinerlei Verbesserungen.
Einen Versuch war es wert

Vor ca. 20 Minuten kam eine SMS von VKD das die Störung behoben ist.

Modulation ist aber immer noch 2x32 und 2x16 und der Pegel liegt bei 96... Wird wohl auf eine weitere Störmeldung rauslaufen.

Gruß

Roland

[Flole]

Bleibt es konstant bei den 2x32 und 2x16? Dann hätten wir hier das Beispiel für ein störendes einpegeln was einige sich ja so sehr gewünscht haben.

Die Störung liegt auch nur an, wenn du beim Speedtest beeinträchtigt bist, eine Modulation mit der du unzufrieden bist ist keine Störung, deshalb immer wieder (natürlich Abends zur Hauptnutzungszeit) testen sodass du auch eine Geschwindigkeit hast die du melden kannst (zusammen mit der Modulation).

[ExOdUs]

An der Modulation hat sich nichts verändert. Aktuell schwankt diese zwischen 3x16 + 1x32 und 2x16 +2x32.

Speedprobleme habe ich nicht, nur immer Lagś beim Surven und telefonieren.

[Flole]

Die Lags hast du dann wohl immer beim Modulationswechsel. Kannst du so nichts dran machen, da bleibt nur das abwarten bis der Störer gefunden und beseitigt ist.

[in-need-for-speed]

Exodus, Du solltest den Rückwegpegel lieber wieder korrigieren. Sonst läuft auch nach Behebung der Rückwegstörung QAM64 nicht wirklich stabil. 101,1dBµV sollten es schon sein, und tolarabel wäre erst ab 97,1dBµV. Und da sich selbst die 9dB weniger Rückwegverstärkung nicht negativ abgezeichnet haben, sind ein paar dB weniger auch für die Nachbarn kein Problem.

Rückwegstörer muss man manchmal bis zu 3x in Folge melden, damit sie einmal beim echten Level 2 Supporter landet, und nicht nur bei der automatischen Leitungsprüfung. Und die Hänger sind nach Vodafone-Sprech "Verbindungsabbrüche", kann man also als Störung eintragen. Die verursachen auch das Knacksen oder die Aussetzer beim Telefonieren.


Ob die Lags wirklich an schnellen Modulationswechseln liegen, kann man an hand des Puma6 tests rausfinden:
http://www.dslreports.com/tools/puma6
Sind die Perfekt, kann das eigentlich nicht sein.

[Flole]

Exodus, Du solltest den Rückwegpegel lieber wieder korrigieren. Sonst läuft auch nach Behebung der Rückwegstörung QAM64 nicht wirklich stabil. 101,1dBµV sollten es schon sein, und tolarabel wäre erst ab 97,1dBµV. Und da sich selbst die 9dB weniger Rückwegverstärkung nicht negativ abgezeichnet haben, sind ein paar dB weniger auch für die Nachbarn kein Problem.

Immer noch gilt: QAM64 entweder für alle oder für niemanden. Demnach würde der Anschluss bei der Behebung sowieso in den Fokus rücken. Aber die Bandbreite liegt ja im richtigen Bereich, also macht das rumdrehen Null sinn.

Und die Hänger sind nach Vodafone-Sprech "Verbindungsabbrüche", kann man also als Störung eintragen. Die verursachen auch das Knacksen oder die Aussetzer beim Telefonieren.

Tut mir leid dich enttäuschen zu müssen, aber wenig überraschend sind Verbindungsabbrüche (per Definition) Abbrüche der Verbindung. Eine Unterbrechung für wenige hundert Millisekunden ist kein Verbindungsabbruch, sondern ein Latency Spike oder Lag. Die Verbindung bleibt nämlich bestehend und wenn man da in den Logs nach Verbindungsabbrüchen sucht, sieht man eine Verbindung die x Tage lang steht, Störung wird geschlossen.

Ob die Lags wirklich an schnellen Modulationswechseln liegen, kann man an hand des Puma6 tests rausfinden:
www.dslreports.com/tools/puma6
Sind die Perfekt, kann das eigentlich nicht sein.

Bitte was? Möchtest du das nicht nochmal überdenken? Eine Unterbrechung des Upstreams die vom CMTS angeordnet wird um den Wechsel sauber zu vollziehen schiebst du auf den Puma Bug?

[in-need-for-speed]

Natürlich gibt's die Anweisung nicht, das wäre ja auch völlig wahnsinnig. Du schließt dein kaputtes Endgerät an und schon startet einmal das ganze Segment neu, dann machst du das wieder, und nochmal geht das ganze Segment offline.

So war das garnicht gemeint. Neustarten würde man nur bei Grossstörungen (darunter fallen auch systemische Rückwegstörer), Systemwartungen oder nach deutlichen Rückwegstörern.
Natürlich könnte man das mit Knowhow auch künstlich reproduzieren. Dagegen würde aber einfach ein Timer im CMTS helfen: So dass die Modems nur neu gestartet werden dürfen wenn innerhalb der letzten 24 Stunden höchstens 1x Neugestartet wurde, seit dem ersten mal mind. 12 Stunden vergangen sind oder falls es schon 2mal vorkam nurnoch alle 24 Stunden + eine prioritäre Meldung an die Systemwartung nach dem 3. Neustart in einer Woche. Gehen würde das also. Wenn alle Modems von sich aus wieder auf 64QAM mit allen Kanälen laufen, könnte man den Neustart aussetzen oder auf 4 Uhr verschieben. Dann müsste man nach einer Wetterbedingten Grossstörung nicht mehr 2 Tage nach Behebung warten, bis alle Modems wieder halbwegs normal laufen.

[Flole]

Du überforderst Casa mit so einem request

Und ich habs noch nie erlebt, das ein Gerät mit einem Pegel der in Ordnung war auf einem Kanal stecken geblieben ist (der eine Kanal tritt ja nur auf wenn der Pegel völlig falsch liegt). Das ein Gerät in der falschen Modulation stecken bleibt ist ausgeschlossen, die ist nämlich (immer noch, sofern sich da nichts dran geändert hat) für das ganze Segment global festgelegt (wobei da bei 3.1 ja wohl Neuerungen kommen sollen). Dann würde es auch Sinn machen, aber momentan eher nicht.

[in-need-for-speed]

Immer noch gilt: QAM64 entweder für alle oder für niemanden. Demnach würde der Anschluss bei der Behebung sowieso in den Fokus rücken. Aber die Bandbreite liegt ja im richtigen Bereich, also macht das rumdrehen Null sinn.

Das ist Blödsinn. Ein Rückwegpegel bzw. SNR der für QAM32 stabil reicht, muss noch lange nicht für (stabiles) QAM64 reichen. Und dann bist Du der Rückwegstörer.

Und die Hänger sind nach Vodafone-Sprech "Verbindungsabbrüche", kann man also als Störung eintragen. Die verursachen auch das Knacksen oder die Aussetzer beim Telefonieren.

Tut mir leid dich enttäuschen zu müssen, aber wenig überraschend sind Verbindungsabbrüche (per Definition) Abbrüche der Verbindung. Eine Unterbrechung für wenige hundert Millisekunden ist kein Verbindungsabbruch, sondern ein Latency Spike oder Lag. Die Verbindung bleibt nämlich bestehend und wenn man da in den Logs nach Verbindungsabbrüchen sucht, sieht man eine Verbindung die x Tage lang steht, Störung wird geschlossen.

Schreibs an Wikipedia! Das was ich erwähnt habe passt in Vodafone KDGs komische Definition von Verbindungsabbrüchen (die meinen eher Timeouts bzw. Reximits bei TCP während der Datenübertragung).

Ob die Lags wirklich an schnellen Modulationswechseln liegen, kann man an hand des Puma6 tests rausfinden:
www.dslreports.com/tools/puma6
Sind die Perfekt, kann das eigentlich nicht sein.

Bitte was? Möchtest du das nicht nochmal überdenken? Eine Unterbrechung des Upstreams die vom CMTS angeordnet wird um den Wechsel sauber zu vollziehen schiebst du auf den Puma Bug?

Darum ging es ja garnicht du Spassvogel! Der Puma6 Test ist nichts anderes als ein TCP-Packetlauf-Test mit vielen kleinen TCP-Paketen. Der schlägt beim Puma6 Latenzzeit-Bug ebenso aus wie bei Verbindungshängern durch häufige Modulationswechsel. Wenn die Lags nicht dort sondern nur bei grossen TCP-Paketen auftreten, spricht das gegen die Schnelle-Modulationswechsel-Theorie.

Und ich habs noch nie erlebt, das ein Gerät mit einem Pegel der in Ordnung war auf einem Kanal stecken geblieben ist (der eine Kanal tritt ja nur auf wenn der Pegel völlig falsch liegt).

Hier hatten wird das schon mehrfach. Sogar das Modems mit normaler manueller Neuverbindung ohne Neustart nur einen oder 3 statt 4 Uploads hatten.
Dazu bleiben die Modems manchmal nach der Störungsbehebung auf zu niedrigen Pegelwerten hängen. Da hilft auch nur der Neustart.

[Flole]

Das ist Blödsinn. Ein Rückwegpegel bzw. SNR der für QAM32 stabil reicht, muss noch lange nicht für (stabiles) QAM64 reichen. Und dann bist Du der Rückwegstörer.

Sag ich ja, und genau das fällt auf wenn der Techniker auf der Suche nach dem Störer in der CMTS sich die schlechtesten SNRs anschaut, und wo das Modem steht findet der dann auch raus.

Darum ging es ja garnicht du Spassvogel! Der Puma6 Test ist nichts anderes als ein TCP-Packetlauf-Test mit vielen kleinen TCP-Paketen. Der schlägt beim Puma6 Latenzzeit-Bug ebenso aus wie bei Verbindungshängern durch häufige Modulationswechsel. Wenn die Lags nicht dort sondern nur bei grossen TCP-Paketen auftreten, spricht das gegen die Schnelle-Modulationswechsel-Theorie.

Das sind keine schnellen Modulationswechsel (die sind nämlich limitiert, also in Zeit x werden nur y Modulationswechsel durchgeführt), da reicht ein permanenter Ping und schauen wenn die Modulation sich ändert ob die Antwortzeit in die Höhe geht, das klappt besser als der Puma Test der versucht die Fritzbox mit vielen Verbindungen in die Knie zu zwingen.