Hansenet Fastpath, hat das wer und lohnts sich? Pingzeiten (bitte nich aus nem Spiel, das bringt mir nichts weil ich kein UT/Q3/CS daddel)?

ingzeiten (bitte nich aus nem Spiel, das bringt mir nichts weil ich kein UT/Q3/CS daddel)?

Was willst du dann großartig mit fastpath?

X-forwarding?

X-forwarding?

Argument, aber so viel X-Forwarding, dass es den aufwand lohnt? [img]http://www.fb18.de/gfx/28.gif[/img]

Hansenet Fastpath, hat das wer und lohnts sich? Pingzeiten (bitte nich aus nem Spiel, das bringt mir nichts weil ich kein UT/Q3/CS daddel)?

Was bitte ist das? Hansenet Fastpath??

Also: Fastpath = abgeschaltetes Interleaving. Fastpath ist eigentlich weltweit bei so gut wie allen DSL-Anbietern üblich (oder zumindest ein Interleaving <= 5ms), mit einer Ausnahme: rosa-T konfigurierte bis vor kurzem jeden Anschluss mit dem maximal zulässigem Interleaving von 20ms (inzwischen kann man dies auch bei der Telekom als "Feature" bestellen und natürlich bezahlen).

Interleaving bedeutet, dass die Datenpakete ineinander "verschränkt" werden, zusammengehörende bytes werden also über einen gewissen Zeitraum verteilt. Wenn jetzt mehrere Bytes hintereinander gelöscht werden (sogenannte "Burstfehler", hervorgerufen durch z.B. Wählgeräusche), ist die Fehlerkontrolle der darüberliegenden Schichten oftmals in der Lage, diese Fehler zu korrigieren, da diese beim dekodieren wieder weiter auseinander liegen. Bei Fastpath müsste in dem Fall das ganze Paket erneut übertragen werden.

Interleaving verschlechtert also die Reaktionszeit (Ping) um bis zu 40ms (Hin und Rückweg), dafür wird die Qualität der Übertragung (z.B. Downloadgeschwindigkeit) gesteigert. Letzteres macht sich (nach dem, was ich gehört habe) allerdings nur dann bemerkbar, wenn man eh am Rande des DSL-Gebietes lebt.

Interleaving bedeutet, dass die Datenpakete ineinander "verschränkt" werden, zusammengehörende bytes werden also über einen gewissen Zeitraum verteilt. Wenn jetzt mehrere Bytes hintereinander gelöscht werden (sogenannte "Burstfehler", hervorgerufen durch z.B. Wählgeräusche), ist die Fehlerkontrolle der darüberliegenden Schichten oftmals in der Lage, diese Fehler zu korrigieren, da diese beim dekodieren wieder weiter auseinander liegen. Bei Fastpath müsste in dem Fall das ganze Paket erneut übertragen werden.

Leider hat IP meines wissens nach nur eine Fehlererkennung, keine Fehlerkorrektur, also werden fehlerhafte Pakete sowieso weggeschmissen. Deswegen verschlechtert sich die leitungsqualität auch nicht weiter mit Fastpath, denn die kaputten Pakete werden so oder so neu angefordert.

PPP scheint auch keine Großartigen Mittel zu haben, zumindest steht in der RFC zu PPP nichts davon. Im Übrigen halte ich es für abenteuerlich, mit 2 bzw. 4 Bytes ein 1500-Byte-Paket zu korrigieren, wenn man nicht weiß, wo der Fehler liegt [img]http://www.fb18.de/gfx/28.gif[/img]

Einbitfehler in grossen Paketen kann man recht gut ueber Matrizen lokalisieren (zwei Pruefsummen eine laengs zum uebertragenen Paket, eine quer).
Wenn man weiss, *das bit da* ist flasch, dann dreht man es halt um und fertig. Und gibt es bei dsl nicht vielleicht noch ein protokoll (wie zB ethernet/modem), das unter dem ppp liegt, und die fehler*korrektur* vornehmen kann?

Ich halte ja nicht viel vom rosa T, aber soo doof?

MoKrates

Ich halte ja nicht viel vom rosa T, aber soo doof?

Soo doof sind sie nicht. Das DSL Modem und das DSLAM (Die Gegenstelle beim Provider: DSL Access Multiplexer) benutzen mehere Frequenzen die fuer die Telfonie nicht benoetigt werden (deshalb der Splitter). Das was ueber die Leitung geht ist also kein ppp mehr sondern ueber ein kompliziertes Frequenz Multiplex/Demultiplex Protokoll (glaube es heisst AAL5)…
Mehr dazu gibts in der ct' 1/02 oder hier:
http://www.broadcastpapers.com/broadband/TandbergVideoToDSL02.htm

/jr

Dazu ist ppp auch noch ein Datenstromorientiertes Protokoll, und kein 'Frequenz'orientiertes (um es mal so zu nennen). Da muss irgendwas drunterliegen.

MoKrates

Soo doof sind sie nicht. Das DSL Modem und das DSLAM (Die Gegenstelle beim Provider: DSL Access Multiplexer) benutzen mehere Frequenzen die fuer die Telfonie nicht benoetigt werden (deshalb der Splitter). Das was ueber die Leitung geht ist also kein ppp mehr sondern ueber ein kompliziertes Frequenz Multiplex/Demultiplex Protokoll (glaube es heisst AAL5)…
Mehr dazu gibts in der ct' 1/02 oder hier:
http://www.broadcastpapers.com/broadband/TandbergVideoToDSL02.htm

Naja, das PPP ist shcon noch drin enthalten. Nur halt in einem höheren Level. Aber hat nicht jedes DSL-Mode eine Gegenstelle beim Provider? dann wäre es nicht sehr einfach, da zu Interleaven, denn auf der Leitung wäre dann ja nur ein Datenstrom.

Dann liegt da halt *noch* ein Protokoll zwischen…

MoKrates

Dann liegt da halt *noch* ein Protokoll zwischen…

Zwischen PPP und dem Physikalischen Protokoll? Das wird aber langsam wirklich überflüssig [img]http://www.fb18.de/gfx/28.gif[/img]

Was willst du dann großartig mit fastpath?

Quakeworld spielen! Außerdem spielen bei dem ping den die Spiele anzeigen noch andere sachen als nur dir reale Übertragungszeit eine Rolle. Bei Q3 ist es zb ganz schlimm da dort Packetloss und Ping gemixt werden, bei den meisten spielen ist es aber "nur" so das die leistung des rechners auch noch den im spiel angezeigten ping beeinflussen.

Dann liegt da halt *noch* ein Protokoll zwischen…

Zwischen PPP und dem Physikalischen Protokoll? Das wird aber langsam wirklich überflüssig [img]http://www.fb18.de/gfx/28.gif[/img]

Mitnichten. PPP geht zB auch ueber Modems. Das zeigt folgendes:
PPP ist ein "internet <-> duplex-data-stream" protokoll. Wenn ich das ueber ein Null-Modem-Kabel betreibe wird dann aber zB noch das Protokoll, dass dann die beruehmten parity-bits und start und stop-bits enthaelt, druntergelegt. PPP ist ein reines Software-Protokoll, dass einen Datenstrom erwartet. Eine Buchse in der Wand != Datenstrom!

MoKrates

Dann liegt da halt *noch* ein Protokoll zwischen…

Zwischen PPP und dem Physikalischen Protokoll? Das wird aber langsam wirklich überflüssig [img]http://www.fb18.de/gfx/28.gif[/img]

Mitnichten. PPP geht zB auch ueber Modems. Das zeigt folgendes:
PPP ist ein "internet <-> duplex-data-stream" protokoll. Wenn ich das ueber ein Null-Modem-Kabel betreibe wird dann aber zB noch das Protokoll, dass dann die beruehmten parity-bits und start und stop-bits enthaelt, druntergelegt. PPP ist ein reines Software-Protokoll, dass einen Datenstrom erwartet. Eine Buchse in der Wand != Datenstrom!

Das ist schon klar. Dadrunter liegt mindestens das physikalische Protokoll, denn irgendwie müssen die Daten ja in Spannungen codiert werden. Die Stop/Startbits sind Teil des RS232-Protokolls, soweit ich es sehen kann ein physikalisches Protokoll, die Start/Stop-Bits werden in die Physikalische Codierung mit einbezogen. Also kein Protkoll dem Physikalischen Protokoll des Modems (v.90 und konsorten) und PPP. RS232 wird zwischen Serieller Schnittstelle und Modem benutzt, v.90 dann auf der Leitung. Also läuft aus dme PC raus ein PPP-Paket, was in RS232 kodiert ist und übers Modem läuft dann das PPP-Paket kodiert in v.90. Da ist kein Protokoll dazwischen [img]http://www.fb18.de/gfx/22.gif[/img]

PS: PPP ist nicht internet-gebunden. PPP bildet mehrere Protkollströme auf eine Einzelleitung zwischen zwei Orten ab. Mehr nicht [img]http://www.fb18.de/gfx/22.gif[/img]

Tri, bist Du sicher, dass Du gesund bist?

Naja, aber irgendjemand muss das Interleaving ja machen, oder kann standard-PPP mit *verschraenkten* Paketen umgehen?

MoKrates

Tri, bist Du sicher, dass Du gesund bist?

Garantiert nicht [img]http://www.fb18.de/gfx/22.gif[/img]

Naja, aber irgendjemand muss das Interleaving ja machen, oder kann standard-PPP mit *verschraenkten* Paketen umgehen?

Warum sollte PPP es machen. Man bedenke ja es ist eine Punkt-zu-Punkt-Verbindung. d.h. es sind genau zwei Punkte involviert und EIN Datenstrom zwischen den beiden, da hat man garnichts anderes zum Interleaven [img]http://www.fb18.de/gfx/28.gif[/img]

auch wahr…

Wer zum Henker dekodiert dann die verdammten verschraenkten Pakete?

/me was kicked again for swearing…

MoKrates

Das interleaving geschieht doch auf dem ATM Adaption Layer (AAL) oder nicht?

Das interleaving geschieht doch auf dem ATM Adaption Layer (AAL) oder nicht?

Also den gibts sowieso nur auf ATM-Systemen, aber das wäre ein Punkt an dem das durchaus möglich wäre (vorausgesetzt die Telekom benutzt ATM). Die untere hälfte vom AAL heißt SAR (Segmentation and reassembly), da könnte in der DSL-Gegenstelle wenn man sowieso schon die Pakete zerlegen muss, auch ein bisschen Zerlegen. Aber auch ATM hat keine großartigen Fehlerkorrekturmöglichkeiten soweit ich das sehe, der Tanenbaum sagt "Cell delivery is not guaranteed" und wenn dafür schon kein Aufwand getrieben wird, dann wird im 5-Byte-Header auch bestimmt keine ausführliche Checksumme sein. Außerdem kommen in so niedrigen Protokollen die Checksummen eigentlich immer nach den Daten. Aber man könnte natürlich in die 48 Byte Benutzerdaten noch Fehlerkorrekturinfos stopfen, aber ob sich das bei der hohen zuverlässigkeit von ATM überhuapt lohnt…

Mal davon abgesehen fällt mir gerade ein: Interleaving ist doch DSL-spezifisch. Dann kann das Interleaving nicht erst bei ATM stattfinden, also im internen Netz der Telekom. Außerdem wäre es sonst doch kompliziert, Interleaving für ienen Nutzer abzuschalten…

Hab den Übeltäter gefunden. Die PPPoE-Pakete die beim Modem ankommen, werden tatsächlich in ATM-Zellen aufgeteilt. Laut [img]http://www.fb18.de/gfx/1.gif[/img] enthält eine ATM-Zelle die dann übers DSL geht (ATM stirbt owhl dohc nicht so shcnell aus…) immer nur 48 Bytes eines PPPoE-Paketes, nach 48 Bytes kommt das nächste Paket erst dran. Und das soll was helfen…

[img]http://www.fb18.de/gfx/1.gif[/img] http://www.informatik.fh-muenchen.de/~ifw99235/dako/dako_upload.pdf

also geht das hier gewissermaßen als http over tcp over ip over ppp over ethernet over atm raus. cool

Das ist dann wohl die praktische Anwendung von "Every problem in informatics is solved by yet another level of indirection" (von wem kommt das nochmal?)

wobei es da eigentlich nur eine schicht gibt, die ich gerne weglassen möchte

na gut ethernet könnte auch weg, muss aber nicht

also geht das hier gewissermaßen als http over tcp over ip over ppp over ethernet over atm raus. cool

Das ist aber sehr unvollstaendig. Bei mir zu Hause:

(Rechner: http - tcp - ip - ethernet) - (router: ethernet - atm - pppoe - ethernet) - (modem: ethernet - und raus) <-> (contentprovider: und rein - blablabla - ip - tcp - http - dyncontentprotokoll - datenbankabfragesprachen (zB sql))

Das ist schon ordentlich, vor allem wenn man bedenkt, dass die halbe Contentproviderseite und die ganze Providerseite fehlt.

Und denk daran, wenn Du das naechste mal in einer Konsole "ping" eintippst [img]http://www.fb18.de/gfx/7.gif[/img].

MoKrates

Das ist aber sehr unvollstaendig. Bei mir zu Hause:

(Rechner: http - tcp - ip - ethernet) - (router: ethernet - atm - pppoe - ethernet) - (modem: ethernet - und raus) <-> (contentprovider: und rein - blablabla - ip - tcp - http - dyncontentprotokoll - datenbankabfragesprachen (zB sql))

*klugscheissmode*
Na moment, der Router schmeißt keine ATM-Pakete. Die ATM-Pakete gehen zwischen Modem und Provider soweit ich das sehe. Ansonsten wäre Interleaving nur eine Geschichte zwischen dir und deinem Modem. Außerdem habe ich noch nie in einem Windoof-System einen ATM-Treiber für DSL installiert (Linux hat sowas ja sichelrihc sowieso irgendwo als modul rumstehen, da weiß man nie [img]http://www.fb18.de/gfx/28.gif[/img]).

also irgendwie ist in der auflistung bei mokrates der wurm drinn, aber ich bin zu müde um das jetzt klarzubekommen, und muss noch M2 fertig machen ;-)

also irgendwie ist in der auflistung bei mokrates der wurm drinn, aber ich bin zu müde um das jetzt klarzubekommen, und muss noch M2 fertig machen ;-)

Also der einzige efhler den ich sehe, ist, dass atm nicht zum router gehört. Von Modem zu Provider dürfte es dann sein:
ATM - PPP - IP - TCP - HTTP

Also der einzige efhler den ich sehe, ist, dass atm nicht zum router gehört.

ack

Von Modem zu Provider dürfte es dann sein:
ATM - PPP - IP - TCP - HTTP

nö, das modem transportiert ethernet frames über ATM

meiner meinung nach:
ATM - Ethernet - PPP - IP - TCP - HTTP

edit: Ach ja, es gibt noch eine andere Art DSL zu veranstelten, in deutschland aber wohl nirgendwo in gebrauch:
(ATM -) Ethernet - IP - TCP - PPTP - IP - TCP - HTTP

Von Modem zu Provider dürfte es dann sein:
ATM - PPP - IP - TCP - HTTP

nö, das modem transportiert ethernet frames über ATM

meiner meinung nach:
ATM - Ethernet - PPP - IP - TCP - HTTP

edit: Ach ja, es gibt noch eine andere Art DSL zu veranstelten, in deutschland aber wohl nirgendwo in gebrauch:
(ATM -) Ethernet - IP - TCP - PPTP - IP - TCP - HTTP

Also ATM ist ein Physikalisches Protokoll und Ethernet eines. Man kann schlecht beide auf einmal benutzen [img]http://www.fb18.de/gfx/28.gif[/img] Außerdem: Wozu ein Protkoll mit Multiple-Access, Riesiger Adressierung etc. auf einem 2-Punkt-Link?

Also ATM ist ein Physikalisches Protokoll und Ethernet eines. Man kann schlecht beide auf einmal benutzen Außerdem: Wozu ein Protkoll mit Multiple-Access, Riesiger Adressierung etc. auf einem 2-Punkt-Link?

ich checke das

ich checke das

KRÄMERALARM!!!!

Als haetten wir nix besseres zu tun…

* /me macht eine neue Packung Tabak auf…

MoKrates

Also ATM ist ein Physikalisches Protokoll und Ethernet eines. Man kann schlecht beide auf einmal benutzen Außerdem: Wozu ein Protkoll mit Multiple-Access, Riesiger Adressierung etc. auf einem 2-Punkt-Link?

ich checke das

Um einen draufzusetzen. Wer solld ie gegenstelle für die Ethernet-Rahmen sein? Die Webserver laufen ja nicht alle auf Ethernet…Und sobald iener das nicht mehr tut, machen verpackte Ethernet-Rahmen keinen Sinn mehr.

Um einen draufzusetzen. Wer solld ie gegenstelle für die Ethernet-Rahmen sein? Die Webserver laufen ja nicht alle auf Ethernet…Und sobald iener das nicht mehr tut, machen verpackte Ethernet-Rahmen keinen Sinn mehr.

irgendwas zwischen der gegenstelle von atm und der gegenstelle von ppp

übrigens heisst die spezielle Art von ppp die hier Zum Einsatz kommt pppoe was für point to point protocol over ethernet

da erwartet man doch, dass das ganze tatsächlich über ethernet übertragen wird, aber wie gesagt, ich werde das checken

da erwartet man doch, dass das ganze tatsächlich über ethernet übertragen wird, aber wie gesagt, ich werde das checken

Wirds doch. Von dienem Rechner zum DSL-Modem, das ist die Ethernet-Strecke über die PPP praktiziert wird, also PPPoE.

aber das ppp geht doch nur bis zum modem sondern weiter!

aber das ppp geht doch nur bis zum modem sondern weiter!

Kann es ja auch. Aber bitte nur das PPP, das kann man sicherlich recht simpel trennen. Nur ists danach kein PPPoE mehr, sondenr ein ganz normales PPP was auf der physikalischen Ebene durch ATM realisiert wird.

IIRC ist das oE nur zur Einwahl da…

MoKrates

IIRC ist das oE nur zur Einwahl da…

Nein. Per Ethereal wird schnell sichtbar, dass dein Rechner die ganze zeit PPPoE verschickt. Und ansonsten, was soll danach laufen? PPP? PPP auf Ethernet? Das wäre dann ja wieder PPPoE [img]http://www.fb18.de/gfx/28.gif[/img]

nochmal zum OP: "normale" Pingzeiten ohne Fastpath interessieren mich auch.
zu PPPoe,PPP,ATM,TCP/IP: Das Internet kommt bei mir aus der Telefonanlage ;)

Ich habe mir Fastpath bei Hansenet bestellt und duerfte es neachste Woche haben (Poste dann die Werte).

Momentan hab ich im Schnitt zur rzdspc3 nen Ping von 31ms und zu terragate.net 29ms.

/jr

hm jetzt schon ping 29-31, da ham die aber nen schwaches interleaving eingeschaltet, wenn ich da an ping 61 mit t-dsl denke.

habe das gecheckt:

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

Please stop kraemering this thread…

Und? Soll *ich* jetzt den ganzen RFC jetz lesen, oder was?

MoKrates

habe das gecheckt:

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

Klar KANN man das machen um z.B. zwei LANs über eine ATM-Leitung zu verbinden. Da sist ja nicht die Frage, die Frage ist: macht DSL das und ich bestehe immernoch auf nein [img]http://www.fb18.de/gfx/22.gif[/img]

Und? Soll *ich* jetzt den ganzen RFC jetz lesen, oder was?

nö, such doch mal nach den worten "ethernet", "atm" und "encapsulation" und glaub mir

es sei denn du willst die sache auch noch rogern…

Habe jetzt Fastpath. Ist aber nich dolle.

Zur Uni hat sich nichts getan und zu terragate.net sinds jetzt 5ms weniger.

Ich haette mal vorher den P-t-P pingen sollen: Jetzt sind es 10ms. Der Rest haengt dann von der Distanz ab (Uni >=12 hops, terragate>=10 hops)…

Mein Rat: Spart euch die 2,90 Euro (Macht 1 teures Bier mehr im Monat)

/jr

Klar KANN man das machen um z.B. zwei LANs über eine ATM-Leitung zu verbinden. Da sist ja nicht die Frage, die Frage ist: macht DSL das und ich bestehe immernoch auf nein

auch das werde ich checken

aber erkläre mir doch mal wie du zwei punkte per ppp over ethernet verbinden willst, ohne das diese beiden punkte über ethernet verbunden sind

Klar KANN man das machen um z.B. zwei LANs über eine ATM-Leitung zu verbinden. Da sist ja nicht die Frage, die Frage ist: macht DSL das und ich bestehe immernoch auf nein

auch das werde ich checken

aber erkläre mir doch mal wie du zwei punkte per ppp over ethernet verbinden willst, ohne das diese beiden punkte über ethernet verbunden sind

Solange die beiden Endpunkte an einem Ethernet sitzen kein Problem, Beispiel die LANs sind via ATM verbunden:

PC1 schickt PPPoE an Bridge1 (via Ethernet)
Bridge1 schickt PPPoE gekapselt in ATM an Bridge2 (via ATM)
Bridge2 schick PPPoE an PC2 (via Ethernet)

Solange die beiden Endpunkte an einem Ethernet sitzen kein Problem, Beispiel die LANs sind via ATM verbunden:

PC1 schickt PPPoE an Bridge1 (via Ethernet)
Bridge1 schickt PPPoE gekapselt in ATM an Bridge2 (via ATM)
Bridge2 schick PPPoE an PC2 (via Ethernet)

ja, aber dann werden doch ethernet frames zwischen PC1 und PC2 ausgetauscht

nix anderes habe ich von Anfang an behauptet

ja, aber dann werden doch ethernet frames zwischen PC1 und PC2 ausgetauscht

nix anderes habe ich von Anfang an behauptet

Das impliziert aber, dass PC1 und PC2 an einem Ethernet hängen was bei Internethosts nicht sein muss.

PC2 ist aber die Telekom PPP Gegenstelle
und wie ich versuche dir zu erklären hangt die zumindest virtuell mit dir am selben ethernet

PC2 ist aber die Telekom PPP Gegenstelle
und wie ich versuche dir zu erklären hangt die zumindest virtuell mit dir am selben ethernet

Fakt oder gedacht [img]http://www.fb18.de/gfx/28.gif[/img] Ansich ists doch unlogisch an der Telekom PPP Gegenstelle extra die ATM-Pakete wieder zu PPPoE-Paketen zu machen um diese dann zu PPP-Paketen machen. Das ist nur zusätzlicher Overhead auf der DSL-Leitung, da kann auch gleich das Modem PPP-Pakete übers ATM verschicken. Denn intern hat die Telekom bestimmt kein Ethernet.

also macht das modem deiner meinug nach aus ppp over ethernet paketen ppp over atm pakte?

wie geht das?

I C Q

Also ICQ funktioniert auch komplett ohne PPP-Pakete *duck*

also macht das modem deiner meinug nach aus ppp over ethernet paketen ppp over atm pakte?

wie geht das?

PPPoE-Header ab, wichtige Daten in ein PPP-Paket packen und Checksumme neu Berechnen?

*lichtschwert zück*

PPPoE-Header ab, wichtige Daten in ein PPP-Paket packen und Checksumme neu Berechnen?

nach welchem rfc?

PPPoE-Header ab, wichtige Daten in ein PPP-Paket packen und Checksumme neu Berechnen?

nach welchem rfc?

Wieso RFC? Mein Rechner hält eine PPPoE-Verbindung mitm Modem. Das Modem hält dann für sich eine PPP-Verbindung mit der Telekomstelle. Dafür braucht man nur die RFCs für PPPoE und PPP.

I C Q

Also ich finde es on Topic und interessant. Nicht annaehernd so schlimm wie unsere beinahe-geistigen Sekrete sonst hier.

MoKrates

Falls es interessiert, Hansenet mit Fastpath:

ping [url=http://www.heise.de]www.heise.de[/url] PING [url=http://www.heise.de]www.heise.de[/url] (193.99.144.71): 56 octets data icmp_seq=0 ttl=247 time=24.8 ms icmp_seq=1 ttl=247 time=24.9 ms icmp_seq=2 ttl=247 time=24.1 ms icmp_seq=3 ttl=247 time=23.5 ms icmp_seq=4 ttl=247 time=25.8 ms Auf quake3 Server kommt man min. auf 50 ms, also lohnt nicht wirklich. Dafür hat man ja 2 Wochen Widerrufsrecht.