Inoffizielles Vodafone-Kabel-Forum

Aber 90% der Codewords?

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

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

Das TC4400 hat übrigens keinen Puma Chipsatz sondern einen Broadcom.

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

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.

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

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.

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.

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.