QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Forumsregeln
Forenregeln
Bitte gib bei der Erstellung eines Threads im Feld „Präfix“ an, ob du Kunde von Vodafone Kabel Deutschland („[VFKD]“), von Vodafone West („[VF West]“), von eazy („[eazy]“) oder von O2 über Kabel („[O2]“) bist.
Forenregeln
Bitte gib bei der Erstellung eines Threads im Feld „Präfix“ an, ob du Kunde von Vodafone Kabel Deutschland („[VFKD]“), von Vodafone West („[VF West]“), von eazy („[eazy]“) oder von O2 über Kabel („[O2]“) bist.
-
- Newbie
- Beiträge: 18
- Registriert: 17.10.2010, 11:56
QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Hallo, schon den ganzen Abend springt mein Modem (Thomson) relativ oft zwischen QAM16 und QPSK im Upload hin und her. Dabei ändert sich auch jedes mal die Uploadgeschwindigkeit - QAM16: ~1.6Mbit, QPSK: ~0.6Mbit. Jedes mal wenn das Modem umspringt habe ich ca. 5 Sekunden lag, was beim Zocken nervig sein kann.
Modemwerte:
SNR: 37 dB
Downstream Power: 1.2 dBmV
Upstream Power: 46.0 dBmV (QAM16) / 45.0 dBmV (QPSK)
Das Problem besteht auf sämtlichen Upstream Channels. Bei der Hotline hieß es nur meine Werte sind okay und das wars.
Weiß wer was da schief laufen könnte?
Modemwerte:
SNR: 37 dB
Downstream Power: 1.2 dBmV
Upstream Power: 46.0 dBmV (QAM16) / 45.0 dBmV (QPSK)
Das Problem besteht auf sämtlichen Upstream Channels. Bei der Hotline hieß es nur meine Werte sind okay und das wars.
Weiß wer was da schief laufen könnte?
-
- Ehrenmitglied
- Beiträge: 2139
- Registriert: 08.07.2009, 11:25
Re: QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Ich kenne mich nicht 100-Prozentig aus mit der Kabeltechnik, mich wundert aber das "springen"...
Meiner Meinung nach ist da was kaputt, also entweder das Modem oder etwas an der Gegenstelle (CMTS) oder zwischendrin eine Muffe abgesoffen oder ein Verstärker.
Ich dachte nämlich immer, dass das Modem, wenn es einmal synchronisert mit der Gegenstelle die Verbindung hergestellt hat, die Parameter wie Kanal etc. beibehält, bis die Verbindung abbricht.
Also ein "nachregeln" während des Betriebes hier nicht üblich ist, wie es bei ADSL2+ der Fall wäre.
So gesehen müsste dieser Wechsel quasi immer ein kurzzeitiges "abfliegen" und neu sycnhronisieren sein?
Aber wie gesagt: Da kennen sich andere besser aus.
Meiner Meinung nach ist da was kaputt, also entweder das Modem oder etwas an der Gegenstelle (CMTS) oder zwischendrin eine Muffe abgesoffen oder ein Verstärker.
Ich dachte nämlich immer, dass das Modem, wenn es einmal synchronisert mit der Gegenstelle die Verbindung hergestellt hat, die Parameter wie Kanal etc. beibehält, bis die Verbindung abbricht.
Also ein "nachregeln" während des Betriebes hier nicht üblich ist, wie es bei ADSL2+ der Fall wäre.
So gesehen müsste dieser Wechsel quasi immer ein kurzzeitiges "abfliegen" und neu sycnhronisieren sein?
Aber wie gesagt: Da kennen sich andere besser aus.
Mein Anschluss am Zweitwohnsitz (allerdings bei den lokalen Stadtwerken, die FTTH bieten): 
[img]https://www.speedtest.net/result/2818053949.png[/img]

[img]https://www.speedtest.net/result/2818053949.png[/img]
-
- Newbie
- Beiträge: 18
- Registriert: 17.10.2010, 11:56
Re: QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Hmm, also ich hatte es schon, dass die Frequenz oder der Kanal einfach mittendrin wechselt, ohne dass die Verbindung getrennt wurde (nebenbei lief ein Stream, der nicht unterbrochen wurde). Somit glaube ich, dass es nicht abfliegen und neu Synchronisieren sein wird.Silverio hat geschrieben: Ich dachte nämlich immer, dass das Modem, wenn es einmal synchronisert mit der Gegenstelle die Verbindung hergestellt hat, die Parameter wie Kanal etc. beibehält, bis die Verbindung abbricht.
Also ein "nachregeln" während des Betriebes hier nicht üblich ist, wie es bei ADSL2+ der Fall wäre.
So gesehen müsste dieser Wechsel quasi immer ein kurzzeitiges "abfliegen" und neu sycnhronisieren sein?
Aber wie gesagt: Da kennen sich andere besser aus.
Das Modem synct ja auch nicht in obigem Fall komplett neu (kein Docsis-Downstream Scanning, Docsis-Ranging, Docsis-DHCP, Docsis-TFTP) es ist einfach plötzlich auf QPSK oder QAM16, verbunden mit einem kurzen lag. Richtiges Synchronisieren dauert, jedenfalls bei mir, definitiv länger.
Nunja, hoffe ich, dass es von alleine besser wird, bei der Hotline fehlt mir inzwischen (nach Jahren KDG) einfach der Wille mich da ewig (mit mehreren Anrufen) durch zu boxen, bis sie mir mal glauben, dass da was nicht stimmt.
Edit: Was mir heute noch aufgefallen ist, dass Upstream-Kanal: 1 und 2 komplett weg sind.
-
- Ehrenmitglied
- Beiträge: 2402
- Registriert: 20.09.2007, 10:23
- Wohnort: Freilassing
Re: QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Das Modem merkt, dass das CMTS auf seine T3, T4 Anfragen nicht reagiert, jedoch einen super SNR in Empfangsrichtung hat. Das Modem versucht darauf hin, seine Komprimierung zu ändern, so dass der SNR auf CMTS-Seite besser wird. Ist der SNR wieder gut genug, versteht das CMTS das Modem wieder. Anschließend versucht das Modem wieder, mit einer besseren Komprimierung zu senden. Das ist kein Ranging oder sonstiges, das läuft während dem Betrieb ab.
Ursachen, wie Silverio schon geschrieben hat.
Ein Verstärker scheint das Signal nicht mehr passend an die anderen Nodes zu verstärken, oder es ist auf dem Weg zu einer höheren Dämpfung des Signals durch eine defekte Muffe, Wassereintritt gekommen.
Was auch sein kann:
Kabel Deutschland hat bei einer Coax-Strecke die mind. Tiefe der Grabung nicht eingehalten. Das Kabel ist / war hohen Belastungen durch Druck ausgesetzt, was das Kabel beschädigte. Bei uns in Freilassing habe ich mal eine NE-3-Verkablung gesehen, wo das Kabel ca. 10cm unter dem Asphalt verlegt wurde. Wenn man noch genau wüsste, wo das Kabel entlang ging, könnte man mit einem dicken Nagel und einem Vorschlaghammer das Kabel ganz einfach beschädigen
Ursachen, wie Silverio schon geschrieben hat.
Ein Verstärker scheint das Signal nicht mehr passend an die anderen Nodes zu verstärken, oder es ist auf dem Weg zu einer höheren Dämpfung des Signals durch eine defekte Muffe, Wassereintritt gekommen.
Was auch sein kann:
Kabel Deutschland hat bei einer Coax-Strecke die mind. Tiefe der Grabung nicht eingehalten. Das Kabel ist / war hohen Belastungen durch Druck ausgesetzt, was das Kabel beschädigte. Bei uns in Freilassing habe ich mal eine NE-3-Verkablung gesehen, wo das Kabel ca. 10cm unter dem Asphalt verlegt wurde. Wenn man noch genau wüsste, wo das Kabel entlang ging, könnte man mit einem dicken Nagel und einem Vorschlaghammer das Kabel ganz einfach beschädigen

Anschlüsse: 3x Internet&Phone 100 MBits, 2x Internet&Phone 26MBit, 1x Internet&Phone 32 MBits Telefon-Anschluss: sipgate.de, dus.net, easybell.de, personal-voip.de
Router: Linux x64 Router, Interne Verkablung: Patchpannel, CAT 7, Netzwerkdosen, CAT 5e, wirelessLAN
Links:
- Kabel-Deutschland und die Geschwindigkeit des Internet-Zugangs
Router: Linux x64 Router, Interne Verkablung: Patchpannel, CAT 7, Netzwerkdosen, CAT 5e, wirelessLAN
Links:
- Kabel-Deutschland und die Geschwindigkeit des Internet-Zugangs
-
- Newbie
- Beiträge: 18
- Registriert: 17.10.2010, 11:56
Re: QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Danke für die Info
-
- Fortgeschrittener
- Beiträge: 203
- Registriert: 24.01.2007, 06:29
Re: QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Betreffend dem Upstream merkt das Kabelmodem erst mal garnichts. Es hat genau genommen keinerlei Entscheidungsbefugnis was den Upstream betrifft sondern muss strickt die Vorgaben des CMTS befolgen, welche ihm ueber den Downstream mitgeteilt werden. In diesem Fall merkt das CMTS, mit aktivierten Spectrum-Management dass das ankommende Signal nicht den Vorgaben (SNR und/oder Fehlerraten) entspricht und teilt dem Kabelmodem ueber den Downstream in dem sogenannten Upstream-Channel-Descriptor (UCD) mit, dass sich die Einstellungen im Upstream geaendert haben. Das Kabelmodem empfaengt diesen UCD regelmaesig in sehr kurzen Abstaenden und uebernimmt ohne Unterbrechung der Registrierung die Vorgaben der UCD und aendert gegebenenfalls die Modulation im Upstream. Dies ist moeglich, da im Upstream ein Burstartiges Zeitmultiplexverfahren eingesetzt wird (TDMA). Somit auch der Hinweis dass diese automatische Anpassenung der Modulation im Downstream nicht moeglich ist, wie hier manche Leute ab und zu denken.RcRaCk2k hat geschrieben:Das Modem merkt, dass das CMTS auf seine T3, T4 Anfragen nicht reagiert, jedoch einen super SNR in Empfangsrichtung hat. Das Modem versucht darauf hin, seine Komprimierung zu ändern, so dass der SNR auf CMTS-Seite besser wird. Ist der SNR wieder gut genug, versteht das CMTS das Modem wieder. Anschließend versucht das Modem wieder, mit einer besseren Komprimierung zu senden. Das ist kein Ranging oder sonstiges, das läuft während dem Betrieb ab.
Weiter sei zu erwaehnen das T3 und T4 Timeouts ein Ergebnis von Ranging (CMTS: Ranging-Opportunity, CM: Ranging-Request, CMTS: Ranging-Response) zwischen CMTS und CM ist und nicht wie man vielleicht aus dem Text oben entnehmen koennte "eine T3 Anfrage".
Wenn ein Verstaerker das Signal nicht mehr ausreichend im Rueckweg verstaerken oder dem Upstream-Signal andersweitige Daempfung zum CMTS zuteil werden wuerde, wird sich dass nicht in eine Aenderung der Modulation auswirken!RcRaCk2k hat geschrieben: Ursachen, wie Silverio schon geschrieben hat.
Ein Verstärker scheint das Signal nicht mehr passend an die anderen Nodes zu verstärken, oder es ist auf dem Weg zu einer höheren Dämpfung des Signals durch eine defekte Muffe, Wassereintritt gekommen.
Hier kann es genau im umgekehrten Fall dazu kommen, wenn der Verstaerker falsch eingepegelt und somit zu stark verstaerkt und somit zum breitbandigen Rauschen im Rueckweg beitraegt. Deswegen ist es auch nicht so toll wenn Leute im Internet mit gefaehrlichen Halbwissen die Kunden dazu animieren selbststaendig den Hausanschlussverstaerker mit dem Kabelmodem einzugepegeln.
mfg
wittmann
RFC 1925 Rule (4)
Some things in life can never be fully appreciated nor understood unless experienced firsthand.
Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
wittmann
RFC 1925 Rule (4)
Some things in life can never be fully appreciated nor understood unless experienced firsthand.
Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
-
- Newbie
- Beiträge: 18
- Registriert: 17.10.2010, 11:56
Re: QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Ich habe heute noch durch Zufall erfahren, dass ein Nachbar seit ein paar Tagen nun auch einen KDG-Anschluss hat. Kann es somit sein, dass der Techniker beim Einrichten des Anschlusses Mist beim Pegeln gebaut hat?wittmann hat geschrieben: Hier kann es genau im umgekehrten Fall dazu kommen, wenn der Verstaerker falsch eingepegelt und somit zu stark verstaerkt und somit zum breitbandigen Rauschen im Rueckweg beitraegt. Deswegen ist es auch nicht so toll wenn Leute im Internet mit gefaehrlichen Halbwissen die Kunden dazu animieren selbststaendig den Hausanschlussverstaerker mit dem Kabelmodem einzugepegeln.
Edit: Wie gesagt komme ich seit dem PingPong auch nicht mehr auf Kanal 1 und 2
-
- Fortgeschrittener
- Beiträge: 203
- Registriert: 24.01.2007, 06:29
Re: QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Eher unwarscheinlich, da der Techniker normalerweise sein Handwerk versteht und die Verstaerker entsprechen einstellen kann.Phaiger hat geschrieben:Ich habe heute noch durch Zufall erfahren, dass ein Nachbar seit ein paar Tagen nun auch einen KDG-Anschluss hat. Kann es somit sein, dass der Techniker beim Einrichten des Anschlusses Mist beim Pegeln gebaut hat?wittmann hat geschrieben: Hier kann es genau im umgekehrten Fall dazu kommen, wenn der Verstaerker falsch eingepegelt und somit zu stark verstaerkt und somit zum breitbandigen Rauschen im Rueckweg beitraegt. Deswegen ist es auch nicht so toll wenn Leute im Internet mit gefaehrlichen Halbwissen die Kunden dazu animieren selbststaendig den Hausanschlussverstaerker mit dem Kabelmodem einzugepegeln.
Ich kann dir nur empfehlen, da bei dir offensichtlich auch ein Service-Impact einhergeht, dies der Technik-Hotline zu melden, Einschliesslich der Erkenntnis der sich aendernden Modulation. Das duerfte schon entsprechender Hinweis fuer die Hotline sein.
Alles weitere hier im Forum duerfte relativ sinnlos sein und zu keiner Besserung deines Problems fuehren.
mfg
wittmann
RFC 1925 Rule (4)
Some things in life can never be fully appreciated nor understood unless experienced firsthand.
Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
wittmann
RFC 1925 Rule (4)
Some things in life can never be fully appreciated nor understood unless experienced firsthand.
Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
-
- Ehrenmitglied
- Beiträge: 2402
- Registriert: 20.09.2007, 10:23
- Wohnort: Freilassing
Re: QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
@Wittmann: Du hast natürlich vollkommen Recht, gar kein Thema
Jedoch kann es auch vorkommen, dass das CMTS nicht einmal herausfinden kann, welches Modem denn eigentlich versucht, Daten zu Senden, da auf der physikalischen Sicherungsebene die Daten nicht ausgewertet werden können. Dann versucht das Modem selbstständig ein niedrigeres Komprimierungsverfahren einzusetzen. Von diesem Szenario ging ich nun aus. Wenn jedoch bei QAM16 das CMTS das Modem noch teilweise verstehen kann, aber viele CRC-Fehler auftreten, fordert das CMTS natürlich das Modem dazu auf, den Upstream anzupassen.

Anschlüsse: 3x Internet&Phone 100 MBits, 2x Internet&Phone 26MBit, 1x Internet&Phone 32 MBits Telefon-Anschluss: sipgate.de, dus.net, easybell.de, personal-voip.de
Router: Linux x64 Router, Interne Verkablung: Patchpannel, CAT 7, Netzwerkdosen, CAT 5e, wirelessLAN
Links:
- Kabel-Deutschland und die Geschwindigkeit des Internet-Zugangs
Router: Linux x64 Router, Interne Verkablung: Patchpannel, CAT 7, Netzwerkdosen, CAT 5e, wirelessLAN
Links:
- Kabel-Deutschland und die Geschwindigkeit des Internet-Zugangs
-
- Fortgeschrittener
- Beiträge: 203
- Registriert: 24.01.2007, 06:29
Re: QAM16 <-> QPSK Pingpong im Upload (10553 Bln.)
Nochmal, das Kabelmodem hat keinerlei Befugnis bzw. Moeglichkeit die Modulation, was ich auch nicht als Komprimierungsverfahren beschreiben wuerde (siehe unten), zu aendern. Es hat die Vorgaben des Modulationsprofils vom CMTS, welches ueber den Downstream in dem UCD verschickt wird, strickt einzuhalten!RcRaCk2k hat geschrieben:...Dann versucht das Modem selbstständig ein niedrigeres Komprimierungsverfahren einzusetzen. Von diesem Szenario ging ich nun aus...
Das einzige was das Kabelmodem von selbst aus machen darf, bis es den ersten Ranging-Response vom CMTS erhalten hat, ist den Sendepegel des Upstreamsignals in 3dB Schritten angefangen bei 68dB(µV) zu erhoehen, sofern das Kabelmodem nicht schon den vorherigen Sendepegel verwendet, welcher bei der letzten erfolgreichen Registrierung verwendet worden ist.
Die Entscheidungsgewalt fuer die verwendete Modulation im Rueckweg liegt einzig und allein beim CMTS.
Die Modulation hat nichts mit einer Komprimierung zu tun. Es kann lediglich aufgrund der geringeren Anzahl von Symbolen pro Sekunde weniger Bytes pro Burst versendet werden, was zu einer Verringerung des moeglichen Datendurchsatzes fuehrt. Weiter ist ein geringerer Modulationsindex (QPSK) robuster gegen Stoereinfluesse als als ein hoeherer (z.B. 16QAM).
Eine Komprimierung bedeutet fuer mich dass die gleiche Nutzlast effektiver Verpackt wird und somit mit weniger Datendurchsatz in der gleichen Zeit uebertragen werden kann. Das ist hier aber nicht der Fall.
mfg
wittmann
RFC 1925 Rule (4)
Some things in life can never be fully appreciated nor understood unless experienced firsthand.
Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
wittmann
RFC 1925 Rule (4)
Some things in life can never be fully appreciated nor understood unless experienced firsthand.
Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.