Erfahrungen mit TC4400

Hier dreht sich alles um die aktuell von Vodafone Kabel Deutschland, von Vodafone West bzw. im Rahmen der eazy-Tarife verschickten Kabelrouter der Marken Arris, CommScope, Technicolor, Compal, Sagemcom und Hitron sowie um die SuperWLAN-Produkte von Vodafone. Speedprobleme bitten wir im entsprechenden Forum zu behandeln, wenn ihr Ursprung nicht auf diese Produkte zurückzuführen ist!
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.
in-need-for-speed
Kabelexperte
Beiträge: 841
Registriert: 21.08.2018, 16:44

Re: Erfahrungen mit TC4400

Beitrag von in-need-for-speed »

Aber 90% der Codewords?
in-need-for-speed
Kabelexperte
Beiträge: 841
Registriert: 21.08.2018, 16:44

Re: Erfahrungen mit TC4400

Beitrag von in-need-for-speed »

Yoshi2000, Teste mal mit http://www.dslreports.com/tools/puma6 und http://www.dslreports.com/speedtest !

{Die geben genauere Info über die Reallatenzen und RoundTripTimes.}
sparkie
Kabelexperte
Beiträge: 721
Registriert: 04.09.2010, 12:35

Re: Erfahrungen mit TC4400

Beitrag von sparkie »

Wechsler hat geschrieben: 21.09.2018, 18:15 Da ist alles in bester Ordnung, 0 unkorrigierbare Fehler. Correctables sind bei OFDM völlig normal.
diese Modem-Ausgaben sind aber auch etwas irrefuehrend. Was besagen die schon? Diese Zahlen sind vielleicht notwendig aber nicht hinreichend.

Bei mir z.B. sind die 'Unkorrigierbaren' wochenlang auf 0 und die 'Korrigierbaren' wochenlang im Bereich <100.

Und trotzdem habe ich etwa 1 Stunde lang pro Woche deutliche Paketverluste und zwar sowohl eingehend (ueberwacht von thinkbroadband) als auch ausgehend (ueberwacht von meinen eigenen tools).
Yoshi2000
Newbie
Beiträge: 71
Registriert: 07.10.2017, 19:25
Wohnort: Passau

Re: Erfahrungen mit TC4400

Beitrag von Yoshi2000 »

dslreports.jpg
Das TC4400 hat übrigens keinen Puma Chipsatz sondern einen Broadcom.
Yoshi2000
Newbie
Beiträge: 71
Registriert: 07.10.2017, 19:25
Wohnort: Passau

Re: Erfahrungen mit TC4400

Beitrag von Yoshi2000 »

Wechsler hat geschrieben: 21.09.2018, 18:15 Da ist alles in bester Ordnung, 0 unkorrigierbare Fehler. Correctables sind bei OFDM völlig normal.
Habe mich in englischsprachigen Foren mal umgeschaut. Diese bestätigen das bei ODFM eine höhere Anzahl an Korrigierbaren Fehlern Normal ist im Vergleich zu DOCSIS 3.0. Erst bei unkorrigierbaren sollte man sich sorgen machen. Die Werte sind dort auch so hoch wie bei mir. Denke also es ist alles im grünen Bereich :grin:
in-need-for-speed
Kabelexperte
Beiträge: 841
Registriert: 21.08.2018, 16:44

Re: Erfahrungen mit TC4400

Beitrag von in-need-for-speed »

Also der Spark mit >400ms sollte nicht sein. Könnte aber auch ein Computerhänger gewesen sein. Die sonstigen Laufzeiten der kleinen TCP-Pakete sollten erfahrungsgemäss 15-20ms kürzer sein, es sei denn man hat einen Puma6 :? .

Die Latenz beim Cable Speedtest und die RTTs auf der Results Seite wären noch interessant.
Yoshi2000
Newbie
Beiträge: 71
Registriert: 07.10.2017, 19:25
Wohnort: Passau

Re: Erfahrungen mit TC4400

Beitrag von Yoshi2000 »

Der Bufferbloat im Downstream ist hier so schlecht, seit dem das CMTS von Arris auf Casa gewechselt wurde vor einem Jahr.

Code: Alles auswählen

Server		NettSpeed		RTT / Jitter	Avg	Re-xmit	Avg	Cwnd	Avg
Frankfurt, DE, EU (INTERNAP)	d6	64.84 Mb/s	589.5±33.4ms	0.4%	3257
Amsterdam, Netherlands, EU (softlayer)	d7	32.53 Mb/s	511.5±39.5ms	0.1%	2192
Frankfurt, DE, EU (INTERNAP)	u6	2.95 Mb/s	22±11ms	-	10
Amsterdam, Netherlands, EU (softlayer)	u6	3.18 Mb/s	21.3±10.6ms	-	10
in-need-for-speed
Kabelexperte
Beiträge: 841
Registriert: 21.08.2018, 16:44

Re: Erfahrungen mit TC4400

Beitrag von in-need-for-speed »

Ich hab mir Deine Ergebnisseite mal geladen. Also nach glatt laufen sieht das nicht aus: Timer Drop 1, durchschnittliche ansprechzeit 210ms, RTTs nach Frankfurt und Amsterdam um 900ms im Download, der Lag in der Spitze 2250ms, im Idle sogar noch 988ms Lag. Nur im Upload sieht's besser aus, mit 32-105ms auch nicht traumhaft. Immerhin die reale Upload RTT liegt bei normalen ~21ms.

Also so fährt dein TC4400 Ferrari wie eine Puma 6 Providerbox (mit älterer Firmware). Sorry, für die raue Botschaft. Aber Lösungsvorschläge hab' ich auch schon gemacht.

Warum kann das sein? Millionenfach Fehler zu korrigieren ist zwar möglich (besonders bei OFDM), kostet aber eine heiden Rechenleistung von Modem/Router.
Yoshi2000
Newbie
Beiträge: 71
Registriert: 07.10.2017, 19:25
Wohnort: Passau

Re: Erfahrungen mit TC4400

Beitrag von Yoshi2000 »

Mit der Fritzbox sind die Werte genauso mies (noch schlechter), obwohl der Bug mit dem Puma Chipsatz ja mit neuerer Firmware gefixt wurde . Das CMTS ist hier bei mir das Problem.
Benutzeravatar
wittmann
Fortgeschrittener
Beiträge: 203
Registriert: 24.01.2007, 06:29

Re: Erfahrungen mit TC4400

Beitrag von wittmann »

in-need-for-speed hat geschrieben: 21.09.2018, 19:00 Warum kann das sein? Millionenfach Fehler zu korrigieren ist zwar möglich (besonders bei OFDM), kostet aber eine heiden Rechenleistung von Modem/Router.
Dafuer ist die FEC nunmal da und sie hat KEINEN nennenswerten Einfluss im Delay und laeuft in Hardware. Nicht umsonst verbraucht LDPC auf dem Die einen extrem grossen Anteil der Flaeche. Wie Wechsler schon sagte, ist bei OFDM bzw. der hohen Modulationsrate bei dem Pegel normal und auch so "vorgesehen". Umso frueher man sich von dem Gedanken verabschiedet, dass ein OFDM Signal nur einwandfrei ist, solange man nicht mal korrigierbare Codewords hat, umso besser.

Das Klippen zwischen der Codeword Correction Rate (CCR) und der Codeword Error Rate (CER) ist seit LDPC so dermassen eng geworden, dass die CCR quasi nutzlos geworden ist. Da hilft eigentlich nur eine richtige Bit Error Messung (BER) und die bekommst Du mit Messgeraeten im fuenfstelligen Euro-Bereich. Da sollte man der Margin des OFDM Tuners vertrauen.

Im Uebrigen ist das bei SC-QAM und der CCR nach Reed-Solomon so, dass die CCR ein guter Indikator sein kann. Wichtig ist jedoch, solange es nur bei einer CCR bleibt und die CER bei null ist alles schick! Eine hohe Anzahl von korrigierbaren Codewords allein, ohne hochzaehlen der unkorrigierbaren Codewords, wirkt sich nicht im Durchsatz aus.

Deswegen verstehe ich nicht, warum hier alle Orakeln, weil mal die korrigierbaren Codewords im Webinterface hochzaehlen. So wie ich das sehe, denkt keiner mal danach nach, dass es bei SC-QAM mit 256-QAM und Reed-Solomon 34079 Codewords pro Sekunde sind. Das macht 122.684.400 Codewords in der Stunde und 2.944.425.600 Codewords am Tag. bei einem 32-Bit-Counter laeuft der nach 2 Tagen ueber und dann kann man die vorher gezaehlten korrigierbaren Codewords gar nicht mehr vernuenftig im Verhaeltnis sehen, weil es dort Wochen, Monate oder Jahre dauert bis auch dessen Counter ueberlaeuft.
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.
Antworten