Bandbreitenreservierung NGN

[tuxtux]

Ich habe wirklich schon überall rumgesucht aber nichts aussagekräftiges zu dem Thema gefunden - deswegen versuch ichs mal so:
Kann es sein, dass Hansenet bei NGN-Anschlüssen bis zu 2(!!!) Mbit(!!!!!!) für die Fernwartung und VOIP reserviert und man sie so beim normalen Surfen nicht nutzen kann?!
Ich habe bei mir vollen Sync (also 16124 kb/s) habe aber wenn es ganz hoch kommt einen maximalen Download von ca 13900 kb/s. Klar sind die Speedtests nicht wirklich aussagekräftig, aber aus Arcor-Zeiten kenne ich da eine Abweichung von 100, höchstens 200 kbit/s.
An verschieden Stellen habe ich gelesen, dass für VOIP nicht wirlich was reserviert, sondern dass die Pakete "nur" prorisiert werden, wenn denn dann wirklich telefoniert wird. Habe das auch schon getest in dem ich die die PVC-Parameter für (1/35) genommen habe und nicht VOIP, sondern die normalen Inet-Zugangsdaten benutzt habe - das hat tatsächlich funktioniert und gab einen Download von ca. 130 kb/s (also ca. 2 ISDN-Kanäle - habe auch die sog. ISDN-Variante).

Weiß vielleich jemand woran das liegen könnte bzw. ob Hansenet Bandbreite reserviert(für was auch immer)???

 

[frank_m24]

Hallo,

NGN Anschlüsse werden üblicherweise mit 2 PVCs (Permanent Virtual Connection) realisiert. Eine PVC wird auf ATM Ebene etabliert und ist Transportkanal für eine PPP Verbindung.
Die sog. 2. PVC für VoIP wird häufig als CBR (Constant Bit Rate) Variante ausgelegt - d.h. die Bandbreite wird belegt unabhängig davon, ob Daten darüber fließen oder nicht. Nur so lässt sich QoS wirklich garantieren. Ob das bei Alice auch so ist, kann ich nicht mit Sicherheit sagen, halte es aber für wahrscheinlich.

So wie von dir beschrieben kann man die Bandbreite nicht so ohne weiteres messen, da die Parameter einer PVC erheblich mehr als nur VPI/VCI umfassen. Eine PVC wird in der Box standardmäßig als UBR eingerichtet, also "alles was geht". Du bist bei deinem Download-Test nur auf das Proxy-Limit von Alice gestoßen. Bei 1&1 wird die 2. PVC in CBR mit einer PCR (Peak Cell Rate) von 603 konfiguriert. Eine ATM Zelle transportiert 53 Byte inkl. Header, mit 603 Zellen pro Sekunden kommt man somit auf 603*53*8 = 255672 Bit/s, also etwa 256 kBit/s, was für ca. 3 - 5 Telefonate gleichzeitig reicht (je nach Codec).

Von daher sind die Einbrüche in der Größenordnung von 2 MBit/s auf andere Effekte zurückzuführen, aber nicht auf die Reservierung für VoIP.

 

[RAMler]

Entschuldigt wenn ich das alte Thema hier wieder ausgrabe, aber es passt genau zu meiner Frage und per SuFu/Google bin ich dann auch hier gelandet.

Ich habe eine AliceBox. Die zweite PVC hat als QoS Class vbr-rt. Die Box synct aktuell im Upload mit 666kbit/s netto, trotz allem kann ich nur ~257kbit/s netto nutzen.

Wieso das? Wäre es ne CBR Verbindung, ok, aber so? Zudem ist in der Box die dritte PVC (1/34 als UBR) auch eingerichtet, obwohl ich kein home-tv nutze. Kann es damit zusammen hängen?

 

[frank_m24]

Hallo,

Die zweite PVC hat als QoS Class vbr-rt.

Sicher? Die PVC für VoIP nutzt meistens CBR mit fest eingestellter PCR.

 

[RAMler]

100%ig sicher.

Siehe: http://666kb.com/i/bmldlnp2nnvqthuc5.jpg

EDIT:

Grad auffen FTP geuppt - 68KB/s. Ist zwar etwas unter den Werten, die ich haben sollte, aber ok - damit kann ich leben.

Hat sich daher also erledigt. Wieso es nun geht? Keine Ahnung.

 

[RAMler]

Entschuldigt wenn ich das hier wieder ausgrabe, aber kann es sein das die Fritzbox 7270 bzw. allgemein die aktuellen AVM Firmware Versionen CBR und co schlicht weg ignorieren?

Setze ich die zweite PVC auf CBR mit nem PCR von 1300 wird nichts fest reserviert. Es ist genau gleich, als wenn ich UBR nehme. VBR lässt sich im Übrigen gar nicht (mehr?) nutzen. Die Box läuft dann nicht mehr (keine Einwahl mehr, er versucht es erst nicht mal).

 

[frank_m24]

Wie hast du das ganze denn getestet? Jetzt komm nicht mit einem Speedtest!

 

[RAMler]

Gibt durchaus Speedtests, die i.d.R. eher zu niedrig, als zu hoch messen.

Aber ich hab Kram auf meinen FTP geschoben & davon gezogen. In beide Richtungen Vollgas und in der Fritze steht die zweite PVC auf CBR mit PCR 1300. Sollte ja eigentlich die erste PVC um ~540kbit drosseln, macht es aber nicht.

VBR einstellen geht wie gesagt gar nicht (mehr?). Er übernimmt das inner ar7 zwar und behält das auch nach reboot bei, aber es gar keine Verbindung mehr.

 

[frank_m24]

Gibt durchaus Speedtests, die i.d.R. eher zu niedrig, als zu hoch messen.

Die Formulierung zeigt schon das ganze Dilemma um Speedtests. "idR eher zu niedrig als zu hoch". Ah ja. Ich möchte eine präzisen Messwert, keinen i.d.R. zu niedrigen.

Aber ich hab Kram auf meinen FTP geschoben & davon gezogen.

Und wo steht der?

 

[RAMler]

Ganz ehrlich, ich verstehe nicht auf was du eigentlich hinaus willst. Ich erreiche über WAN vollen Speed, trotz CBR, was eigentlich nicht so sein dürfte. Darum ging es und um sonst nichts.
Ob mir das nun ein Speedtest anzeigt, der mit Pech zu niedrig messen würde, oder mein Webspace/FTP Zugang in einem Rechenzentrum, ist doch belanglos.

Aber um genau zu sein:
Der Server steht in einem Rechenzentrum (FaM) mit 100Mbit Anbindung (Level3). Ändern an den bisherigen Infos aber auch nichts.

 

[frank_m24]

Hallo,

Ich erreiche über WAN vollen Speed, trotz CBR, was eigentlich nicht so sein dürfte.

Ich will wissen, wie du zu dieser Aussage kommst. Du kannst das nämlich nicht messen. Du müsstest Einfluss auf alle zwischen dem Server und dem Client liegenden Komponenten haben. Das ist definitiv nicht der Fall, wenn die Daten übers Internet fließen. Deshalb sind all deine Aussagen im Moment rein spekulativ, da du überhaupt nicht beurteilen kannst, wie die Messergebnisse überhaupt zustande kommen.

Vielleicht ist auch deine 2. PVC ja nicht richtig eingerichtet? Hast du sie per TR-069 einrichten lassen? Wie dem auch sei: Mit den uns zur Verfügung stehenden Methoden werden wir hier nicht zu einer definitiven Aussage kommen.

 

[RAMler]

Über TR-069 bei Alice mit Fremdhardware wohl eher nicht.

Und wieso kann ich das nicht messen? Wenn ich nen Sync von 3400/700 brutto habe und netto Werte erreiche, die knapp 15% darunter liegen, dann bin ich am realen Limit der Leitung.
Würde die gesetzte CBR der zweiten PVC greifen, müsste ich mit meinen Werten definitiv darunter liegen. Ich habe aber mit gesetztem UBR die gleichen Werte, wie mit gesetztem CBR und VBR lässt sich nicht mal setzen. Oder um es ganz einfach zu machen: Wenn ich mit meinem Speed über dem Tempo liege, das ich bei aktiviertem CBR haben dürfte, dann weiß ich doch das es nicht greift und etwas nicht stimmt. :roll:

Ar7 - zweite PVC:

  }
  vccs {
          VPI = 1;
          VCI = 35;
          traffic_class = atm_traffic_class_CBR;
          pcr = 1300;
          scr = 650;
          priority = 1;
          dsl_encap = dslencap_pppoe;
          ipbridgeing = no;
          ipbridgeing_igmp = no;
          pppoeforwarding = no;

Wären die Werte zu niedrig, könnte ich deine Argumentation vielleicht noch ein Stück nachvollziehen, aber so? Ich lade mit dem was die Leitung her gibt auf meinen FTP hoch und runter. Das CBR flag greift also faktisch nicht. Und es ist gleichgültig, ob ich da nun meinen FTP nehme oder von einem Uniserver nen Knoppix lade. Bei passender Gegenstelle laste ich die Leitung komplett aus.

Aber du kannst mir gerne mitteilen, wie ich es besser/anders testen könnte. Vielleicht gibt es hier auch ein Missverständnis, keine Ahnung. :-/

EDIT:
Du kannst ja des Spaßes halber in deiner Fritze mal die zweite PVC, sofern genutzt, auf VBR setzen und sehen was passiert. Bei mir versucht die Fritze danach nämlich nicht einmal mehr eine Einwahl, auf keiner der beiden PVCs.

 

[frank_m24]

Ok, damit ist die ganze Diskussion eh rein akademisch. Da du niemals eine Konfiguration erzeugen kannst, die exakt zum dem passt, was die Alice Infrastruktur von deiner Hardware erwartet, kannst du auch nicht damit rechnen, dass sich das System so verhält, wie du es erwartest. Denn das sich PVCs nicht so verhalten, wie du es erwartest, kann auch an der Gegenseite liegen, und nicht nur an der Fritzbox. Wer weiß, mit welchen Parametern sich die Verbindungen wirklich etablieren, wenn beide Seiten mit Parametern arbeiten, die nicht kompatibel sind?

Und wieso kann ich das nicht messen?

Es macht wenig Sinn, dir hier die Grundlagen von Messtechnik zu erläutern, aber in dem Augenblick, wo es Komponenten in der Messstrecke gibt, auf die du keinen exklusiven Zugriff hast und in der zufällige externe Ereignisse eintreten können, ist das Messergebnis nur noch auf WC zum Abwischen zu verwenden. Wer weiß, was Puffermechanismen und Proxys auf dem Weg zwischen dir und dem Server alles anstellen? Wie ich in meinem Howto über Geschwindigkeitsprobleme schon schrieb, kann ich dir mit einem UMTS Handy, dass definitiv nur 384 kBit/s in beide Richtungen übertragen kann, Messwerte von 8 MBit/s und mehr in beide Richtungen erzeugen. Wie erklärst du mir das? Und wie willst du sicherstellen, dass bei dir nicht ähnliches passiert?

Wenn ich nen Sync von 3400/700 brutto habe und netto Werte erreiche, die knapp 15% darunter liegen, dann bin ich am realen Limit der Leitung.

Kommt drauf an. Was genau hast du denn gemessen? Ist es die Ethernet-Rate, dann wäre ich von 15% darunter massiv enttäuscht.

Oder um es ganz einfach zu machen: Wenn ich mit meinem Speed über dem Tempo liege, das ich bei aktiviertem CBR haben dürfte, dann weiß ich doch das es nicht greift und etwas nicht stimmt. :roll:

Genau. In erster Linie weißt du dann, dass dein Messaufbau Käse ist.

Aber du kannst mir gerne mitteilen, wie ich es besser/anders testen könnte. Vielleicht gibt es hier auch ein Missverständnis, keine Ahnung. :-/

Testen kannst du es in einem Labor mit einer geeigneten DSLAM Messgegenstelle. Sowas wird von einigen Laboren, z.B. Fraunhofer-Instituten, als Dienstleistung angeboten. Dort kannst du auch sehen, mit welchen Parametern sich die Verbindungen wirklich etabliert haben und wie sie sich während der Messung verhalten. Das ist die einzige Chance, es wirklich reproduzierbar und zuverlässig herauszufinden.

Im Moment weißt du nur, dass etwas nicht stimmt. Was nicht stimmt, weißt du nicht. Eins kann ich dir aber sicher sagen: Dein Endgerät und deine Konfiguration stimmt ganz sicher nicht. Das solltest du bei all deinen Versuchen berücksichtigen. Genau damit ist deine Weisheit aber auch schon am Ende. Was willst du jetzt machen? Du kannst ja nicht sehen, was der Alice DSLAM auf der anderen Seite macht. Vielleicht schmeißt er schon nach dem ersten Verbindungsversuch deiner Box einen Haufen Fehlermeldungen und fällt in ein Notfallprogramm zurück? Du wirst es nie erfahren.

 

[RAMler]

Sollte jemand eine 7270v3 haben, könnte er ja mal testen ob sich die Box beim Setzen von VBR auf der zweiten PVC genau so verhält, wie es meine 7270v3 am Alice Anschluss tut. Das wäre wenigstens hilfreich und ich wüsste zumindest schon einmal, ob die Box oder Gegenstelle zickt.

Zu einem Verbindungsversuch kommt es im Übrigen, wenn sie auf VBR steht, laut Logs nicht einmal. Ein IAD5130 nutzt im Übrigen auch VBR, hat aber eine ältere FW intus, auch daher die Vermutung das AVM etwas geändert hat.

kann ich dir mit einem UMTS Handy, dass definitiv nur 384 kBit/s in beide Richtungen übertragen kann, Messwerte von 8 MBit/s und mehr in beide Richtungen erzeugen. Wie erklärst du mir das? Und wie willst du sicherstellen, dass bei dir nicht ähnliches passiert?

Ich bin gespannt, wie du z.B. eine 50MB .rar Datei mit den 8Mbit/s übertragen willst. Das du irgendwelche peaks erreichen kannst bezweifle ich nicht, das du allerdings von DE nach *Ausland xyz* auf einen Server eine große (nicht kompressionsfähige!) Datei mit mehr als den 384Kbit/s schaufelst, bezweifle ich.

Deine ganzen theoretischen Weisheiten sind weder konstruktiv, noch hilfreich. Natürlich kann man nicht jeden Faktor zu 100% belegen, aber hier nun mit Laboraufbauten zu kommen ist wirklich "leicht" übertrieben oder, um es auf den Punkt zu bringen, lächerlich.

Wenn ich eine größere, gepackte Datei mit einer Durschnittsgeschwindigkeit die meiner Leitung entspricht auf meinen FTP schiebe, dann ist das Ergebnis im normalen Leben durchaus zu gebrauchen und belegt, das die zweite PVC keine Geschwindigkeit reserviert. Ob das Ergebnis nun Laborergebnissen gerecht werden könnte, ist dabei vollkommen irrelevant. Es steht fest, dass ich schneller bin, als ich bei CBR auf der zweiten PVC sein dürfte.

Du wirst es nie erfahren.

Wenn sich niemand mit 7270v3 erbarmen sollte das mit VBR mal gegen zu testen, dann magst du recht haben ...


EDIT:

Kommt drauf an. Was genau hast du denn gemessen? Ist es die Ethernet-Rate, dann wäre ich von 15% darunter massiv enttäuscht.

Wieso? Die Ct schrieb damals 14,39% Overhead.

Wenn ich nun (Synckbit/s / ATM brutto byte) x MSS byte rechne, kommt das auch hin. Sync von 3400 wären dann max ~363KB/s die man an seinem Rechner erreicht.

 

[frank_m24]

Hallo,

Sollte jemand eine 7270v3 haben, könnte er ja mal testen ob sich die Box beim Setzen von VBR auf der zweiten PVC genau so verhält, wie es meine 7270v3 am Alice Anschluss tut. Das wäre wenigstens hilfreich und ich wüsste zumindest schon einmal, ob die Box oder Gegenstelle zickt.

Nein, das weißt du nicht. Weil du eben die Reaktion der Gegenstelle in beiden Fällen nicht beurteilen kannst.

Ich bin gespannt, wie du z.B. eine 50MB .rar Datei mit den 8Mbit/s übertragen willst. Das du irgendwelche peaks erreichen kannst bezweifle ich nicht, das du allerdings von DE nach *Ausland xyz* auf einen Server eine große (nicht kompressionsfähige!) Datei mit mehr als den 384Kbit/s schaufelst, bezweifle ich.

Lies noch mal präzise. Ich habe nicht gesagt, dass ich die Datei schneller übertrage. Ich habe gesagt, dass ich ein Messergebnis erzeugen kann, dass diese Werte anzeigt, trotz der eingeschränkten Datenrate. Mit den üblichen Tools, z.B. einem ganz formalen FTP Client und der Zeitanzeige oder iperf.

Deine ganzen theoretischen Weisheiten sind weder konstruktiv, noch hilfreich. Natürlich kann man nicht jeden Faktor zu 100% belegen, aber hier nun mit Laboraufbauten zu kommen ist wirklich "leicht" übertrieben oder, um es auf den Punkt zu bringen, lächerlich.

Ob es übertrieben ist, sei dahingestellt. Fakt ist, dass du eine Aussage zu erzeugen versuchst, die du mit den dir zur Verfügung stehenden Mitteln schlicht nicht treffen kannst. Immerhin erhebst du hier signifikante Vorwürfe, aber auf welcher Basis? Auf einem dilettantischen, nicht reproduzierbaren und ungeeigneten Messaufbau.

Wieso? Die Ct schrieb damals 14,39% Overhead.

14,39% wovon ergeben welchen Wert?

Wenn ich nun (Synckbit/s / ATM brutto byte) x MSS byte rechne, kommt das auch hin. Sync von 3400 wären dann max ~363KB/s die man an seinem Rechner erreicht.

Die Formel kann ich nicht nachvollziehen. Welche Werte hast du da exakt angenommen? Warum teilst du eine Bitrate durch einen Bytewert?
Und dann: 363 kByte/s was denn? Ethernetrate? IP-Rate? TCP-Rate? FTP-Rate?

 

[RAMler]

Nein, das weißt du nicht. Weil du eben die Reaktion der Gegenstelle in beiden Fällen nicht beurteilen kannst.

Natürlich kann mir das eine verbindliche Antwort darauf geben. Sollte VBR bei ihm laufen, liegt es bei mir definitiv nicht an der Box selbst.
Wenn es bei ihm auch nicht geht, ist es halt wieder offen, aber die Wahrscheinlichkeit das die Gegenstelle schuld ist sinkt.

Lies noch mal präzise. Ich habe nicht gesagt, dass ich die Datei schneller übertrage. Ich habe gesagt, dass ich ein Messergebnis erzeugen kann, dass diese Werte anzeigt, trotz der eingeschränkten Datenrate. Mit den üblichen Tools, z.B. einem ganz formalen FTP Client und der Zeitanzeige oder iperf.

Ich lese präzise und habe dir z.B. gesagt, dass ich die Datei so schnell übertrage, wie es meine Leitung ermöglicht. Das allerdings stellst du scheinbar zig mal in Frage, anstatt es einfach mal als gegeben zu akzeptieren.

Das du irgendwelche falschen Ergebnisse generieren kann, interessiert da nicht die Bohne. Wenn ich 50MB in XYZ Sekunden übertrage, lässt sich die angezeigte Geschwindigkeit ja sehr einfach verifizieren. Ich hab meine Leitung trotz CBR flag auslasten können, ist nun einmal so. Wieso du das nicht einfach als gegeben hinnehmen möchtest, verstehen wohl nur die Götter.

Ob es übertrieben ist, sei dahingestellt. Fakt ist, dass du eine Aussage zu erzeugen versuchst, die du mit den dir zur Verfügung stehenden Mitteln schlicht nicht treffen kannst. Immerhin erhebst du hier signifikante Vorwürfe, aber auf welcher Basis? Auf einem dilettantischen, nicht reproduzierbaren und ungeeigneten Messaufbau.

Das ist schlicht und ergreifend Unsinn! Und so langsam aber sicher wird es nervig.

Wenn ich nen CBR flag setze und eine Datei mit der mir maximal zur Verfügung stehenden Bandbreite übertragen kann, also nachweislich keine Bandbreitenreservierung stattfindest, was bitte gibt es daran nicht zu verstehen? Ich könnte es dir auch noch per Stoppuhr und Kamera aufnehmen, würde nur beim eigentlichen Problem kein Stück helfen.

Ehrlich, ich weiß wirklich nicht worum es dir hier eigentlich geht. Solch ein Theater wie hier erlebt man wirklich nicht alle Tage. Interesse an wirklicher Hilfe besteht von deiner Seite anscheinend nicht. Statt dessen wird auf Dingen herumgeritten, die beim vorliegenden Fall vollkommen irrelevant sind und nicht helfen (können).

Und eine Lehrveranstaltung für korrekt ermittelte Labormesswerte konnte ich hier auch nicht erkennen.

Die Formel kann ich nicht nachvollziehen. Welche Werte hast du da exakt angenommen? Warum teilst du eine Bitrate durch einen Bytewert?
Und dann: 363 kByte/s was denn? Ethernetrate? IP-Rate? TCP-Rate? FTP-Rate?

Das, was hinten raus kommt, um mal in der praktischen Welt zu bleiben. :roll:

Die gleiche, wie die Ct damals auch. Syncbit dürfte ja klar sein. ATM brutto 1696. MSS halt den üblichen Standard im LAN - 1452.

Du kannst auch folgende Formel nehmen, wenn dich das bit/byte so stört.

Nettodatenrate = Synchronisationsrate * (1452/1696) (bei MTU 1492)

Das Ergebnis ändert sich dadurch trotzdem nicht.

 

[frank_m24]

Natürlich kann mir das eine verbindliche Antwort darauf geben. Sollte VBR bei ihm laufen, liegt es bei mir definitiv nicht an der Box selbst.

Nein, eben nicht. Bei DSL entscheidet die Infrastruktur über die Verbindungsparameter. Die Box kann Dinge beantragen, aber die Gegenseite hat die Hosen an. Also auch wenn jemand von CBR auf VBR umstellt, und sich das Verhalten nicht ändert, dann kann es immer noch daran liegen, dass die Gegenseite die Parameter einfach überstimmt hat. Und das siehst du ja nicht.

Das du irgendwelche falschen Ergebnisse generieren kann, interessiert da nicht die Bohne. Wenn ich 50MB in XYZ Sekunden übertrage, lässt sich die angezeigte Geschwindigkeit ja sehr einfach verifizieren.

Einfaches Beispiel: Du überträgst eine 50 MB Datei von einem Rechner mit DSL16000 Anschluss auf einen Rechner an einem UMTS Modem (384 kBit/s). Die Übertragung wird nach ca. 50 Sekunden als beendet angezeigt. Wie geht das? Das ist deutlich mehr als 384 kBit/s. Antwort: Clevere Proxies in der Infrastruktur puffern die Daten, um sie dann effizient im Hintergrund an den Client zu übertragen. Wer garantiert dir, dass bei deiner Übertragung nicht ähnliches passiert ist? Denn solche Proxies gibt es auf deiner Verbindung. Garantiert.

Mit wem hast du überhaupt telefoniert während des Versuchs? War überhaupt ein ordentlicher Sprachkanal etabliert? Wenn du mit deinem eigenen Anschluss telefoniert hast, dann kann es sein, dass die Daten direkt geroutet wurden, ohne über die Infrastruktur geführt zu werden. Dann siehst du natürlich auch nichts in der Bandbreite.

Interesse an wirklicher Hilfe besteht von deiner Seite anscheinend nicht.

Doch, das Interesse besteht. Deshalb klinke ich mich hier ja ein. Ein eigentliches Problem hast du ja nicht, du versuchst ja nur, technische Abläufe tief unterm Blech der DSL Verbindung zu ergründen. Ich mache dich darauf aufmerksam, dass du dir das deutlich zu einfach vorstellst und dich durch den Augenschein zu falschen Schlüssen verleiten lässt. Ich sehe aber auch keine Möglichkeit, deine Fragen mit den uns zur Verfügung stehenden technischen Mitteln einwandfrei zu beantworten. Willst du die Fragen wirklich belastbar beantworten, dann brauchst du ein DSL Labor, wo du sehen kannst, was passiert.

Das, was hinten raus kommt, um mal in der praktischen Welt zu bleiben. :roll:

Du weißt also nicht, was du misst oder ausrechnest.

ATM brutto 1696.

Das ist eine sehr grobe Näherung. Eine ATM Zelle hat Brutto 53 Byte und Netto 48. Wenn man die Ethernet-MTU als zu übertragende Datenmenge zugrunde legt, dann muss man 1696 Byte in ATM Zellen übertragen. Das würde aber bedeuten, dass alle Ethernetframes exakt mit der MTU gefüllt sein müssten. In der Praxis (und die kommt ja hinten raus) sind das aber weniger als 0,1% aller Frames. Kleinere Pakete, die zwar die Ethernet-MTU nicht ausfüllen, aber ein vielfaches der ATM Zelle beträgt, vernachlässigst du komplett, genauso wie größere Pakete, die segmentiert werden müssen und damit zusätzlichen Overhead erzeugen. Das ist eine Milchmädchen-Rechnung und weit von der Praxis entfernt.

 

[RAMler]

Nein, eben nicht. Bei DSL entscheidet die Infrastruktur über die Verbindungsparameter. Die Box kann Dinge beantragen, aber die Gegenseite hat die Hosen an. Also auch wenn jemand von CBR auf VBR umstellt, und sich das Verhalten nicht ändert, dann kann es immer noch daran liegen, dass die Gegenseite die Parameter einfach überstimmt hat. Und das siehst du ja nicht.

Anscheinend hast du nicht gelesen, was ich geschrieben habe und was du sogar zitiert hast! Aber nochmal "Sollte VBR bei ihm laufen, liegt es bei mir definitiv nicht an der Box selbst." Das ich, wenn es nicht geht, wieder am Anfang stehe, schrieb ich selbst. Das willst du aber scheinbar nicht sehen. Es ist schon sehr amüsant, dass du das Zitat in der Mitte teilst, den Part also entfernst und dann den Rest noch umdrehst. :roll:

Belassen wir es dabei, denn das ganze hier führt zu nichts und um dieses "Spielchen" weiter zu führen ist mir meine Zeit zu schade. Auf den Rest gehe ich deshalb auch nicht mehr ein.

Dir trotz allem noch eine schöne Woche und eine gut laufende Leitung.

 

[RAMler]

Wollte nur mitteilen das ein gesetztes VBR flag mit der neuen 74.05.05 an meinem Alice Anschluss nun zu einer normalen Einwahl führt. Mit den vorherigen Labors passierte gar nichts und er versuchte nicht einmal eine Einwahl.
Ob CBR nun auch fix reserviert wurde noch nicht getestet.