10MBit symmetrisch von der T-Com: Modem T-N10ETH?

[Gross, Michael]

Hallo

Wir sind vor zwei Wochen von unserer 2MBit SDSL Leitung auf eine von der
Telekom als "10MBit-Leitung" vermarkteten Leitung umgestiegen.

Laut dem T-Techniker, der bei uns die Messung durchgeführt hat, handelt
es dabei physikalisch um vier gebündelte SDSL-Leitungen, wobei aber auf
Layer 2 nicht wie für SDSL üblich ATM, sondern Ethernet gesprochen wird.

In der Praxis erreiche ich auch tatsächlich nur rund 8,8MBit/s, was ja
ungefähr 4 x 2,3MBit/s entspricht.

Das von der Telekom installierte Modem trägt die Bezeichnung "T-NT10ETH"

Im Internet findet man zu dem Modem keine Informationen und laut unseres
ISP (der die Info wiederum von der Telekom hat) gibt es in unserer
Umgebung neben uns nur noch einen Kunden, der ebenfalls diese Technik
nutzt.

Hat jemand Infos über das Modem respektive die eingesetzte Technik? So
ganz zufrieden sind wir mit der Leitung nämlich noch nicht.

[Mathias Mergens]

Post by Gross, Michael
Hat jemand Infos über das Modem respektive die eingesetzte Technik? So
ganz zufrieden sind wir mit der Leitung nämlich noch nicht.
rgds, Michael.

Poste mal die Leitungsschlüzzelzahl von deiner Leitung, dann lässt sich auch
einfacher die Technik bestimmen.

Gruß
Mathias

[Shinji Ikari]

Guten Tag

Post by Mathias Mergens
Poste mal die Leitungsschlüzzelzahl von deiner Leitung, dann lässt sich auch
einfacher die Technik bestimmen.

Duerfte eine LSZ "51x" LSZ-Erg "ETH10" oder so sein.
Irgendwo in dem Segment (51x oder 52x oder so) wurden die neuen ETH10
und ETH100 Produkte eingegliedert.

Ist mir aber fuer meien privaten Zwecke zu teuer. 8)

[Gross, Michael]

Hallo

Post by Shinji Ikari

Post by Mathias Mergens
Poste mal die Leitungsschlüzzelzahl von deiner Leitung, dann lässt sich auch
einfacher die Technik bestimmen.

Duerfte eine LSZ "51x" LSZ-Erg "ETH10" oder so sein.

Scheint sich um LSZ 51x zu handeln. Das steht jedenfalls auf der Dose,
an die das Modem angeschlossen ist.

[Shinji Ikari]

Guten Tag

Post by Gross, Michael
Wir sind vor zwei Wochen von unserer 2MBit SDSL Leitung auf eine von der
Telekom als "10MBit-Leitung" vermarkteten Leitung umgestiegen.
Laut dem T-Techniker, der bei uns die Messung durchgeführt hat, handelt
es dabei physikalisch um vier gebündelte SDSL-Leitungen, wobei aber auf
Layer 2 nicht wie für SDSL üblich ATM, sondern Ethernet gesprochen wird.
In der Praxis erreiche ich auch tatsächlich nur rund 8,8MBit/s, was ja
ungefähr 4 x 2,3MBit/s entspricht.

Naja, eigentlich ist meines Wissens es 'nur' 4x2048MBit/s, aber dafuer
eben eine unkomplizierte Sache.

Post by Gross, Michael
Das von der Telekom installierte Modem trägt die Bezeichnung "T-NT10ETH"

T-.Com eigenes Geraet. Meines Wissens in dieser Form nicht im normalen
Handel zu haben.

Post by Gross, Michael
Im Internet findet man zu dem Modem keine Informationen

Ist auch zu neu. Das Gesamt-Produkt ist noch nicht allzu lange im
Portfolio des rosa Riesen.

Post by Gross, Michael
und laut unseres
ISP (der die Info wiederum von der Telekom hat) gibt es in unserer
Umgebung neben uns nur noch einen Kunden, der ebenfalls diese Technik
nutzt.

Ist eben 'brnadneu'.

Post by Gross, Michael
Hat jemand Infos über das Modem respektive die eingesetzte Technik?

Nicht mehr, als das, was eben schon von Dir geschrieben wurde.

Post by Gross, Michael
So
ganz zufrieden sind wir mit der Leitung nämlich noch nicht.

Was stoert Euch denn?
Gibt es Stoerungen? Habt Ihr den Kundendienst kontaltiert?
Was sagt Euer Vertriebs-telekomiker dazu?

[Gross, Michael]

Hi,

Post by Shinji Ikari

Post by Gross, Michael
Wir sind vor zwei Wochen von unserer 2MBit SDSL Leitung auf eine von der
Telekom als "10MBit-Leitung" vermarkteten Leitung umgestiegen.
Laut dem T-Techniker, der bei uns die Messung durchgeführt hat, handelt
es dabei physikalisch um vier gebündelte SDSL-Leitungen, wobei aber auf
Layer 2 nicht wie für SDSL üblich ATM, sondern Ethernet gesprochen wird.
Das von der Telekom installierte Modem trägt die Bezeichnung "T-NT10ETH"
Im Internet findet man zu dem Modem keine Informationen [...]

Ist auch zu neu. Das Gesamt-Produkt ist noch nicht allzu lange im
Portfolio des rosa Riesen.

Das dachten wir uns schon. Anscheinend gibt es dann auch hier noch keine
Erfahrungswerte.

Post by Shinji Ikari

Post by Gross, Michael
So ganz zufrieden sind wir mit der Leitung nämlich noch nicht.

Was stoert Euch denn?

Vor Produktivgang haben wir verschiedene Tests durchgeführt. Dabei kam
es zu Einbrüchen des Uploads, wenn der Download voll belastet war.

Das trat auch mit vier Maschinen auf (um einzelne Rechner bzw. Duplex
auszuschließen). Das Betriebssystem aller Rechner war Linux.

Beispiel: Rechner A uploaded mit 8,5MBit zu Rechner B. Haben wir dann
einen Download auf Rechner C von Rechner D gestartet, sank der Upload
auf 3,5MBit/s, während der Download mit 8,5MBit/s lief.

Ich denke aber inzwischen, dass das in Relation mit der TcpWindowSize
stehen könnte, da die RTT bei Auslastung der Leitung erheblich steigt:

The TCP window is the amount of unacknowledged data in flight
between the sender and the receiver. Data is sent by TCP in
segments that are typically 1460 bytes in length. If the sender
is permitted a window size of only 1 segment, the sender transmits
a single segment, and waits for an acknowledgement from the
receiver. If the transmission delay between sender and receiver
is long, this means very low throughput (very few segments
transferred per unit time). Both sender and receiver spend most
of their time waiting for messages to be transmitted from one end
of the connection to the other. [1]

Bei unbelasteter Leitung habe ich zu einer bei unserem ISP stehenden
Maschine i.d.R. eine RTT von 5ms.

Ist eine Richtung unserer Leitung ausgelastet, steigt sie auf 40ms;
bei voller Auslastung tendiert sie gegen 80ms.

Hinzu kommt, dass dasselbe Problem bei Tests mit Windows Server 2003
SP1 nicht auftritt -- hier sind immer mind. 8,5MBit symmetrisch drin.

Wobei -- merkwürdigerweise -- das nur bei Windows Server 2003 *mit*
SP1 der Fall ist, ohne SP1 treten dieselben Phänomene wie mit Linux
auf.

Was Microsoft da genau geändert hat, erschließt sich mir noch nicht;
ich würde aber auf Änderungen an der TCPWindowSize tippen.

Post by Shinji Ikari
Gibt es Stoerungen? Habt Ihr den Kundendienst kontaltiert?
Was sagt Euer Vertriebs-telekomiker dazu?

Ich habe keinen direkten Kontakt zur Telekom, das läuft alles über
unseren ISP.

Lauf Information unseres Providers hat der Techniker aber auf den
Modems Ethernet-Fehler feststellen können.

Das wurde bis jetzt aber nicht näher untersucht (Telekom-Techniker
ist im Urlaub und hier in der Gegend gibts wohl nur zwei der neuen
Technik mächtigen Mitarbeiter).

Mittlerweile mussten wir die Leitung aus politischen Gründen auch
produktiv nehmen und damit sind Tests der T-Com erst mal abgesagt.

Wie auch immer: Ich denke, es liegt eher an der Testumgebung als
an der Leitung selbst. Woran genau, müssen wir noch rausfinden.

Wobei ich grundsätzlich sagen muss, dass mir der Anstieg der Latenz
um Faktor 20 bei ausgelasteter Leitung recht hoch erscheint.

Mit unserer 2,3MBit SDSL Leitung schien mir das nicht so arg ins
Gewicht zu fallen, wobei ich mich da auch irren kann.

Wegen meiner Vermutung der TcpWindowSize Crosspost to d.c.p.tcp-ip

[1] http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm

[Detlef Bosau]

Langsam wird das hier eine Troll-Gruppe.

Post by Gross, Michael
Hi,

Post by Gross, Michael
Wir sind vor zwei Wochen von unserer 2MBit SDSL Leitung auf eine von der
Telekom als "10MBit-Leitung" vermarkteten Leitung umgestiegen.
Laut dem T-Techniker, der bei uns die Messung durchgeführt hat, handelt
es dabei physikalisch um vier gebündelte SDSL-Leitungen, wobei aber auf
Layer 2 nicht wie für SDSL üblich ATM, sondern Ethernet gesprochen wird.
Das von der Telekom installierte Modem trägt die Bezeichnung "T-NT10ETH"

Man möge dem Techniker ausrichten, daß auf SDSL, wie der Name schon
nahelegt, SDSL gesprochen wird und nicht Ethernet.

Und wenn der Techniker den Unterschied zwischen SDSL und Ethernet nicht
kennt, möge er seinen Technikerbrief zurückgeben und öffentlich vor dem
Bundestag für die Wiedereinführung der Prügelstrafe plädieren und um
seine öffentliche Auspeitschung betteln.

Was werden da eigentlich für Leute durchgefüttert, wenn ich mal direkt
fragen darf?

Post by Gross, Michael
Vor Produktivgang haben wir verschiedene Tests durchgeführt. Dabei kam

^^^^^^^^^^^^^^^^^^^

Welche?

Mit "verschiedenen Tests" kommen wir wohl kaum weiter.

Post by Gross, Michael
es zu Einbrüchen des Uploads, wenn der Download voll belastet war.
Das trat auch mit vier Maschinen auf (um einzelne Rechner bzw. Duplex
auszuschließen). Das Betriebssystem aller Rechner war Linux.

Das kann auch mit 10 Maschinen auftreten.

Was ist Euer Problem?

Post by Gross, Michael
Beispiel: Rechner A uploaded mit 8,5MBit zu Rechner B. Haben wir dann
einen Download auf Rechner C von Rechner D gestartet, sank der Upload
auf 3,5MBit/s, während der Download mit 8,5MBit/s lief.
Ich denke aber inzwischen, dass das in Relation mit der TcpWindowSize

Bevor hier wieder über TCP Fenster rumschwadroniert wird, sei die
Einsteigerliteratur empfohlen.

Das ist hier nicht der Kindergarten.

Also bitte:

Entweder kommt jetzt eine konzise Problembeschreibung oder abe Du gehst weg.

Ein Elcaro Nosille reicht mir.

Und die TCP/IP Gruppe ist die TCP/IP Gruppe und nicht die Gruppe für
"Wir basteln Windows" oder "Wir bringen Technikern ihr Handwerk bei".

[Gross, Michael]

Post by Detlef Bosau
Entweder kommt jetzt eine konzise Problembeschreibung

Wahrscheinlich kann ich es Dir mangels fachlicher Kompetenz auf meiner
Seite gar nicht präzise genug erklären.

Was ich allerdings aufgrund fehlender Sozialkompetenz deinerseits auch
gar nicht mehr wollen würde.

Post by Detlef Bosau
oder abe Du gehst weg.

[x] done.

[Detlef Bosau]

Post by Gross, Michael

Post by Detlef Bosau
Entweder kommt jetzt eine konzise Problembeschreibung

Wahrscheinlich kann ich es Dir mangels fachlicher Kompetenz auf meiner
Seite gar nicht präzise genug erklären.

Man kann einfach erklären, wsa man beobachtet.

Wenn man das sauber tut, hilft das schon wehr weit.

Es reicht schon, die ganzen "Diagnosen" wegzulassen.

[Detlef Bosau]

Post by Gross, Michael
Was ich allerdings aufgrund fehlender Sozialkompetenz deinerseits auch
gar nicht mehr wollen würde.

Und hör auf von Sozialkompetenz zu schwdronieren, es geht hier um
TCP/IP, das ist hier weder die "Psychologie heute" noch die örtliche
Kirchengemeinde.

[Elcaro Nosille]

Post by Detlef Bosau

Post by Gross, Michael
Was ich allerdings aufgrund fehlender Sozialkompetenz
deinerseits auch gar nicht mehr wollen würde.

Und hör auf von Sozialkompetenz zu schwdronieren, es geht hier um
TCP/IP, das ist hier weder die "Psychologie heute" noch die örtliche
Kirchengemeinde.

Du bist einfach nur plemplem.

[Ralph A. Schmid, DK5RAS]

Post by Gross, Michael
Wahrscheinlich kann ich es Dir mangels fachlicher Kompetenz auf meiner
Seite gar nicht präzise genug erklären.
Was ich allerdings aufgrund fehlender Sozialkompetenz deinerseits auch
gar nicht mehr wollen würde.

Ignoriere den einfach, es bringt nix, mit dem Typen zu diskutieren
oder auch nur ein Wort an ihn zu verschwenden. Seine Defizite hast Du
ja erkannt und treffend skizziert...

Ralph.

[Juergen Ilse]

Hallo,

Post by Detlef Bosau
Langsam wird das hier eine Troll-Gruppe.

Evt. hat der Techniker aber zumindest in einem Punkt gar nicht so Unrecht ...

Post by Detlef Bosau

Post by Gross, Michael

Post by Gross, Michael
Wir sind vor zwei Wochen von unserer 2MBit SDSL Leitung auf eine von der
Telekom als "10MBit-Leitung" vermarkteten Leitung umgestiegen.
Laut dem T-Techniker, der bei uns die Messung durchgeführt hat, handelt
es dabei physikalisch um vier gebündelte SDSL-Leitungen, wobei aber auf
Layer 2 nicht wie für SDSL üblich ATM, sondern Ethernet gesprochen wird.
Das von der Telekom installierte Modem trägt die Bezeichnung "T-NT10ETH"

Man möge dem Techniker ausrichten, daß auf SDSL, wie der Name schon
nahelegt, SDSL gesprochen wird und nicht Ethernet.

Es gibt anscheinend einige wenige (wirklich *sehr* *wenige*) Hersteller
(moeglicherweise auch nur einen, ich habe mir dieses Zeug nie richtig
angesehen), die DSL-Technik bauen, die eben nicht "ATM over DSL" macht,
sondern direkt Ethernet-Frames statt ATM-Zellen ueber DSL uebertraegt.
Das Zeug funktioniert dann natuerlich nur, wenn sowohl CPE als auch
DSLAM vom selben Hersteller stammen, mit dem "ueblichen Kram" ist das
Zeug gaenzlich inkompatibel. Evt. setzt die Telekom so ein Zeug fuer
dieses Produkt ein.

Post by Detlef Bosau
Und wenn der Techniker den Unterschied zwischen SDSL und Ethernet nicht
kennt, möge er seinen Technikerbrief zurückgeben und öffentlich vor dem
Bundestag für die Wiedereinführung der Prügelstrafe plädieren und um
seine öffentliche Auspeitschung betteln.

Nun ja, *SOOO* falsch laege er ja mit seiner Behauptung nicht, wenn
tatsaechlich dieses exotische Zeug da fuer "Ethernet-Bridging oeber DSL"
verwendet wird.

Post by Detlef Bosau

Post by Gross, Michael
Vor Produktivgang haben wir verschiedene Tests durchgeführt. Dabei kam

^^^^^^^^^^^^^^^^^^^
Welche?

Interessante Frage ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Olaf Selke]

Post by Juergen Ilse
Es gibt anscheinend einige wenige (wirklich *sehr* *wenige*) Hersteller
(moeglicherweise auch nur einen, ich habe mir dieses Zeug nie richtig
angesehen), die DSL-Technik bauen, die eben nicht "ATM over DSL" macht,
sondern direkt Ethernet-Frames statt ATM-Zellen ueber DSL uebertraegt.
Das Zeug funktioniert dann natuerlich nur, wenn sowohl CPE als auch
DSLAM vom selben Hersteller stammen, mit dem "ueblichen Kram" ist das
Zeug gaenzlich inkompatibel. Evt. setzt die Telekom so ein Zeug fuer
dieses Produkt ein.

ich vermute eher auch bei diesem Produkt ordinaeres PPPoEoATMoSHDSL,
wobei die hoehere Bandbreite durch Multilink ppp erreicht wird. DTAG
koennte so die DSLAMs, das ATM Konzentratornetz und die BRAS verwenden,
die auch fuer T-DSL eingesetzt werden. Kann mir nicht vorstellen, dass
DTAG fuer dieses Exotenprodukt andere DSLAM und Backhaul verwendet und
dabei DSL neu erfindet.

Die 4-10 MBit/s Produkte der anderen ueblichen SDSL Verdaechtigen werden
auch durch PPPoE und Multilink ppp realisiert. Ich durfte mal an
Leistungsbeschreibungen dafuer mitwirken :-)

Gruss, Olaf

[Bjoern A. Zeeb]

Post by Olaf Selke
ich vermute eher auch bei diesem Produkt ordinaeres PPPoEoATMoSHDSL,
wobei die hoehere Bandbreite durch Multilink ppp erreicht wird. DTAG

oder PPPoAoSHDSL ohne oE, wenn sie das direkt selber machen.

[Shinji Ikari]

Guten Tag.

Post by Olaf Selke
DTAG
koennte so die DSLAMs, das ATM Konzentratornetz und die BRAS verwenden,
die auch fuer T-DSL eingesetzt werden.

Diese Verbindungen laufen nicht ueber das T-com ATM-netz. Es werden
SFV (Punkt zu Punkt) Verbindungen ueber das normale SDH2000+ Netz der
T-com aufgebaut.

Post by Olaf Selke
Kann mir nicht vorstellen, dass
DTAG fuer dieses Exotenprodukt andere DSLAM und Backhaul verwendet und
dabei DSL neu erfindet.

Es hat nichts mit dem sonst ueblichen S-DSL oder A-DSL zu tun.
Es wird zwar der Begriff SDSL (SHDSL) verwendet, doch es ist die selbe
Uebertragungstechnik, welche aktuell auch fuer Primaermultiplexer, SFV
2MBit/s strukturiert und auch unstrukturiert verwendet wird. In so
fern hast du recht, dass (abgesehen von dem Modem) nichts neu
erfunden, sondern eben bei SFV und PMX bekannte Technik einfach
gebuendelt und verwendet wird.

fup to de.comm.technik.dsl

[Juergen Ilse]

Hallo,

In de.comm.protocols.tcp-ip Olaf Selke <***@blutmagie.de> wrote:
[ ... ]

Post by Olaf Selke
Die 4-10 MBit/s Produkte der anderen ueblichen SDSL Verdaechtigen werden
auch durch PPPoE und Multilink ppp realisiert. Ich durfte mal an
Leistungsbeschreibungen dafuer mitwirken :-)

Jein. Es ist zwar ueblich, das ueber Multilink PPP zu machen, aber es gibt
auch noch ein paar anderen Moeglicheiten ... Mit Cisco CPEs mit mehreren
SHDSL-Interfaces kann man hier Routen mit gleicher Metrik ueber beide In-
terfaces setzen und "ip load-sharing per-packet" auf den Interfaces setzen
(das bewirkt ebenfalls ein loadsharing ueber beide Leitungen, nur sollte
man tunlichst auf allen PVCs auch noch "oam-pvc manage" setzen, damit nicht
der Ausfall einer der Leitungen gleich zu untragbaren Paketverlusten fuehrt).
Eine weitere Moeglichkeit (fuer 4 MBit/s) waere "4-Draht SHDSL", was angeb-
lich mit wahlweise SpeedTouch 610s oder bei Cisco mit SHDSL-Interface Version3
gegen einen Lucent Stinger funktionieren soll ... Nachteil: Ist eine der
beiden Kupferdoppeladern gestoert, geht gar nichts mehr (bei MPPP oder
"ip load-sharing per-packet" waere der Link noch mit halber Datenrate
verfuegbar).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Gross, Michael]

Post by Juergen Ilse

Post by Detlef Bosau

Post by Gross, Michael
Vor Produktivgang haben wir verschiedene Tests durchgeführt. Dabei kam

^^^^^^^^^^^^^^^^^^^
Welche?

Interessante Frage ...

FTP, das hatte ich erst geschrieben, dann rausgelöscht und anscheinend
wieder vergessen einzufügen. Und das ganze eben so:

Beispiel: Rechner A uploaded mit 8,5MBit zu Rechner B. Haben wir dann
einen Download auf Rechner C von Rechner D gestartet, sank der Upload
auf 3,5MBit/s, während der Download mit 8,5MBit/s lief.

Rechner A und C stehen beim ISP, Rechner B und D bei uns.

[Detlef Bosau]

Post by Juergen Ilse
Hallo,

Post by Detlef Bosau
Langsam wird das hier eine Troll-Gruppe.

Evt. hat der Techniker aber zumindest in einem Punkt gar nicht so Unrecht ...

....

Post by Juergen Ilse
Es gibt anscheinend einige wenige (wirklich *sehr* *wenige*) Hersteller
(moeglicherweise auch nur einen, ich habe mir dieses Zeug nie richtig
angesehen), die DSL-Technik bauen, die eben nicht "ATM over DSL" macht,
sondern direkt Ethernet-Frames statt ATM-Zellen ueber DSL uebertraegt.

Das hielte ich auch für wenig sinnvoll. Man muß sich nicht mit ATM
verheiraten. Aber DSL ist nun mal eine Synchrontechnik und Ethernet ist
asynchron.

Ich weiß, ich habe mir da mal auf der Ethernetgruppe Haue geholt, weil
alles meinte, Ethernet sei synchron.

Synchron heißt für mich, und der Begriff wird etwa so schillernd
verwendet wie "Schlumpf" und "Hurz", man muß es daher erläutern,
Gleichlauf auf Sender- und Empfängerseite.

Bei DSL, wie auch bei ATM oder ISDN habe ich einen synchronen Strom von
Bytes / Rahmen. Bei Ethernet habe ich das _nicht_. Da kommt nicht in
regelmäßigen Intervallen ein Byte / ein Rahmen, sondern da kommt
"irgendwann" (tm) mal ein Rahmen. Der geht "irgendwann" los. Und startet
folglich auch mit einer Präambel, anhand derer der Empfänger, sich von
seinem Schock erholend, mal seine Hardware auf das beginnende Paket
einrichten kann, um an irgend einem Sonderzeichen (Bit oder Byte je
nachdem ob Du Ethernet machst oder Ethernet ;-)) dann zu sehen, daß ein
Paket losgeht.

Das sind technisch zwei grundlegend verschiedene Ansätze. Daher sollte
man das schon unterscheiden.

Post by Juergen Ilse
Das Zeug funktioniert dann natuerlich nur, wenn sowohl CPE als auch
DSLAM vom selben Hersteller stammen, mit dem "ueblichen Kram" ist das
Zeug gaenzlich inkompatibel. Evt. setzt die Telekom so ein Zeug fuer
dieses Produkt ein.

Bitte. Soll sie. Die können da gerne ein beliebiges ISL Produkt oder
sowas einsetzen, das ist dem Kunden ja auch völlig egal.

Der Kunde sieht Schicht 3. Was darunter passiert, ist Sache des Providers.

Post by Juergen Ilse

Post by Detlef Bosau
Und wenn der Techniker den Unterschied zwischen SDSL und Ethernet nicht
kennt, möge er seinen Technikerbrief zurückgeben und öffentlich vor dem
Bundestag für die Wiedereinführung der Prügelstrafe plädieren und um
seine öffentliche Auspeitschung betteln.

Nun ja, *SOOO* falsch laege er ja mit seiner Behauptung nicht, wenn
tatsaechlich dieses exotische Zeug da fuer "Ethernet-Bridging oeber DSL"
verwendet wird.

Wenn ich auf die tiefen Schichten gehe, dann gibt es nicht ein bißchen
falsch und ein bißchen richtig. Es gibt auch nicht ein bißchen tot oder
ein bißchen schwanger.

Sondern ich muß genau wissen, wo welches Protokoll gefahren wird, wenn
ich verstehen will, was da passiert. Nur dann kann ich nämlich die Dinge
auch begründen. Und zwar sauber, nicht wie EN.

Und auch nur dann kann ich sowas auch mal sauber entstören. Ich muß doch
erstmal einkreisen, welches Phänomen hier überhaupt vorliegt.

Ich höre was von "Upload", ich höre was von "Download". Und darunter
liege SDSL.

- Ja, da ist also ein Synchronprotokoll drunter. Bittschön mit welcher Rate?

- Da ist möglicherweise irgend ein ATM / Frame Relay / Cell Relay / was
proprietäres drunter, um auf einem Synchronprotokoll einen asynchronen
Rahmenstrom aufzulegen. Bittschön mit welchem Rahmenverlust?

- Bisweilen redet man auch von Dämpfung / Rauschen. Sind das jetzt
Buzzwords um die DSL-Helpdeskgruppen anzureichern oder weiß man auch,
was das ist und misst sowas mal?

Wenn ich eine Weitverkehrsleitung in Betrieb nehme, muß ich doch erstmal
dazu in der Lage sein zu prüfen, ob die überhaupt physikalisch den
Anforderungen entspricht! Und das ist zunächst mal Sache des
installierenden Technikers. Und da muß er wissen, was er da tut und
wofür er seinen ganzen Koffer mit den vielen hübschen Messgeräten einsetzt.

Post by Juergen Ilse

Post by Detlef Bosau

Post by Gross, Michael
Vor Produktivgang haben wir verschiedene Tests durchgeführt. Dabei kam

^^^^^^^^^^^^^^^^^^^
Welche?

Interessante Frage ...

Die _entscheidende_ Frage.

Vor allem hat hier ja auch mal ein Kunde eine Leitung vom
Installationstechniker übernommen, nehme ich an. Aufgrund welcher Tests
denn? Hat man sich da 6 Stunden in die knallige Sonne gesetzt und
getestet, ob man dabei einen Sonnenbrand kriegt? Oder hat man einen
Eimer Wasser verschüttet und getestet, ob der Boden naß wird?

Und grundsätzlich testet man durch die Layer von unten nach oben und
nicht umgekehrt. Daher reagiere ich auf Buzzwords wie upload und dowload
reichlich verschnupft. Sowas mögen gewisse Zeitungen so beschreiben.
Aber so testet man keine Weitverkehrsleitung.

[Marc Haber]

Post by Detlef Bosau
Und grundsätzlich testet man durch die Layer von unten nach oben und
nicht umgekehrt. Daher reagiere ich auf Buzzwords wie upload und dowload
reichlich verschnupft. Sowas mögen gewisse Zeitungen so beschreiben.
Aber so testet man keine Weitverkehrsleitung.

Warum machst Du Dich nicht mit Abnahme- und Testdienstleistungen
selbständig. Das scheint ein Markt zu sein, damit kannst Du sicher
reich werden. Und genug Techniker zum Anschnauzen gibt es täglich
gratis.

Grüße
Marc

[Detlef Bosau]

Post by Marc Haber

Post by Detlef Bosau
Und grundsätzlich testet man durch die Layer von unten nach oben und
nicht umgekehrt. Daher reagiere ich auf Buzzwords wie upload und dowload
reichlich verschnupft. Sowas mögen gewisse Zeitungen so beschreiben.
Aber so testet man keine Weitverkehrsleitung.

Warum machst Du Dich nicht mit Abnahme- und Testdienstleistungen
selbständig. Das scheint ein Markt zu sein, damit kannst Du sicher
reich werden. Und genug Techniker zum Anschnauzen gibt es täglich
gratis.

Nur daß ich Techniker nicht anschnauze.

Und die Techniker, mit denen ich bisher an Weitverkehrsleitungen zu tun
habe, waren durchgängig kompetente und sachliche Leute.

Dort _sind_ auch mal Fehler passiert. Aber das waren Versehen. Sowas
wurde berichtigt und gut. Da muß man niemanden anschnauzen.

Die Frage bei Michael ist, wo das Problem liegt. Es hilft ja nun nichts,
wir müssen das ja nun mal eingrenzen.

[Elcaro Nosille]

Post by Marc Haber
Warum machst Du Dich nicht mit Abnahme- und Testdienstleistungen
selbständig. Das scheint ein Markt zu sein, damit kannst Du sicher
reich werden. Und genug Techniker zum Anschnauzen gibt es täglich
gratis.

Ich hab mal bei einem großen schwedischen TK-Konzern in einem Testplant
gearbeitet für Mobilfunk-Netze. Was dort an Leuten teilweise so rumlief
war zum größten Teil nichtmal halbwegs kompetent (lag aber nicht an den
Leuten, sondern dan den schlechten Schulungen und der schlechten Doku-
mentation - nix konzeptionelles, sondern nur Kochrezepte). Ich hab mir
einfach nur meinen Teil gedacht und mich nicht geärgert weil meine Arbeit
nicht von den Verhältnissen abhang. Aber ich glaub Detlef wäre unter sol-
chen Verhältnissen auf dem Zahnfleich gekrochen.

[Gross, Michael]

Und? Habt ihr nachgefragt, ob das tatsaechlich 10 MBit/s FullDuplex ist,
oder ob ihr vielleicht nur (obwohl das eigentlich Unfug waere) HalfDuplex
erhaltet? Haengt der von der Telekom bereit gestellte Ethernet-Port bei
euch evbt. an einem Hub, und wird dadurch das ganze auf Halfduplex ausge-
bremst? Was uebergibt die Telekom denn da wirklich auf dem Ethernet?
10 Mbit/s? 100 MBit/s? HalfDuplex? Fullduplex? Oder macht das Kistchen
ordentlich Autonegotiation?

Laut Telekom-Techniker steht der Port der CPE auf 100MBit Full Duplex
und nimmt an keiner Autonegotiation teil.

Wenn Ethernetseitig nur 10 MBit/s und Halfduplex gefahren werden,
kann da nicht viel mehr drueber gehen als ihr da drueber bekommen
habt. Wenn ihr das Ding an einen Uralt-Hub dran gehaengt habt,
habt ihr das evt. sogar selbst versaubeutelt ..

Das Modem hängt an einem Cisco 2950 und der Port steht ebenfalls fest
auf 100MBit Full Duplex.

Beim Switch unseres Providers sieht es nicht anders aus.

Wir haben damals aber auch ohne Switche dazwischen getestet (einfach
Rechner an die CPE angeschlossen) und dieselben Ergebnisse erzielt.

Wie auch immer, mittlerweile ist die Sache erldigt:

Nach Erhöhen der TcpWindowSize des Linux sind auch damit 8,5MBit/s
symmetrisch möglich. Der Upload bricht jetzt nicht mehr ein [1]

Was aber die Sache mit der FlowControl angeht, so werde ich nochmal
mit unserem Internet Provider darüber sprechen.

Am entsprechenden Switchport unseres Cisco 2950 ist das jedenfalls
nicht aktiviert.

Danke für Eure Hilfe, auf jeden Fall ist es mir jetzt etwas klarer,
was wir da überhaupt einsetzen.

[1] Wen es interessiert, was da verändert worden ist:

Die vorherigen Werte in /etc/sysctl.conf waren:

net.core.rmem_default = 106496
net.core.wmem_default = 106496
net.core.rmem_max = 106496
net.core.wmem_max = 106496
net.ipv4.tcp_rmem = 4096 87380 174760
net.ipv4.tcp_wmem = 4096 16384 131072
net.ipv4.tcp_mem = 48128 48640 49152

Nun sind sie in folgende Werte geändert worden:

net.core.rmem_max = 524288
net.core.wmem_max = 524288
net.ipv4.tcp_rmem = 4096 87380 699050
net.ipv4.tcp_wmem = 4096 65536 524288

Abschließend als xpost nach de.comm.technik.dsl

[Detlef Bosau]

Post by Gross, Michael
Das Modem hängt an einem Cisco 2950 und der Port steht ebenfalls fest
auf 100MBit Full Duplex.
Beim Switch unseres Providers sieht es nicht anders aus.
Wir haben damals aber auch ohne Switche dazwischen getestet (einfach
Rechner an die CPE angeschlossen) und dieselben Ergebnisse erzielt.
Nach Erhöhen der TcpWindowSize des Linux sind auch damit 8,5MBit/s
symmetrisch möglich. Der Upload bricht jetzt nicht mehr ein [1]

Ich weiß zwar nicht, was das ganze mit TCP Window Size zu tun hat.

Aber das weiß wahrscheinlich Herr Bartels und wer sonst noch über sowas
schreibt.

Ich glaube Dir nicht, daß Du ein Problem hattest.

Vielleicht treibst Du solche Spielchen demnächst woanders.

Wir brauchen keine nicht existenten Probleme und großkotzige Geschichten
über angebliche Lösungen.

Ein Elcaro Nosille reicht.

[Rupert Haselbeck]

Post by Detlef Bosau
Ich weiß zwar nicht, was das ganze mit TCP Window Size zu tun hat.

Das wundert wohl niemanden, der ein paar deiner Artikel gelesen hat

Post by Detlef Bosau
Aber das weiß wahrscheinlich Herr Bartels und wer sonst noch über
sowas schreibt.

Ja, der hat immerhin Ahnung, von was er schreibt

Post by Detlef Bosau
Ich glaube Dir nicht, daß Du ein Problem hattest.

Das wird den OP wohl ebensosehr stören, wie der bekannte Sack Reis, der
in Peking ins Fallen geriet. Was sagte er wohl zu einem Erstklässler,
der dem Lehrer nicht glauben mag, daß zwei plus zwei eine vier ergibt?

Post by Detlef Bosau
Vielleicht treibst Du solche Spielchen demnächst woanders.

Glücklicherweise bist du sicherlich der Letzte, der zu entscheiden hat,
wer wann was zu schreiben hat.

Post by Detlef Bosau
Wir brauchen keine nicht existenten Probleme und großkotzige
Geschichten über angebliche Lösungen.

Wer ist wir? Übst du dich jetzt schon im pluralis majestatis?
Du bist echt eine Bereicherung des Usenets. Man hätte ja sonst
garnichts, worüber man lächeln könnte

MfG
Rupert

[Detlef Bosau]

Post by Rupert Haselbeck

Post by Detlef Bosau
Ich weiß zwar nicht, was das ganze mit TCP Window Size zu tun hat.

Das wundert wohl niemanden, der ein paar deiner Artikel gelesen hat

Lies meinen Parallelartikel und hör auf, hier rumuzuschwallen.

Post by Rupert Haselbeck

Post by Detlef Bosau
Aber das weiß wahrscheinlich Herr Bartels und wer sonst noch über
sowas schreibt.

Ja, der hat immerhin Ahnung, von was er schreibt

Bartels hat keinen Schimmer. Und Donnerhacke hat sich eben als
inkompetent geoutet.

Lies das Parallelposting, da habe ich es vorgerechnet.

Wenn Du es nicht schaffst, das nachzurechnen: Rechnen Niveau
Hauptschulabschluß bringe ich den Leuten nicht bei. Förderkurse für
Rechenschwäche gibt es woanders.

[Rupert Haselbeck]

Post by Detlef Bosau
Bartels hat keinen Schimmer. Und Donnerhacke hat sich eben als
inkompetent geoutet.
Lies das Parallelposting, da habe ich es vorgerechnet.

Ja, da musste ich gerade herzlich lachen, als ich das lesen durfte.
Ein angeblich diplomierter Informatiker, der noch nichtmal davon Ahnung
hat, welche Signalausbreitungsgeschwindigkeit man auf welcher Art von
Übertragungsstrecke erreichen kann, der hat es in der Tat nötig, andere
belehren zu wollen! Welche Uni willst du eigentlich besucht haben?
Sollte man das dortige Prüfungsamt eventuell mal davon informieren, wer
sich hier mit ihm nicht zustehenden Titeln zu schmücken scheint?
Merkst du eigentlich wirklich nicht, wie sehr du dich mit jedem weiteren
deiner mehr als abstrusen Artikel selber demontierst? Jeder
Erstesemesterstudent muß auf Anhieb erkennen, welche "Größe" er da vor
sich hat :-(
Warum hältst du dich denn nicht an den Rat, den du schon vor einigen
Wochen mal erhalten hast? Was hast du davon, wenn du dich jeden Tag ein
dutzendmal aufs Neue blamierst?

MfG
Rupert

[Elcaro Nosille]

Post by Detlef Bosau

Post by Gross, Michael
Nach Erhöhen der TcpWindowSize des Linux sind auch damit 8,5MBit/s
symmetrisch möglich. Der Upload bricht jetzt nicht mehr ein [1]

Ich weiß zwar nicht, was das ganze mit TCP Window Size zu tun hat.

Das ist ja echt ein Witz.
Und Du führst immer dein Wissen um das Sliding-Window-Verfahren bei
TCP an.

[Detlef Bosau]

Post by Elcaro Nosille

Post by Detlef Bosau

Post by Gross, Michael
Nach Erhöhen der TcpWindowSize des Linux sind auch damit 8,5MBit/s
symmetrisch möglich. Der Upload bricht jetzt nicht mehr ein [1]

Ich weiß zwar nicht, was das ganze mit TCP Window Size zu tun hat.

Das ist ja echt ein Witz.
Und Du führst immer dein Wissen um das Sliding-Window-Verfahren bei
TCP an.

Ich habe den Sachverhalt vorgerechnet.

_Das_ ist Wissen über TCP.

Du magst es _sachlich_ korrigieren, wenn Du dazu in der Lage bist.

[Elcaro Nosille]

Post by Detlef Bosau

Post by Elcaro Nosille
Das ist ja echt ein Witz.
Und Du führst immer dein Wissen um das Sliding-Window-Verfahren
bei TCP an.

Ich habe den Sachverhalt vorgerechnet.
_Das_ ist Wissen über TCP.

1: Deine Berechnungen die Du anderswo gemacht hast basieren auf einer
freien Leitung, d.h. die ACKs kommen schnell genug durch. Wenn ich aber
noch weiteren Traffic habe so daß sich vor der Leitung zum Kunden die
ACKs nach anderem Traffic einordnen, dann kann eine Window-Size nicht
mehr ausreichend sein obwohl sie für eine freie Leitung passt. Das
gleiche gilt natürlich auch für die Gegenrichtung.
2. Die Window-Size lässt sich oft nicht beliebig erhöhen. Um nicht so
einfach geDOSt zu werden haben viele OSe eine Beschränkung für die Win-
dow-Size _des_Gegenübers_. Denn je größer das Emfpangsfenster des Gegen-
übers, desto mehr Retransmit-Buffer muss der Kernel allokieren um ggf
Pakete erneut zu senden. AFAIK liegt die Standard-Einstellung für das
maximale Emfpangsfenster des Gegenübers beim Linux-Kernel bei 128kB.

[Detlef Bosau]

Post by Elcaro Nosille
1: Deine Berechnungen die Du anderswo gemacht hast basieren auf einer
freien Leitung, d.h. die ACKs kommen schnell genug durch. Wenn ich aber

Wir reden nicht über ACKs.

Die Frage ist, wie groß ein Fenster sein muß, um die Leitung voll
auszulasten.

Post by Elcaro Nosille
noch weiteren Traffic habe so daß sich vor der Leitung zum Kunden die
ACKs nach anderem Traffic einordnen, dann kann eine Window-Size nicht
mehr ausreichend sein obwohl sie für eine freie Leitung passt. Das
gleiche gilt natürlich auch für die Gegenrichtung.

Du hast nicht verstanden, wie Sliding Window funktioniert.

Wenn mehrere Ströme vorliegen, _teilen_ sich diese die Kapazität.

Dann braucht der einzelne Strom sogar ein _kleineres_ Fenster als bei
einer freien Leitung. Die freie Leitung ist der worst case.

Post by Elcaro Nosille
2. Die Window-Size lässt sich oft nicht beliebig erhöhen. Um nicht so

Wozu auch?

Ich rechnete vor, daß die maximale Windowsize für Stuttgart-Helsinki reicht.

Wenn mir jetzt jemand sagt, die in Frage stehende Leitung sei
Stuttgart-New York, haben wir aein Problem. Ich mutmaße aber mal, daß es
sich um eine innerdeutsche Leitung handelt. Und da möchte ich sehen, wo
ich 1600 Kilometer erreiche.

Post by Elcaro Nosille
einfach geDOSt zu werden haben viele OSe eine Beschränkung für die Win-

Wovon redest Du?

Post by Elcaro Nosille
dow-Size _des_Gegenübers_. Denn je größer das Emfpangsfenster des Gegen-
übers, desto mehr Retransmit-Buffer muss der Kernel allokieren um ggf
Pakete erneut zu senden. AFAIK liegt die Standard-Einstellung für das
maximale Emfpangsfenster des Gegenübers beim Linux-Kernel bei 128kB.

Ach hör doch auf, hier andauernd Schmarrn zu erzählen.

Ohne Windowscaling werden Fenster in Oktett angegeben, dazu gibt es im
TCP Header 16 bit, also haben wir ohne Windowscaling ein maximales
Fenster von 65525 Oktett.

Das sind die Fakten.

Was Du AFAIKst, ist irrelevant.

Rede über die Fakten und zeige mir die Fehler auf, dann können wir
darüber reden.

Das gilt auch für Bartels, Donnerhacke und Haselbeck.

TCP funktioniert nach Standards.

Nicht nach der Lautstärke der Schreihälse.

[Detlef Bosau]

Im übrigen ist in meiner Argumentation sogar eine Sollbruchstelle drin:
Ich sprach von einer knapp 1600 Meter langen Leitung für das geforderte LBP.

Das ist völlig richtig.

Frage: Was heißt dsa für die maximale Entferngung von Sender und
Empfänger? Ist die bei 64 kByte Windwogröße auch 1600 Kilometer?

Wenn ja: Warum?

Wenn nein: Warum nicht?

Die Antwort ist einfach, die Begründung sehr kurz und knackig. Die paßt hier

==========================8<======================================




==========================8<======================================

rein.

Wobei ich _reichlich_ Platz gelassen habe. Da würde es sogar Edmund
Stoiber hinkriegen, selbst wenn der plötzlich anfinge zu stottern.

Wenn jemand die richtige Antwort weiß, könnte er sogar demonstrieren,
_daß_ er sliding window verstanden hat.

Ich bat um _sachliche_ Kritik. Elcaro Nosille kann da bitte gleich die
Klappe halten, das muß ich mir jetzt nicht antun.

[frank paulsen]

Post by Detlef Bosau
Ich sprach von einer knapp 1600 Meter langen Leitung für das geforderte LBP.
Das ist völlig richtig.
Frage: Was heißt dsa für die maximale Entferngung von Sender und
Empfänger? Ist die bei 64 kByte Windwogröße auch 1600 Kilometer?
Wenn ja: Warum?
Wenn nein: Warum nicht?
Die Antwort ist einfach, die Begründung sehr kurz und knackig. Die paßt hier
==========================8<======================================

Detlef Bosau hat am Donnerstag, den 10. August 2006 öffentlich erklärt,
daß STD 7 obsolete ist. Mangels Nachfolger findet TCP nicht mehr statt.

Post by Detlef Bosau
==========================8<======================================
rein.

stimmt, passt problemlos.

[Detlef Bosau]

frank paulsen wrote:

nichts.

Wer mir vorwirft, ich hätte keine Ahnung, soll doch endlich mit Fakten
kommen.

Und _NATÜRLICH_ ist RFC 793 obsolet zum Verständnis von TCP nicht
ausreichend, verdammt noch mal1

Das Ding kennt ja noch nicht mal TCP Congestion Control!

Ich habe den RFC von Windowscaling erwähnt. Das ist RFC 1323. Davon ist
in RFC 793 nicht die Rede.

Ich habe auf Congestion Control hingewiesen. RFC 2581. Aus dem Jahr
1999. Davon ist in RFC 793, aus dem Jahre 1981 nicht die Rede.

Es mag ja sein, daß Du mich nicht magst.

Aber es ist einfach unlauter, hier mit 25 Jahre alten Standards
anzukommen, und überhaupt nicht zur Kenntnis zu nehmen, daß diese in den
letzten 25 Jahren mehrere Male ergänzt worden sind!

Und es geht hier um die Standards für TCP, nicht um die Frage, welche
Betriebssysteme sich nicht daran halten!

Werden hier jetzt nochmal Sachargumente ausgetauscht, oder was ist das hier?

[Elcaro Nosille]

Post by Detlef Bosau

Post by Elcaro Nosille
1: Deine Berechnungen die Du anderswo gemacht hast basieren auf einer
freien Leitung, d.h. die ACKs kommen schnell genug durch. Wenn ich aber

Wir reden nicht über ACKs.

Ne, die gehören ja nicht zum Sliding-Window-Konzept dazu - überhauptnicht.

Post by Detlef Bosau
Die Frage ist, wie groß ein Fenster sein muß, um die Leitung voll
auszulasten.

Im ursprünglich geschilderten Senzario des OP war die Leitung aber
noch mit anderem Traffic belastet.

Post by Detlef Bosau

Post by Elcaro Nosille
noch weiteren Traffic habe so daß sich vor der Leitung zum Kunden die
ACKs nach anderem Traffic einordnen, dann kann eine Window-Size nicht
mehr ausreichend sein obwohl sie für eine freie Leitung passt. Das
gleiche gilt natürlich auch für die Gegenrichtung.

Du hast nicht verstanden, wie Sliding Window funktioniert.

Musst Du gerade sagen.

Post by Detlef Bosau
Wenn mehrere Ströme vorliegen, _teilen_ sich diese die Kapazität.

Ja, aber nicht sauber. D.h. wenn ich einen Download habe dann schießt die
sendende Maschine mir beim Router des Providers die Sendequeue voll so daß
ACKs für einen Upload sich danach einreihen - zumindest bei nicht balancier-
tem Queuing. Das kann ACKs so weit verzögern, daß nicht weiter gesendet wer-
den kann weil der Retransmit-Buffer voll ist.
Aber ich befürchte mal wieder, daß Du das nicht verstehst. Nicht, daß Du es
nicht könntest. Du nimmst einfach von Anfang an, daß dein Gegenüber dümmer
als Du ist und denkst garnicht über die Sache nach.

Post by Detlef Bosau
Dann braucht der einzelne Strom sogar ein _kleineres_ Fenster als
bei einer freien Leitung.

Au weia! Bei sowas frag ich mich ob es Sinn macht sich mit dir noch
weiter darüber zu unterhalten.

Post by Detlef Bosau

Post by Elcaro Nosille
2. Die Window-Size lässt sich oft nicht beliebig erhöhen.

Wozu auch?

In dem genannten Szenario ist das unter Umständen (zu kleines Fenster)
nötig während das Fenster bei einer Freien Gegenrichtung ausreicht.

Post by Detlef Bosau

Post by Elcaro Nosille
einfach geDOSt zu werden haben viele OSe eine Beschränkung für die Win-

Wovon redest Du?

Informier dich mal warum heutige OSe in der Default-Konfiguration nicht
jegliches TCP-Window der Gegenseite akzeptieren. Dann können wir weiter-
reden.

Post by Detlef Bosau

Post by Elcaro Nosille
dow-Size _des_Gegenübers_. Denn je größer das Emfpangsfenster des Gegen-
übers, desto mehr Retransmit-Buffer muss der Kernel allokieren um ggf
Pakete erneut zu senden. AFAIK liegt die Standard-Einstellung für das
maximale Emfpangsfenster des Gegenübers beim Linux-Kernel bei 128kB.

Ach hör doch auf, hier andauernd Schmarrn zu erzählen.

Ok, Du verstehst das also nicht.

Post by Detlef Bosau
Ohne Windowscaling werden Fenster in Oktett angegeben, dazu gibt es
im TCP Header 16 bit, also haben wir ohne Windowscaling ein maximales
Fenster von 65525 Oktett.
Das sind die Fakten.

Noch ein Beleg, daß Du es nicht verstehst.
Denn das relativier meine Äußerung überhauptnicht.

Post by Detlef Bosau
Rede über die Fakten und zeige mir die Fehler auf, dann können wir
darüber reden.
Das gilt auch für Bartels, Donnerhacke und Haselbeck.
TCP funktioniert nach Standards.
Nicht nach der Lautstärke der Schreihälse.

Das kannst Du dir in diesem Fall selbst vorhalten.

[Detlef Bosau]

Post by Elcaro Nosille

Post by Detlef Bosau
Dann braucht der einzelne Strom sogar ein _kleineres_ Fenster als
bei einer freien Leitung.

Au weia! Bei sowas frag ich mich ob es Sinn macht sich mit dir noch
weiter darüber zu unterhalten.

Das frage ich mich freilich auch.

Kannst Du _begründen_, warum meine Meinung unrichtig sei?

Also ich kann Dir gerne Primärliteratur gegen:

http://nms.csail.mit.edu/6829-papers/congavoid.pdf

Also: Wo ist meine Aussage falsch? Ich will eine sachliche Begründung!

Bartels und Donnerhacke dürfen Dir gerne helfen.

Post by Elcaro Nosille

Post by Detlef Bosau

Post by Elcaro Nosille
2. Die Window-Size lässt sich oft nicht beliebig erhöhen.

Wozu auch?

In dem genannten Szenario ist das unter Umständen (zu kleines Fenster)
nötig während das Fenster bei einer Freien Gegenrichtung ausreicht.

Was ist die Window Size? Kannst Du das bitte einmal unter Verwendung der
üblichen Begriffe erläutern?

Post by Elcaro Nosille

Post by Detlef Bosau

Post by Elcaro Nosille
einfach geDOSt zu werden haben viele OSe eine Beschränkung für die Win-

Wovon redest Du?

Informier dich mal warum heutige OSe in der Default-Konfiguration nicht
jegliches TCP-Window der Gegenseite akzeptieren. Dann können wir weiter-
reden.

Ich will von Dir wissen, wie Sliding Window funktioniert.

Post by Elcaro Nosille

Post by Detlef Bosau
Ohne Windowscaling werden Fenster in Oktett angegeben, dazu gibt es
im TCP Header 16 bit, also haben wir ohne Windowscaling ein maximales
Fenster von 65525 Oktett.
Das sind die Fakten.

Noch ein Beleg, daß Du es nicht verstehst.
Denn das relativier meine Äußerung überhauptnicht.

Hör auf, mich hier andauernd zu beleidigen.

Im übrigen:

http://www.ietf.org/rfc/rfc1323.txt

Der ist hier im Zusammehang sogar schon mal genannt worden.

Dort heißt es u.a. wörtlich:

(1) Window Size Limit

The TCP header uses a 16 bit field to report the receive
window size to the sender. Therefore, the largest window
that can be used is 2**16 = 65K bytes.

To circumvent this problem, Section 2 of this memo defines a
new TCP option, "Window Scale", to allow windows larger than
2**16. This option defines an implicit scale factor, which
is used to multiply the window size value found in a TCP
header to obtain the true window size.


Und zum Scale Factor:

2.2 Window Scale Option

The three-byte Window Scale option may be sent in a SYN segment by
a TCP. It has two purposes: (1) indicate that the TCP is prepared
to do both send and receive window scaling, and (2) communicate a
scale factor to be applied to its receive window. Thus, a TCP
that is prepared to scale windows should send the option, even if
its own scale factor is 1. The scale factor is limited to a power
of two and encoded logarithmically, so it may be implemented by
binary shift operations.


TCP Window Scale Option (WSopt):

Kind: 3 Length: 3 bytes

+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+


This option is an offer, not a promise; both sides must send
Window Scale options in their SYN segments to enable window
scaling in either direction. If window scaling is enabled,
then the TCP that sent this option will right-shift its true
receive-window values by 'shift.cnt' bits for transmission in
SEG.WND. The value 'shift.cnt' may be zero (offering to scale,
while applying a scale factor of 1 to the receive window).

This option may be sent in an initial <SYN> segment (i.e., a
segment with the SYN bit on and the ACK bit off). It may also
be sent in a <SYN,ACK> segment, but only if a Window Scale op-
tion was received in the initial <SYN> segment. A Window Scale
option in a segment without a SYN bit should be ignored.

The Window field in a SYN (i.e., a <SYN> or <SYN,ACK>) segment
itself is never scaled.

Und das ist genau das, was ich gesagt habe.

Wenn ich einen shift.cnt von 1 habe, wird die Windowsize vor dem Senden
halbiert, ich zähle also in _2_ Byte Schritten.

Steht dort z.B. eine 3, habe ich 3 shifts, zähle also in _8_ Byte
Schritten.

Ich kann es nicht ausstehen, wenn hier Leute mich andauernd beleidigen
und für einen Volltrottel halten, und wenn ich den Leuten dann die RFCs
unter die Nase halte, dann kommt nichts!

Post by Elcaro Nosille

Post by Detlef Bosau
Rede über die Fakten und zeige mir die Fehler auf, dann können wir
darüber reden.
Das gilt auch für Bartels, Donnerhacke und Haselbeck.
TCP funktioniert nach Standards.
Nicht nach der Lautstärke der Schreihälse.

Das kannst Du dir in diesem Fall selbst vorhalten.

Doch, ganz genau das kann ich!

Und zwar Dir!

[Ralph A. Schmid, DK5RAS]

Post by Detlef Bosau
Ich weiß zwar nicht, was das ganze mit TCP Window Size zu tun hat.

Es gibt Vieles, was Du nicht weißt. Das ist nicht weiter schlimm,
solange man nicht permament vorgibt, alles zu wissen...

Und husch, wieder in den mentalen Filter mit Dir.

[Elcaro Nosille]

Post by Ralph A. Schmid, DK5RAS

Post by Detlef Bosau
Ich weiß zwar nicht, was das ganze mit TCP Window Size zu tun hat.

Es gibt Vieles, was Du nicht weißt. Das ist nicht weiter schlimm,
solange man nicht permament vorgibt, alles zu wissen...

Vor allem meint er mit dem Lesen von RFCs alles verstanden zu haben. Da
frag ich mich wieso man im TCP/IP-Illustrated eine Menge Implementations
-Implikationen von TCP/IP findet die sich in keiner RFC finden.

[Detlef Bosau]

Post by Elcaro Nosille

Post by Ralph A. Schmid, DK5RAS

Post by Detlef Bosau
Ich weiß zwar nicht, was das ganze mit TCP Window Size zu tun hat.

Es gibt Vieles, was Du nicht weißt. Das ist nicht weiter schlimm,
solange man nicht permament vorgibt, alles zu wissen...

Vor allem meint er mit dem Lesen von RFCs alles verstanden zu haben. Da
frag ich mich wieso man im TCP/IP-Illustrated eine Menge Implementations
-Implikationen von TCP/IP findet die sich in keiner RFC finden.

Ich dachte, ich hätte darauf geantwortet.

Erstens mag ich es nicht sonderlich, wenn über mich in der dritten
Person geredet wird. Bitte rede mit mir, nicht über mich.

Zweitens geht es nicht darum, ich ich meine, alles verstanden zu haben.

Im Gegensatz zu Dir _nenne_ ich meine Quellen. Im Gegensatz zu Dir nenne
ich auch die _Primärquellen_. Den Unterschied zwischen einer Primär- und
einer Sekundärquelle kennst Du.

Auch wurdest Du mehrfach, ich erinnere ungern an das Ding Philosophers
Problem, aufgefordert, Aussagen zu _begründen_.

Du wirfst mir andauernd irgendwelche Dinge vor. Aber statt mal konzis
auf den Punkt zu kommen, worum es eigentlich geht, kommt nur Geraune und
Geschwalle, und genau _das_ ist es, was mich stört.

Komme auf den Punkt, dann kann man darüber reden.

Aber mit Allgemeinplätzen kommen wir nicht weiter.

Und selbstverständlich werden wir da über RFCs reden. Denn die RFCs sind
nun mal die verbindlichen Dokumente, in denen die IETF ihre Standards
festlegt. Punkt, Ende. Da beißt die Maus keinen Faden ab.

Was da in Lehrbüchern steht, kann und darf und soll sogar gerne
angeführt werden.

Aber wenn Du mit Deinem Auto zum TÜV fährst, ist nun mal nicht das
Lehrbuch für die Prüfungen relevant sondern die einschlägige DIN oder
welche Norm da auch immer Rechtskraft hat.

TCP Stacks implementiert man daher auch nicht nach Schönwetterlage und
Herzensgüte, sondern man implementiert sie nach Standards.

Daher habe ich auch unlängst, wsa Du natürlich wieder nicht verstanden
hast, darauf wert gelegt, möglichst vorhandene Stacks zu übernehmen.
Weil es nämlich keinen sonderlichen Wert hat, das Rad alle drei Wochen
noch einmal zu erfinden und immer wieder dieselben Fehler zu machen und
zu beheben.

Und die Diskussion, die wir hier gerade führen, zeigt mir nur
allzudeutlich, daß es immer wieder dieselben Denkfehler _sind_, die da
gemacht werden, und auch immer wieder von "Experten", die zwar das große
Wort führen, aber die Standards nicht kennen.

Noch einmal: Wenn etwas von dem, was ich schreibe, falsch ist, bitte ich
sogar um Korrektur. Aber dann bitte _begründet_ und nicht einfach
hingesülzt. Da darf mal eine Formel drinstehen, da darf mal eine
konkrete These auftauchen, da darf mal eine Quelle benannt sein.

Das einzige Mal, wo Du eine Quelle genannt hast, was zum Dining
Philosophers Problem ein Link auf eine Vorlesung. Und hättest Du mal
genau hingeschaut, hättest Du gemerkt, ich meine ich habe es Dir damals
auch erläutert, daß dieser Vorlesungsabschnitt Deine Argumentation
überhaupt nicht gestützt hat sondern Du im Gegenteil den Text überhaupt
nicht verstanden hast.

Und auf der Basis sind Diskussionen nicht sonderlich sinnvoll

Detlef

[Marc Haber]

Post by Detlef Bosau
TCP Stacks implementiert man daher auch nicht nach Schönwetterlage und
Herzensgüte, sondern man implementiert sie nach Standards.

In der Praxis nimmt man den BSD-Stack mit allen Bugs und baut die dann
langsam über die Lebensdauer des Produkts hinweg aus.

Grüße
Marc

[Detlef Bosau]

Post by Marc Haber

Post by Detlef Bosau
TCP Stacks implementiert man daher auch nicht nach Schönwetterlage und
Herzensgüte, sondern man implementiert sie nach Standards.

In der Praxis nimmt man den BSD-Stack mit allen Bugs und baut die dann
langsam über die Lebensdauer des Produkts hinweg aus.

Es wäre dennoch besser, das an _einem_ Stack zu machen.

Die Diskussion hier hat gezeigt, daß die aktuellen Standards überhaupt
nicht bekannt ist. Ich habe es nicht im Kopf, aber um TCP zu überblicken
muß man sicher so um die 20 (weiß es wer genauer?) RFCs beachten - und
die aktuelle Diskussion dazu.

Es ist da einfach herzlich hinderlich, daß da jeder seinen eigenen Stuss
veranstaltet.

TCP ist da einfach zu komplex für privates Experimentieren.

[Marc Haber]

Post by Detlef Bosau
TCP ist da einfach zu komplex für privates Experimentieren.

UDP übrigens auch. Die wenigsten Billig-DSL-"Router" können mit UDP
außerhalb von DNS vernünftig umgehen. Das zeigt sich dann besonders
gerne in Wackeleien von Streamingapplikationen oder IPSEC.

Grüße
Marc

[Holger Marzen]

["Followup-To:" header set to de.comm.protocols.tcp-ip.]

Post by Marc Haber

Post by Detlef Bosau
TCP ist da einfach zu komplex für privates Experimentieren.

UDP übrigens auch. Die wenigsten Billig-DSL-"Router" können mit UDP
außerhalb von DNS vernünftig umgehen. Das zeigt sich dann besonders
gerne in Wackeleien von Streamingapplikationen oder IPSEC.

Neulich erlebt und nur durch Kleindrehen der MTU bei OpenVPN lösen
können. Wenn ich das richtig messen konnte, hat der Consumer-Router, den
die T-Com ausliefert, die Folgefragmente fragmentierter UDP-Pakete
einfach verschluckt.

[Detlef Bosau]

TCP hat standardmäßig (ohne Windowscaling) ein maximales Sendefenster
von 65536 Byte. So steht es in den Standards, wenn M$ da was kaputties
implementiert, interessiert das keinen Menschen.

Wenn ich 100 MBit/s Bandbreite habe und

Latenz * Bandbreite = Fenstergröße sein soll, habe ich also:
Latenz * 100 MBit/s = 65536 byite = 524288 bit und damit
Latenz = 5,24288... * 10^-3 Sekunden.

So.

Wenn ich als Ausbreitungsgeschwindigkeit c= 300.000 km/s setze, ist
c*Latenz = 1572,864 Kilometer.

Ich kriege also ab dieser Länge ein Problem, das ich Windowscaling
einführen muß.

So. Ich habe mal eben einen Routenplaner angeschmissen.

Die Entfernung von Stuttgart bis nach Helsinkli sind (siehe
http://www.hirnbrauser.de/map-distances.html) 1616 Kilometer.

Das kommt also etwa hin.

Wenn jemand also eine Glasfaserstrippe von Stuttgart bis nach Helsinki
zieht, und _einen_ isolierten TCP Strom darauf betrachtet, dann kann der
allmählich über die Windowsizes rumquaken.

Für alle anderen Szenarien ist dieses Deppengeschwätz irrelevant.

Wenn freilich jemand TCP Fenster in nicht RFC konformer Weise
abquetscht, kann ich nichts dafür und ich kann auch nichts dagegen.
Aber sowas sind keine "Probleme", sowas sind _Fehler_. Und für diese
sind die verantwortlich, die sie machen.

In eine Entstörung eines Netzproblems gehört sowas freilich nicht rein.
Wenn man irgendwo zu doof ist, Sockets und Betriebssysteme richtig zu
programmieren, ist das weder ein Problem von TCP/IP noch ist das ein
Problem von DSL, sondern es ist wahlweise ein Problem für eine
Schadensersatzklage oder den Rausschmiß eines Mitarbeiters.

Ich habe jedenfalls langsam keinen Bock mehr darauf, mir angebliche
Probleme mit TCP Windowsizes anzuhören, nur weil jemand die Entfernung
von der Hofeinfahrt bis zur Garage für eine "Deep Space Distance" hält.

[Clemens W]

Post by Detlef Bosau
Wenn ich als Ausbreitungsgeschwindigkeit c= 300.000 km/s setze, ist
c*Latenz = 1572,864 Kilometer.

Stimmt so leider nicht. Die Lichtgeschwindigkeit in Glas(fasern) liegt
bei rund 2/3 der Vakuumlichtgeschwindigkeit, also rund 2,0 x 10^8 m/s.
{1]

Damit schrumpft die Entfernung schon mal auf rund 1050 km.

Post by Detlef Bosau
So. Ich habe mal eben einen Routenplaner angeschmissen.
Die Entfernung von Stuttgart bis nach Helsinkli sind (siehe
http://www.hirnbrauser.de/map-distances.html) 1616 Kilometer.

Das ist kein Routenplaner, das ist ein Entfernungsmesser. Und Kabel
verlaufen selten genau in Luftlinie.

Post by Detlef Bosau
Das kommt also etwa hin.

Kommt es nicht. Garmisch - Flensburg sind z.B. 1020 Autobahnkilometer.
Das kommt also etwa hin.

Man liest sich,

Clemens

{1] Der genaue Wert ist abhängig von verschiedenen Faktoren wie z.B.
optische Dichte des Glases.

[Detlef Bosau]

Post by Clemens W

Post by Detlef Bosau
Wenn ich als Ausbreitungsgeschwindigkeit c= 300.000 km/s setze, ist
c*Latenz = 1572,864 Kilometer.

Stimmt so leider nicht. Die Lichtgeschwindigkeit in Glas(fasern) liegt
bei rund 2/3 der Vakuumlichtgeschwindigkeit, also rund 2,0 x 10^8 m/s.
{1]
Damit schrumpft die Entfernung schon mal auf rund 1050 km.

Das ändert nun aber nichts am Rechengang. Und 1050 Kilometer sind nun
auch nicht gerade von hier bis zur nächsten Bushaltestelle.

Post by Clemens W

Post by Detlef Bosau
So. Ich habe mal eben einen Routenplaner angeschmissen.
Die Entfernung von Stuttgart bis nach Helsinkli sind (siehe
http://www.hirnbrauser.de/map-distances.html) 1616 Kilometer.

Das ist kein Routenplaner, das ist ein Entfernungsmesser. Und Kabel
verlaufen selten genau in Luftlinie.

Ob Routenplaner oder Entfernungsmesser, ich wollte die Entfernung von
der Größenordnung her veranschaulichen.

Worauf willst Du denn jetzt raus? Willst Du jetzt die
Ausbreitungsgeschwindigkeit etwas drücken und das hannoverinterne Kabel
den Nanas noch ein paar mal um den Bauch wickeln? Dann kriegst Du
vielleicht noch ein paar Kilometerchen her. Sei geschenkt. Damit landen
wir nicht bei den vielleicht 20 Kilometern, die ich für innerstädtische
Verbindungen habe, vielleicht 30 Kilometer. Da hätte ich dann immer noch
eine Latenz in der Größenordnung von (30 Kilometer) / (200.000 km/s) =
1.5 * 10^-4 Sekunden. Also bei 150 Mikrosekunden. Im
Latenzbandbreiteprodukt bei 100 MBit/s haben wir da 1875 Byte. Also
nicht mal 2 kByte.

Das macht uns also keine Sorgen, dafür muß man weder TCP noch Sliding
Window neu erfinden.

Post by Clemens W

Post by Detlef Bosau
Das kommt also etwa hin.

Kommt es nicht. Garmisch - Flensburg sind z.B. 1020 Autobahnkilometer.
Das kommt also etwa hin.

Die Anmerkung war gut, aber in bezug auf unser Problem sagt es doch
nichts aus.

Man wollte auf irgendwas mit zu kleinen TCP Windows als Ursache für
mangelnden Durchsatz hinaus. Und ob die Speicherkapazität des Pfades da
nun 2 kByte sind oder 0.2 oder 20 kByte, das spielt für unsere
Diskussion doch überhaupt keine Rolle.

Post by Clemens W
Man liest sich,
Clemens
{1] Der genaue Wert ist abhängig von verschiedenen Faktoren wie z.B.
optische Dichte des Glases.

[Detlef Bosau]

TCP hat standardmäßig (ohne Windowscaling) ein maximales Sendefenster
von 65536 Byte. So steht es in den Standards, wenn M$ da was kaputties
implementiert, interessiert das keinen Menschen.

Wenn ich 100 MBit/s Bandbreite habe und

Latenz * Bandbreite = Fenstergröße sein soll, habe ich also:
Latenz * 100 MBit/s = 65536 byite = 524288 bit und damit
Latenz = 5,24288... * 10^-3 Sekunden.

So.

Wenn ich als Ausbreitungsgeschwindigkeit c= 300.000 km/s setze, ist
c*Latenz = 1572,864 Kilometer.

Ich kriege also ab dieser Länge ein Problem, das ich Windowscaling
einführen muß.

So. Ich habe mal eben einen Routenplaner angeschmissen.

Die Entfernung von Stuttgart bis nach Helsinkli sind (siehe
http://www.hirnbrauser.de/map-distances.html) 1616 Kilometer.

Das kommt also etwa hin.

Wenn jemand also eine Glasfaserstrippe von Stuttgart bis nach Helsinki
zieht, und _einen_ isolierten TCP Strom darauf betrachtet, dann kann der
allmählich über die Windowsizes rumquaken.

Für alle anderen Szenarien ist dieses Deppengeschwätz irrelevant.

Wenn freilich jemand TCP Fenster in nicht RFC konformer Weise
abquetscht, kann ich nichts dafür und ich kann auch nichts dagegen.
Aber sowas sind keine "Probleme", sowas sind _Fehler_. Und für diese
sind die verantwortlich, die sie machen.

In eine Entstörung eines Netzproblems gehört sowas freilich nicht rein.
Wenn man irgendwo zu doof ist, Sockets und Betriebssysteme richtig zu
programmieren, ist das weder ein Problem von TCP/IP noch ist das ein
Problem von DSL, sondern es ist wahlweise ein Problem für eine
Schadensersatzklage oder den Rausschmiß eines Mitarbeiters.

Ich habe jedenfalls langsam keinen Bock mehr darauf, mir angebliche
Probleme mit TCP Windowsizes anzuhören, nur weil jemand die Entfernung
von der Hofeinfahrt bis zur Garage für eine "Deep Space Distance" hält.

[Shinji Ikari]

Guten Tag.

Post by Juergen Ilse
Es gibt anscheinend einige wenige (wirklich *sehr* *wenige*) Hersteller
(moeglicherweise auch nur einen, ich habe mir dieses Zeug nie richtig
angesehen), die DSL-Technik bauen, die eben nicht "ATM over DSL" macht,
sondern direkt Ethernet-Frames statt ATM-Zellen ueber DSL uebertraegt.
Das Zeug funktioniert dann natuerlich nur, wenn sowohl CPE als auch
DSLAM vom selben Hersteller stammen,

Achtung! Die erwaehnte SDSL-technik ist SHDSL und hat mit den
ueblichen DSLam fuer die oft bekannten A-DSL und S-DSL
ISP-verbindungen nichts zu tun. Es wird gezielt eine Bosch/Marconi
Baugruppe mit 8 Ports verwendet, welche mit 4 Ports eine feste
Geschwindigkeit von je ca. 2MBit/s (oder auch als 2,3MBit/s benannt)
erreicht. Wenn es die passenden Modems gaebe, koennte man es auch
ueber die aeltere HDSL- oder gar die HDB3-Technik realisieren. Da es
aber alte Techniken sind, wird eben die neueste SDSL (SHDSL)Technik
verwendet.

Post by Juergen Ilse
mit dem "ueblichen Kram" ist das
Zeug gaenzlich inkompatibel. Evt. setzt die Telekom so ein Zeug fuer
dieses Produkt ein.

Es ist speziell nur hierzu kompatibeles Equipment beim Kunden: ja.

fup to de.comm.technik.dsl

[Detlef Bosau]

Post by Shinji Ikari
Achtung! Die erwaehnte SDSL-technik ist SHDSL und hat mit den
ueblichen DSLam fuer die oft bekannten A-DSL und S-DSL
ISP-verbindungen nichts zu tun. Es wird gezielt eine Bosch/Marconi
Baugruppe mit 8 Ports verwendet, welche mit 4 Ports eine feste
Geschwindigkeit von je ca. 2MBit/s (oder auch als 2,3MBit/s benannt)
erreicht. Wenn es die passenden Modems gaebe, koennte man es auch
ueber die aeltere HDSL- oder gar die HDB3-Technik realisieren. Da es
aber alte Techniken sind, wird eben die neueste SDSL (SHDSL)Technik
verwendet.

Wie erreicht man dann die 10 MBit/s? Durch Kanalbündelung?

Wie sieht das bei dem von Michael genutzten Produkt aus?

[Shinji Ikari]

Guten Tag.

Post by Detlef Bosau

Post by Shinji Ikari
Es wird gezielt eine Bosch/Marconi
Baugruppe mit 8 Ports verwendet, welche mit 4 Ports eine feste
Geschwindigkeit von je ca. 2MBit/s (oder auch als 2,3MBit/s benannt)
erreicht.

Wie erreicht man dann die 10 MBit/s? Durch Kanalbündelung?

Sie wird nicht erreicht. Er werden keine 10MBit/s geboten. Es ist nur
ein 10MBit/s Ethernet Interface. Darueber laeuft weniger.

Post by Detlef Bosau
Wie sieht das bei dem von Michael genutzten Produkt aus?

Die 51X ETH10 sind so, wie beschrieben realisiert. Soll ich es nochmal
wiederholen?

[Juergen Ilse]

Hallo,

Post by Shinji Ikari

Post by Juergen Ilse
Es gibt anscheinend einige wenige (wirklich *sehr* *wenige*) Hersteller
(moeglicherweise auch nur einen, ich habe mir dieses Zeug nie richtig
angesehen), die DSL-Technik bauen, die eben nicht "ATM over DSL" macht,
sondern direkt Ethernet-Frames statt ATM-Zellen ueber DSL uebertraegt.
Das Zeug funktioniert dann natuerlich nur, wenn sowohl CPE als auch
DSLAM vom selben Hersteller stammen,

Achtung! Die erwaehnte SDSL-technik ist SHDSL und hat mit den
ueblichen DSLam fuer die oft bekannten A-DSL und S-DSL
ISP-verbindungen nichts zu tun.

Es gibt durchaus Leute, die Begriffe wie ADSL, SDSL und SHDSL auseinander
halten koennen, und wenn nicht noch "Altgeraete" mit verbaut werden muessen,
wird heutzutage i.a. SHDSL statt SDSL verwendet (wegen groesserer Reichweite,
geringerer Stoeranfaelligkeit, weniger Problemen bei Kombination von Hard-
ware verschiedener Hersteller, ...). ADSL ist dagegen ein voellig anderes
Thema ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Shinji Ikari]

Guten Tag.

Post by Detlef Bosau

Laut dem T-Techniker ... handelt
es dabei physikalisch um vier gebündelte SDSL-Leitungen, wobei aber auf
Layer 2 nicht wie für SDSL üblich ATM, sondern Ethernet gesprochen wird.
Das von der Telekom installierte Modem trägt die Bezeichnung "T-NT10ETH"

Man möge dem Techniker ausrichten, daß auf SDSL, wie der Name schon
nahelegt, SDSL gesprochen wird und nicht Ethernet.

Das Gesamtprodukt wird als Ethernet verkauft.
Auf welchem Layer das stattfindet kann ich nicht sagen, aber der Kunde
bekommt eine nutzbare Ethernetverbindung, die mit SDSL nicht wirklich
etwas zu tun hat (ausser, dass es eben das SHDSL als Transportmedium
nutzt)..

Post by Detlef Bosau
Und wenn der Techniker den Unterschied zwischen SDSL und Ethernet nicht
kennt, möge er seinen Technikerbrief zurückgeben

Der Techniker hat sich an den Sprachgebrauch dieses Produktes
gehalten.

Post by Detlef Bosau
Was werden da eigentlich für Leute durchgefüttert, wenn ich mal direkt
fragen darf?

Ich weiss nicht, wo Dein Problem liegt, aber es wird ueber 4
ca.2MBit/s Verbindungen, welche auf SDSL-uebertragungen aufsetzen mit
entsprechenden Endgeraeten Ethernet Anschluesse bereitgestellt.
Das ist nichts anderes, als wenn der Kunde eine andere beliebige SFV
mietet/aufbaut und diese dann mit geeigneter Technik auf Ethernet
umsetzt. Wenn es sauber umgesetzt wird, ist es eben Ethernet.
Somit ist die Aussage des Techniker korrekt und er war sogar
auskunftsfreudiger als er haette sein muessen. Das dahinter 4x2MBit/s
ueber SDSL (eher SHDSL) Technik steckt haette er nicht sagen muessen.

fup zu de.comm.technik.dsl

[Detlef Bosau]

Post by Shinji Ikari
Guten Tag.

Post by Detlef Bosau

Laut dem T-Techniker ... handelt
es dabei physikalisch um vier gebündelte SDSL-Leitungen, wobei aber auf
Layer 2 nicht wie für SDSL üblich ATM, sondern Ethernet gesprochen wird.
Das von der Telekom installierte Modem trägt die Bezeichnung "T-NT10ETH"

Man möge dem Techniker ausrichten, daß auf SDSL, wie der Name schon
nahelegt, SDSL gesprochen wird und nicht Ethernet.

Das Gesamtprodukt wird als Ethernet verkauft.
Auf welchem Layer das stattfindet kann ich nicht sagen, aber der Kunde
bekommt eine nutzbare Ethernetverbindung, die mit SDSL nicht wirklich
etwas zu tun hat (ausser, dass es eben das SHDSL als Transportmedium
nutzt)..

Der Kunde kriegt eine Ethernetverbindung.

So. Also müssen wir jetzt mal schauen:

A --------------VomKundenGekriegteEthernetVerbindung ------------B

welche Paketrate kriegen wir von A nach B?

Und paßt die zur zugesicherten Rate aus der Produktbeschreibung?

Post by Shinji Ikari

Post by Detlef Bosau
Und wenn der Techniker den Unterschied zwischen SDSL und Ethernet nicht
kennt, möge er seinen Technikerbrief zurückgeben

Der Techniker hat sich an den Sprachgebrauch dieses Produktes
gehalten.

Gut. Das Produkt gewährleistet mir eine gewisse maximale Paketrate. Und
es wäre jetzt sinnvoll auszutesten, ob die erreicht wird.

Wenn ja: Verbindung ist in Ordnung.
Wenn nein: Zugesicherte Leistung wird nicht erbracht => Störungsmeldung.

Post by Shinji Ikari

Post by Detlef Bosau
Was werden da eigentlich für Leute durchgefüttert, wenn ich mal direkt
fragen darf?

Ich weiss nicht, wo Dein Problem liegt, aber es wird ueber 4
ca.2MBit/s Verbindungen, welche auf SDSL-uebertragungen aufsetzen mit
entsprechenden Endgeraeten Ethernet Anschluesse bereitgestellt.
Das ist nichts anderes, als wenn der Kunde eine andere beliebige SFV
mietet/aufbaut und diese dann mit geeigneter Technik auf Ethernet
umsetzt. Wenn es sauber umgesetzt wird, ist es eben Ethernet.

Fein. Aber das ist eben _nicht_ Ethernet. Das muß man auch ganz klar
sagen. Ich höre mir sowas immer wieder an, und man mache kein Remote
Bridigung und sonst was.

Aber Ethernet ist kein Buzzword, sondern Ethernet liegt in verschiedenen
Standards vor, die sämtlich auch eine physikalische Schnittstelle betreiben.

Und die Standorte hier sind nicht über eine solche verbunden.

Es werden hier also Ethernetpakete durchgereicht. _Wie_, das ist für den
Kunden transparent. Aber dennoch ist es kein Ethernet.

Post by Shinji Ikari
Somit ist die Aussage des Techniker korrekt und er war sogar
auskunftsfreudiger als er haette sein muessen. Das dahinter 4x2MBit/s
ueber SDSL (eher SHDSL) Technik steckt haette er nicht sagen muessen.
fup zu de.comm.technik.dsl

Die Frage ist jetzt: Ist diese Verbindung in Ordnung oder nicht?

[Shinji Ikari]

Guten Tag.

Post by Detlef Bosau

Post by Shinji Ikari

Post by Detlef Bosau
Und wenn der Techniker den Unterschied zwischen SDSL und Ethernet nicht
kennt, möge er seinen Technikerbrief zurückgeben

Der Techniker hat sich an den Sprachgebrauch dieses Produktes
gehalten.

Gut. Das Produkt gewährleistet mir eine gewisse maximale Paketrate.

Woher nimmst Du diese Annahme?
Es wird ihm eine Ethernet SFV Verbindung mit 10MBit/s Interface
geboten. Wie schnel die Verbindung dazwischen laeuft ist eien ganz
andere Sache.
In ETH10 kann man auch weniger als 10 MBit/s transportieren.

Post by Detlef Bosau
Und
es wäre jetzt sinnvoll auszutesten, ob die erreicht wird.

Er hat ja schon versucht darzulegen, dass er <9MBit/s erreicht.

Post by Detlef Bosau
Wenn nein: Zugesicherte Leistung wird nicht erbracht => Störungsmeldung.

Dem stimem ich zu. Aber was zugesichert wird, sollte in den
Vertragsunterlagen stehen und nicht dem Namen entnommen werden.
Zusaetzlich hat OP ein Problem: Er ist bei diesem Produkt nicht Kunde
des rosa Riesen, sondern hat einen anderen Anbieter dazwischen. Somit
kann OP nur die zugesicherten Eigenschaften seines Anbieters
einfordern. Was da drin steht koennen nur er(als
Kunde/Vertragspartner) und sein Anbieter wissen.

Post by Detlef Bosau
Fein. Aber das ist eben _nicht_ Ethernet.

Das ist Deine Interpretation.

Post by Detlef Bosau
Aber Ethernet ist kein Buzzword, sondern Ethernet liegt in verschiedenen
Standards vor, die sämtlich auch eine physikalische Schnittstelle betreiben.

Und die "Schnittstelle" ist Ethernet. nur die uebertragung Uzwischen
wird etwas anders realisiert.

Post by Detlef Bosau
Die Frage ist jetzt: Ist diese Verbindung in Ordnung oder nicht?

Er schafft knapp <9MBit/s: Ich wuerde sagen, ja das passt. Er kann es
ja messen und belegen lassen.

[Olaf Selke]

Post by Gross, Michael
Vor Produktivgang haben wir verschiedene Tests durchgeführt. Dabei kam
es zu Einbrüchen des Uploads, wenn der Download voll belastet war.

es liegt nicht am LAN selber? D.h. die CPE spricht ins LAN 100 MBit/s
full duplex und nicht mit 10 MBit/s half duplex?

Gruss, Olaf

[Gross, Michael]

Post by Olaf Selke
es liegt nicht am LAN selber? D.h. die CPE spricht ins LAN 100 MBit/s
full duplex und nicht mit 10 MBit/s half duplex?

Nein, die CPE steht laut Telekom fest auf 100MBit Full Duplex. Daran
kann es auch nicht liegen, andernfalls wären die 8MBit/s symmetrisch
wohl auch mit den Windows-Maschinen nicht möglich.

Auch auf den Switchen und Rechnern stimmt alles (was Duplex angeht).

Als Test haben wir übrigens FTP verwendet, das hatte ich vorhin ganz
vergessen :(

Jedenfalls ist es momentan so: Sobald ich den Download voll auslaste
(egal womit und wo), sinkt der Upload meiner Linux-Maschine von 8,5
MBit auf 3,5MBit/s.

Genauso, wie es auch bei den Tests mit den vier Linux-Testmaschinen
war.

Der Upload von einem Windows dagegen bricht nicht ein.

Ich werd's schon noch rausfinden ;)

[Ranjeev Darshan Rakshit Prasad]

Hi,

Post by Gross, Michael
Wir sind vor zwei Wochen von unserer 2MBit SDSL Leitung auf eine von der
Telekom als "10MBit-Leitung" vermarkteten Leitung umgestiegen.

darf man fragen ob das ein standard AGB-Produkt ist bzw wie die
Leistungsbeschreibungen, SLAs und Preise fuer das Ding aussehen, oder
wie der genaue Produktname heisst um bei der DTAG Infos einzuholen?

Was zahlt ihr fuer die Leitung (als Flat, 9x%, Traffic, Volumen) und was
hat im Vergleich die 2Mbit vorher gekostet (Faktor?)?

Welche Stadt/Gegend seid ihr mit dem Produkt, oder ist das Bundesweit
verfuegbar? Normales SDSL im Hintergrund, also im schlechtesten Fall
auch weniger als 2,3mbit je Doppelader bei sehr langer Leitung? Oder
faehrt die Telekom fuer solche Produkte auch garantierte n*2,3mbits
(aehnlich wie ihre HDSL/E1?/SFV Produkte mit garantierten 2048 bzw
1998kbit?)

Gruesse.

[Gross, Michael]

Hallo

Post by Ranjeev Darshan Rakshit Prasad
darf man fragen ob das ein standard AGB-Produkt ist bzw wie die
Leistungsbeschreibungen, SLAs und Preise fuer das Ding aussehen, oder
wie der genaue Produktname heisst um bei der DTAG Infos einzuholen?

Wie das Produkt von der Telekom angeboten wird, weiß ich nicht. Wir
beziehen das über unseren Internet Provider. Muss ich mal fragen.

Ich kenne deshalb auch nur den Preis für Endkunden: Wir jedenfalls
zahlen im Monat EUR 750,- exkl. MwSt. inkl. 300GB Traffic/Monat.

Post by Ranjeev Darshan Rakshit Prasad
Was zahlt ihr fuer die Leitung (als Flat, 9x%, Traffic, Volumen) und was
hat im Vergleich die 2Mbit vorher gekostet (Faktor?)?

Die 2MBit SDSL-Leitung hat AFAIK EUR 250,- gekostet (ebenfalls mit
300GB Volumen/Monat).

Post by Ranjeev Darshan Rakshit Prasad
Welche Stadt/Gegend seid ihr mit dem Produkt, oder ist das Bundesweit
verfuegbar? Normales SDSL im Hintergrund, also im schlechtesten Fall
auch weniger als 2,3mbit je Doppelader bei sehr langer Leitung? Oder
faehrt die Telekom fuer solche Produkte auch garantierte n*2,3mbits
(aehnlich wie ihre HDSL/E1?/SFV Produkte mit garantierten 2048 bzw
1998kbit?)

Wir sind in Braunschweig. Ob es bundesweit verfügbar, weiß ich nicht.

Und soweit ich eben weiß und laut Telekom-Techniker handelt es sich
wie gesagt um 4x 2,3MBit/SDSL das in dem Modem gebündelt wird.

Am Modem gibt es 4 LEDs, eine je Adernpaar. Der Techniker meinte dazu:

Wenn eine LED nicht mehr leuchtet, haben Sie 2,3MBit weniger.

[Gross, Michael]

Hallo

Post by Gross, Michael

Post by Ranjeev Darshan Rakshit Prasad
darf man fragen ob das ein standard AGB-Produkt ist bzw wie die
Leistungsbeschreibungen, SLAs und Preise fuer das Ding aussehen, oder
wie der genaue Produktname heisst um bei der DTAG Infos einzuholen?

Wie das Produkt von der Telekom angeboten wird, weiß ich nicht. Wir
beziehen das über unseren Internet Provider. Muss ich mal fragen.

Ich habe mal bei unserem ISP nachgefragt, das Produkt heißt

EtherConnect 10M

und eine Leistungsbeschreibung gibt es an folgender Stelle:

http://www.telekom.de/dtag/agb/dokument/pdf/0,1384,1443,00.pdf

[Gross, Michael]

Post by Gross, Michael
EtherConnect 10M

Ups, EthernetConnect meinte ich natürlich.

[Ranjeev Darshan Rakshit Prasad]

Post by Gross, Michael
Ups, EthernetConnect meinte ich natürlich.

Verstehe, ich dachte zunaechst, dass auch die DTAG euer Internetprovider
sei.

Euer Internetprovider in Braunschweig kauft also nur die
EthernetConnect-Leitung von eurem Standort zu ihren Pop, und machen die
Inet-Connectivity etc alles selber.

Hat einer Ahnung was andere Carrier so fuer 10mbit (SFV-aehnlich)
Leitung plus Traffic oder auch als Flat bzw pro MBit verlangen? Dass die
Entfernungen zu POPs oder Ballungszentren eine Rolle spielen ist
natuerlich klar, aber wasfuer sonstige grobe Richtpreise gibt es da so?

Weitere Frage: Ist 10Mbit/s heute nicht eher ueber Glas zu realisieren,
als die Koppelung von mehreren S(H)DSL Leitungen? Waere die Glasvariante
erheblich teurer?

Gruss.

[Gross, Michael]

Post by Ranjeev Darshan Rakshit Prasad
Euer Internetprovider in Braunschweig kauft also nur die
EthernetConnect-Leitung von eurem Standort zu ihren Pop, und machen die
Inet-Connectivity etc alles selber.

Exakt.

[Shinji Ikari]

Guten Tag.

Post by Ranjeev Darshan Rakshit Prasad

Post by Gross, Michael
Ups, EthernetConnect meinte ich natürlich.

Euer Internetprovider in Braunschweig kauft also nur die
EthernetConnect-Leitung von eurem Standort zu ihren Pop, und machen die
Inet-Connectivity etc alles selber.

so sieht es aus.

Post by Ranjeev Darshan Rakshit Prasad
Weitere Frage: Ist 10Mbit/s heute nicht eher ueber Glas zu realisieren,

Hier wird mit Absicht Ku verwendet, weil es eben beim Kunden schon
liegen koennte und somit nicht extra Glas ausgerollt werden muss.

Post by Ranjeev Darshan Rakshit Prasad
als die Koppelung von mehreren S(H)DSL Leitungen? Waere die Glasvariante
erheblich teurer?

Verlegungstechnisch ist es teurer als schon vorhandenes und geeignetes
Ku.

[Marc Haber]

Post by Ranjeev Darshan Rakshit Prasad
Weitere Frage: Ist 10Mbit/s heute nicht eher ueber Glas zu realisieren,
als die Koppelung von mehreren S(H)DSL Leitungen? Waere die Glasvariante
erheblich teurer?

Auf die letzte Frage würde ich spontan "Ja" antworten. Vor allen
Dingen, wenn das Glas zum Endkunden erst einmal gelegt werden muss.
Kupfer gibt es (fast) überall, sobald man zu einem Standort muss, wo
es Kupfer aber kein Glas gibt ist die Bündelvariante garantiert
billiger.

Addiere Skaleneffekte, und schwupps ist die Bündelvariante überall
billiger.

Grüße
Marc

[Ralph A. Schmid, DK5RAS]

Post by Ranjeev Darshan Rakshit Prasad
Weitere Frage: Ist 10Mbit/s heute nicht eher ueber Glas zu realisieren,
als die Koppelung von mehreren S(H)DSL Leitungen? Waere die Glasvariante
erheblich teurer?

Kupfer liegt mehr oder weniger überall im Boden, Glas müßte u.U. erst
verbuddelt werden. Das will man dann nicht wirklich bezahlen müssen...

[Olaf Selke]

Post by Gross, Michael
http://www.telekom.de/dtag/agb/dokument/pdf/0,1384,1443,00.pdf

"Ethernet-Frames werden transparent uebertragen", also doch kein mppp
wie urspruenglich von mir vermutet. Der naechste Schuss ins Blaue ist
Bridged-Ethernet ueber ATM nach RFC 1483 a la
ftp://ftp.rfc-editor.org/in-notes/rfc1483.txt

Das Linebonding koennte dabei als SHDSL physical Bonding erfolgen.

Gruss, Olaf

[Bjoern A. Zeeb]

Post by Olaf Selke

Post by Gross, Michael
http://www.telekom.de/dtag/agb/dokument/pdf/0,1384,1443,00.pdf

"Ethernet-Frames werden transparent uebertragen", also doch kein mppp
wie urspruenglich von mir vermutet. Der naechste Schuss ins Blaue ist

3518?

[Michael Holzt]

Post by Gross, Michael
http://www.telekom.de/dtag/agb/dokument/pdf/0,1384,1443,00.pdf

Hier gibts auch noch weitere Unterlagen dazu:
http://www.telekom.de/etelco/agb/1,18301,AGB_462,00.html?bs=e&pdf=1

Und hier die offizielle Anpreisung:
http://mittelstand.t-systems.de/msp/cms/content/MSP/de/39416

Neu ist das Produkt offenbar nicht. Golem.de hat schon 2004 berichtet,
daß es das ab da auch mit bis zu 1 GBit/s gibt.

[Michael Holzt]

Post by Gross, Michael
http://www.telekom.de/dtag/agb/dokument/pdf/0,1384,1443,00.pdf

Hier gibts auch noch weitere Unterlagen dazu:
http://www.telekom.de/etelco/agb/1,18301,AGB_462,00.html?bs=e&pdf=1
http://www.telekom.de/etelco/agb/1,18301,AGB_462A,00.html?bs=1&pdf=1

Für die 100M und 1G-Variante (die ist aber über Glas geschaltet):
http://www.telekom.de/etelco/agb/1,18301,AGB_462B,00.html?bs=1&pdf=1
http://www.telekom.de/etelco/agb/1,18301,AGB_462C,00.html?bs=1&pdf=1

Und hier die offizielle Anpreisung:
http://mittelstand.t-systems.de/msp/cms/content/MSP/de/39416

Neu ist das Produkt offenbar nicht. Golem.de hat schon 2004 berichtet,
daß es das ab da auch mit bis zu 1 GBit/s gibt.

[Oliver Bartels]

On Wed, 09 Aug 2006 15:38:02 +0200, "Gross, Michael"

Post by Gross, Michael
http://www.telekom.de/dtag/agb/dokument/pdf/0,1384,1443,00.pdf

Lies mal, was unter 1.1 steht:
"Die Ethernet-Frames werden transparent übertragen.
Steuerungsmechanismen der auf dem Ethernetprotokoll
aufgesetzten Dienste (z. B. TCP) können
den tatsächlichen Ethernetdurchsatz vermindern. Bei
nicht genutzter Flow Control können Frameverluste
durch Überlauf auftreten."

Flow Control (Backpressure) wäre für Euch in der Tat
eine nachdenkenswerte Option, die meisten Switche
beherrschen diese. Wenn diese nur einseitig aktiv ist
(z.B. am ISP Switch), dann kann es zu Effekten wie
von Dir beschrieben kommen.

Generell ist das TCP/IP zunächst auf die klassische
Upload/Download Situation _einer_ TCP-Verbindung
optimiert, problematisch wird es bei schwankenden
Latenzzeiten infolge Füllung der Warteschlange z.B.
am Router durch weitere Verbindungen und damit
verbundenen Latenzzeitschwankungen.

Du kannst Dir das so vorstellen, dass bei gleichbleibendem
Durchsatz und steigender Latenzzeit das TCP zunächst
das Fenster für noch nicht bestätigte Pakete größer macht.
Sollte nun die Latenzzeit spontan wieder kleiner werden,
dann fährt automatisch der Durchsatz hoch, u.U. zu hoch.
Irgendwann wird dann die Warteschlange per Paketwegwurf
verkleinert und bestenfalls somit das Fenster halbiert.
Geschieht das zu häufig durch einen nicht aus dem
Fenstermechanismus motivierten Dritteingriff (weitere
Verbindungen, technische Delays bei DSL, z.B. infolge
langsamer Reed Solomon Fehlerkorrektur bei sich
gegenseitig störenden Leitungen), dann leidet der
Durchsatz (*).

Flow Control kann hier helfen, weil sie von Knoten zu Knoten
vorgenommen wird, speziell wenn es um dedizierte Rechner
beim ISP versus bei Euch geht und sie auf der gesamten
Strecke implementiert ist.

(U.U. könnten auch ATM Paketverluste eine Role spielen,
falls ATM im Produkt verbaut ist.)

Dein Problem kommt mir insofern bekannt vor, als dass
wir ähnliches mit FTP auch bei einem Kunden mit hoher
Bandbreite (20 MBit/s) an einer VC3 Leitung (STM-1
Grundleitung auf Glas) hatten und der Tausch des FTP
Programms, ein Update des Betriebssystems (verbesserter
TCP Stack) und die durchgängige Aktivierung der Flow
Control Abhilfe brachten.

Derlei LAN_over_something Implementationen mit hoher
Bandbreite sind nicht trivial, dass muss auch nicht
am T-Com Produkt liegen.

Gruß Oliver

P.s.: (*) Im Backbone funktioniert das i.a. deshalb so gut, weil
es gnadenlose Überkapazitäten gibt und sich die Einflüsse
statistisch im Mittel ausgleichen. Geht eine Backbone-Leitung
über 80% Auslastung, dann fängt es für gewöhnlich an zu
lahmen.

[Ralph A. Schmid, DK5RAS]

Post by Oliver Bartels
P.s.: (*) Im Backbone funktioniert das i.a. deshalb so gut, weil
es gnadenlose Überkapazitäten gibt und sich die Einflüsse
statistisch im Mittel ausgleichen. Geht eine Backbone-Leitung
über 80% Auslastung, dann fängt es für gewöhnlich an zu
lahmen.

Ich verstehe das insofern richtig, als ein stinknormaler, fetter
Internet-Backbone Probleme bekommt, wenn er in Richtung 100%
ausgelastet wird? Das Ganze läuft also nur deswegen mehr oder weniger
vernünftig, weil die Grenze kaum mal erreicht wird?

Spannend...

[Oliver Bartels]

On Wed, 09 Aug 2006 19:18:44 +0200, "Ralph A. Schmid, DK5RAS"

Post by Ralph A. Schmid, DK5RAS
Ich verstehe das insofern richtig, als ein stinknormaler, fetter
Internet-Backbone Probleme bekommt, wenn er in Richtung 100%
ausgelastet wird? Das Ganze läuft also nur deswegen mehr oder weniger
vernünftig, weil die Grenze kaum mal erreicht wird?

Ja.
Es gibt dafür genügend Beispiele.

Richtig lustig wird es, wenn sogar BGP4 Traffic betroffen ist.
Je nachdem, wie das Netz aufgebaut ist, kann der sogar
Multihop sein. Wird dann zwischendrin zwischen BGP4 und
normalen Paketen nicht unterschieden, dann kann die
BGP4 Verbindung abbrechen und das so betroffene
Routing erhebliche Probleme bekommen.

Gruß Oliver

[Ralph A. Schmid, DK5RAS]

Post by Oliver Bartels
Ja.
Es gibt dafür genügend Beispiele.

OK. Ich habe nie darüber nachgedacht, aber klar, warum soll es da
anders laufen als vor Ort "im Kleinen"...

[Oliver Bartels]

On Fri, 11 Aug 2006 09:38:17 +0200, "Ralph A. Schmid, DK5RAS"

Post by Ralph A. Schmid, DK5RAS
OK. Ich habe nie darüber nachgedacht, aber klar, warum soll es da
anders laufen als vor Ort "im Kleinen"...

Es gibt aber Lösungsmöglichkeiten, eine, die ich hier schon
angeschnitten habe, ist Backpressure. Das gilt umso mehr für
ATM (und passt damit hierher, da DSL vielfach über ATM
geführt ist) und MPLS over ATM, genauso aber für TCP/IP.

Hierzu ein interessanter Artikel
(gecached, da Original gerade offline, sorry für den langen Link):
http://citeseer.ist.psu.edu/cache/papers/cs/16189/http:zSzzSzwww.cs.ucla.eduzSz~pazoszSzpubzSzINFOCOM99.pdf/using-back-pressure-to.pdf

Der ganze Trick bei der Geschichte ist, dass man die
Congestion an die Ecke des Netzwerks bringt, wo sie bei
vielen parallelen Datenströmen für die TCP Algorithmen
in viel definierterer Weise geschieht als im Core des
Netzwerks. D.h. die Regelalgorithmen der einzelnen
TCP Datenströme kommen sich nicht so leicht gegenseitig
in Quere, was chaotische Schwingungen bei der
Bandbreitenregelung vermeiden hilft.
Damit wird der Durchsatz insgesamt verbessert.

Der Artikel ist zwar ein paar Jahre alt, aber für die neuen
schnellen ADSL2+/VDSL Netze aktueller denn je ...

Gruß Oliver

[Ralph A. Schmid, DK5RAS]

Post by Oliver Bartels
Der ganze Trick bei der Geschichte ist, dass man die
Congestion an die Ecke des Netzwerks bringt, wo sie bei
vielen parallelen Datenströmen für die TCP Algorithmen
in viel definierterer Weise geschieht als im Core des

Jaja, klingt ganz einfach, aber ich denke mal, das ist es nicht :-)

Post by Oliver Bartels
Netzwerks. D.h. die Regelalgorithmen der einzelnen
TCP Datenströme kommen sich nicht so leicht gegenseitig
in Quere, was chaotische Schwingungen bei der
Bandbreitenregelung vermeiden hilft.

Es ist immer wieder interessant, wie uralte Ansätze aus der
Regelungstechnik immer wieder auch bei neueren Techniken ihren Einfluß
haben.

Post by Oliver Bartels
Damit wird der Durchsatz insgesamt verbessert.
Der Artikel ist zwar ein paar Jahre alt, aber für die neuen
schnellen ADSL2+/VDSL Netze aktueller denn je ...

Bin gerade am Laden, dauert "dank" GPRS bissl... Mal sehen, ob ich
davon etwas verstehen werde; mein diesbezügliches Wissen ist leider
nicht so wirklich allumfassend :) Danke!

Post by Oliver Bartels
Gruß Oliver

Grüße aus Kirchdorf!

Ralph.

[M G Berberich]

Post by Gross, Michael
Hallo
Wir sind vor zwei Wochen von unserer 2MBit SDSL Leitung auf eine von der
Telekom als "10MBit-Leitung" vermarkteten Leitung umgestiegen.
Laut dem T-Techniker, der bei uns die Messung durchgeführt hat, handelt
es dabei physikalisch um vier gebündelte SDSL-Leitungen, wobei aber auf
Layer 2 nicht wie für SDSL üblich ATM, sondern Ethernet gesprochen wird.
In der Praxis erreiche ich auch tatsächlich nur rund 8,8MBit/s, was ja
ungefähr 4 x 2,3MBit/s entspricht.

Bist Du Dir sicher, daß sich Deine Vorstellung von MBit mit der der
Telekom-Marketingabteilung deckt?

10*2^20 != 10*10^6

MfG
bmg