Glasfaser Dt. Glasfaser stoppt Ausbau im Landkreis Karlsruhe

RMS_der_Zweite schrieb:
Vodafone Kabel. Weiß nicht wie sich das aktuell bei VDSL verhält, aber ich würde vermuten das 320 brutto schon noch 300 netto ergeben.
DOCSIS ist hier nicht vergleichbar mit DSL
Bei DOCSIS wird auch nicht gesynct sondern im CMTS sind feste Profile hinterlegt.
 
RMS_der_Zweite schrieb:
Der Abstand zwischen netto und brutto ist doch ziemlich gering seit das nicht mehr in ATM-Zellen verpackt wird?
Naja, mit PPPoE hat man bei IPv6 ziemlich genau 1432 Bytes an TCP-Payload pro Ethernet-Frame, das wiederum 1522 Byte lang ist. Wenn man die Präambel mitzählt sind es nochmal 8 Byte, also insgesamt 1530 Byte. Das ergibt gut 93.5% an TCP-Nutzlast.
Insofern, wenn man wirklich 320 Mbit/s an Ethernet-Paketen übertragen bekommt, dann wären wohl knapp 300 Mbit/s drin. Über IPv4 sollte man das sogar knapp überschreiten.

Dr. Chaos schrieb:
Diese 350Mbits Brutto teilen sich dann auf in 300 Down und 50 Up das ergibt dann 250 Mbits Down und 40 Mbits Up an realen Daten die genutzt werden können.
Die Rechnung verstehe ich aber auch nicht. Aus 400 Mbit/s bidirektionaler Spektrum-Bandbreite werden aufgrund der "Guards" dann 350 Mbit/s bidirektionale brutto-Datenbandbreite, und das soll netto dann 290 Mbit/s bidirektional ergeben. Dann verliert man also 110 Mbit/s an die Guards und den Overhead, also 27.5%. Das ist schon massiv. Stehen die 350 Mbit/s im Standard? Habe das auf die Schnelle nicht gefunden.

Bei 17a sind es 150 Mbit/s bidirektionale Bandbreite auf dem gesamten Spektrum, und am Ende kommt man bei 140 Mbit/s netto heraus, also verliert man hier nur mickrige 6.6% an Guards + Overhead?
 
Web-Schecki schrieb:
Bei 17a sind es 150 Mbit/s bidirektionale Bandbreite auf dem gesamten Spektrum, und am Ende kommt man bei 140 Mbit/s netto heraus, also verliert man hier nur mickrige 6.6% an Guards + Overhead?
Das ist recht einfach erklärt.

Dämpfung und Crosstalk: Höhere Frequenzen (über 17 MHz) werden auf Kupferadern viel stärker gedämpft. Um diese Frequenzen stabil nutzbar zu machen, muss das Vectoring bei 35b wesentlich präziser arbeiten. Der Rechenaufwand für die Fehlerkorrektur und die Verwaltung der Koeffizienten steigt quadratisch zur Anzahl der Träger.
Bei 35b müssen daher mehr Redundanz Bits übertragen werden. Das reduziert die Netto Datenrate im Verhältnis zur Brutto Rate stärker als bei 17a.

Das Schutzintervall (Cyclic Prefix) muss perfekt auf die Leitungslänge und das Profil abgestimmt sein, um die Stabilität gegen Rauschen zu gewährleisten.
 
@Dr. Chaos
So genau verstehe ich deinen Rechenweg trotzdem nicht. Die 150 Mbit/s brutto bei 17a wären extrem konservativ geschätzt und werden selbst im TCP-Netto in der Praxis regelmäßig erreicht. Und bei 35b sollen die 350 Mbit/s brutto eine absolut theoretische Wunschvorstellung sein? Dass die höheren Träger stärker dämpfen und man einen höheren Vectoring-Aufwand hat ist sicherlich im Standard (in den 400 Mbit/s) schon (zumindest zum Teil) eingepreist. Sonst hätte man bei grob doppeltem Spektrum und grob doppelter Sendeleistung wohl eher grob eine vierfach höhere Brutto-Datenrate, und nicht nur Faktor 2.66...

Bei 17a hat man DSLAM-Max-Datenraten von 116/46, wenn ich mich nicht irre, also man übertrifft das Brutto aus dem Standard auch hier schon recht deutlich. Warum sollte das bei 35b, auf dementsprechend kürzeren Leitungen, unmöglich sein? Einfach DSLAM-Max-Datenraten von 320/55 eintragen und schauen, was die Modem und Linecard aushandeln...
 
  • Gefällt mir
Reaktionen: DLMttH
Zurück
Oben