Weil -wie ich schon schrieb- Vodafone gerne mal am falschen Ende spart. Wen die DSLAM VERNÜNFTIG DIMENSIONIERT(!) angebunden sind, gibt's keine Überlastung! PUNKT!DarkStar hat geschrieben:[...]Und das es keine Überlastung bei VDSL gibt...solche Aussagen sind ein Tritt in den [zensiert] all derer Vodafone Kunden die in der Vergangenheit unter anderen in Berlin damit zu kämpfen hatten.
Bei VF scheint dies aber Mode zu sein, die Netze über die Grenzen hinaus zu belegen - siehe Segmentüberlastung im Kabelnetz. Wenn der Betreiber weiß, dass das Netz dicht ist, kann er nicht noch weitere Kunden aufnehmen - macht VF aber! Und das nicht nur fahrlässig, sondern in meinen Augen schon mit Vorsatz.
Immerhin ist die Telekom dann so ehrlich und sagt: Kein Port mehr frei, geht kein DSL - statt dem Kunden eine neue Leitung zu schalten und genau zu wissen, dass die Kapazität dafür nicht ausreicht.
Und was hat das jetzt mit "Shared Medium" zu tun, wie du es in deinem letzten Post weismachen wolltest? Merkst selbst...Ist doch vollkommen unerheblich ob die Überlastung nun durch ein Überbuchtes Segment zu Stande kommt oder daher das die DSLAM nich schnell genug mit genügend Banbreite angebunden ist.
VF hat die DSLAMs nicht schnell genug angebunden - unter anderem deshalb gab's die Probleme.
Und es macht einen großen Unterschied, ob die Bandbreite VOR dem CMTS, wo sich alle Kunden des Segments die Kapazität aufgrund der gemeinsamen Übertragung teilen, nicht reicht -oder- ob die Bandbreite HINTER dem CMTS/DSLAM nicht reicht. Die Auswirkungen sind zwar die Gleichen, jedoch sind es andere Ursachen. Bei der Anbindung von DSLAM/CMTS zum nächsten Knotenpunkt weiß man VORHER, welche Bandbreite man braucht - die ergibt sich im Fall vom DSLAM aus der Anzahl der Linecards multipliziert mit der Kapazität pro Linecard. Im Fall des CMTS ergibt sich die Kapazität aus der Summe der geschalteten DS- und US-Kanäle. Und das steht VOR DEM BAU des DSLAM bzw. des CMTS fest!
Wenn man nun neue Linecards [bei DSL] installiert -oder- zusätzliche DS/US-Kanäle schaltet [beim CMTS/DOCSIS], dann muss NATÜRLICH die Anbindung des DSLAM/CMTS auch passen - und hier hat VF gerne in der Vergangenheit "gepennt", insbesondere im Bereich, wo VDSL und Kabelnetz parallel lagen, wurde da beim VDSL gerne überbucht, damit die Kunden einen Anreiz haben, ins Kabelnetz wechseln.
Unabhängig von der Kapazität der Anbindung vom CMTS/DSLAM zum nächsten Knotenpunkt gibt's im Kabelnetz -aufgrund des Shared Mediums namens Koax-Kabel- das Problem, dass sich alle Kunden eines Segments die verfügbare Bandbreite (d.h. die Summe der Kapazitäten der geschalteten US/DS-Kanäle) teilen. Sollte hierbei die Summe der gebuchten/verkauften Kundenleitungen deutlich größer als die verfügbare Bandbreite des Segments sein, reicht die Bandbreite zwischen CMTS und Modem für den Einzelkunden nicht mehr aus und es kommt zum Geschwindigkeitseinbruch. Da hilft dann auch keine dickere Anbindung des CMTS, weil das Problem VOR dem CMTS auftritt.
Dieses Verhalten gibt's beim DSL zwischen DSL-Modem und DSLAM NICHT! Egal wie viele Kunden DSL gebucht haben, auf die einzelne Leitung des Kunden hat dies keinen oder nur marginalen Einfluss [z.B. durch Übersprechen]
Kleiner Nachtrag zum verlinkten Artikel:
Wenn du ihn richtig gelesen hättest, hättest du gemerkt, dass VF hier auf Leitungen der Telekom (d.h. Bitstrom-Zugänge) zurückgegriffen hat, statt selbst Leitungen zu legen.
Hierfür muss(te) aber VF auch einen Bandbreitenkorridor angeben, sprich Leitungskapazität auf der Zuleitung zu DSLAM einkaufen - und da hat VF "geschlafen" bzw. zu wenig Kapazität bestellt.
Denn -wie auch im Artikel genannt- als VF mehr Bandbreite bei der Telekom bestellt hat [und das ging mal ohne Bauarbeiten oder anderweitige Kabelverlegerei], verschwanden die Probleme...
Ergo war hier nicht die Technik Schuld am Desaster (sprich die vorhandene Anbindung zu "schmal"), sondern da wurde seitens VF rumgegeizt und zu wenig Kapazität auf der vorhandenen Leitung bei der Telekom bestellt - denn die Telekom lässt sich neben der reinen TAL bei Bitstromzugängen natürlich auch jedes Gigabyte im Backbone entsprechend vergüten...