1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Verbindungsturbo: Wie Googles Rack…

Das ziehlt vor allem auf Asymetrische Leitungen

  1. Thema

Neues Thema Ansicht wechseln


  1. Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: JouMxyzptlk 27.07.16 - 12:24

    Gerade bei diesen 100 MBit down, und 2.5 MBit up Leitungen ist der Unterschied mit 40:1 derart extrem dass die ACK's vom TCP in einigen Situationen den Upstream vollmüllen können und man nicht mal Ansatzweise die 100 MBit nutzen kann.
    Wenn also nicht auf jedes ACK gewartet wird verbessert sich die Situation für diejenigen an diesen Schrott-Leitungen.
    Bei 16:1 (DSL 16000) dürfte sich das auch noch bemerkbar machen.
    Bei einem down:up Verhältnis von weniger als 10:1 dürfte es sich weniger stark auswirken, selbst wenn ein Upload nebenher läuft.

  2. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: Gucky 27.07.16 - 12:36

    ich habe hier 32:1 DSL 16000.. (16Mbit/s Down, 0,8Mbit/s Up) ich dachte das wäre standart....

  3. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: Apollo13 27.07.16 - 12:44

    16/0,8 = 20 - und das ist nur einer von zwei gängigen Verhältnissen, also quasi ein Standar_d_ :) SCNR

  4. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: JouMxyzptlk 27.07.16 - 12:48

    Gucky schrieb:
    --------------------------------------------------------------------------------
    > ich habe hier 32:1 DSL 16000.. (16Mbit/s Down, 0,8Mbit/s Up) ich dachte das
    > wäre standart....

    Nein, Standard bei 16000 down und 1000 up, schau mal in die sync-raten deiner Firtzbox. Wenn es weniger ist: Anrufen. Ansonsten: 16000/800 = 20. 16000/500 sind 32.

    Edit: Also bei dem Nicknamen kannst du doch teleportieren, mach doch ein Geschäft auf für Schnelltransport von Festplatten mit großen Datenmengen. Schneller als das Internet.



    1 mal bearbeitet, zuletzt am 27.07.16 12:52 durch JouMxyzptlk.

  5. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: quasides 27.07.16 - 13:21

    die teleportation kann nicht schneller sein weil die datenmenge die notwendig ist um die festplatten zu rematerialisieren ein milionenfaches größer ist als der in halt der platten

    wenn man bereits die möglichkeit hat diese menge zu übertragen und empfangen kann man den weg gleich nehmen um die daten zu übertragen

    just saying :))

  6. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: elf 27.07.16 - 23:00

    Dann ist an deinem Client was falsch konfiguriert. Die ACKs muessen nur fuer das letzte Segment von ggf. Amehreren gesendet werden. Upload duerfte weit unterhalb von 1:20 ggü Diwnload belastet sein, wenn die Clients richtig arbeiten. Ansonsten waere es bei Videos schlimmstenfalls etwa 68:1492 Bytes.

  7. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: tingelchen 29.07.16 - 17:47

    Komm wir essen Opa.... Satzzeichen retten leben.

    Ach so. "Inhalt" schreibt man noch immer zusammen ;)

  8. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: tingelchen 29.07.16 - 18:03

    Wenn dem so wäre. Wieso müsste man sich dann überlegen TCP zu beschleunigen? Immerhin könnte man seine, what ever, 50 Segmente einfach ins Netz brüllen und die Gegenseite schickt dann ein einzelnes ACK, nachdem sie 50 Segmente empfangen haben.

    Hat nur einen Nachteil... wann und welche der 50 Segmente schickt man neu?

    Bedenke. Ein ACK ist nicht damit spezifiziert, das dort eine unbestimmte Anzahl an Sequenznummern enthalten sind, sondern immer genau eine. Daher brauch ein ACK auch kein Body. Sondern besteht nur aus dem IP Header.

  9. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: Crass Spektakel 01.08.16 - 01:54

    Die maximale Grösse eines TCP-Package ist 2346 Bytes, ein ACK ist mindestens 46 Bytes gross (roh). D.h. Faktor ca. 1:50. Weil Dinge nie optimal laufen (nicht jedes TCP-Package ist maximal lang) sollte eine Kommunikation mindestens eine Bandbreite im Verhältnis 4:50~1:12 aufweisen. Bei 1:20 sehe ich aber keinen Grund zur Panik, Du bekommst wohl keine 100% aber sicher 98%.

    Achtung, wenn Du PPP verwendest (in Deutschland wohl 80% der Anwender), da werden ACKs ZUSAMMENGEFASST. Völlig Gaga aber ist so. Da funktioniert teilweise sogar eine Bandbreite von 1:100 noch halbwegs.

    Witziges Detail am Rande, mein Provider erlaubt mir Jumbo-PPP-Frames. Er schlägt sie zwar nicht vor aber wenn ich sie erzwinge gehen sie in beide Richtungen durch Wenn hier richtig was los ist gehen hier Frames mit 32kByte durchs Netz und nur alle 64-256kByte geht mal ein Packen ACKs raus... Soweit ich das diagnostizieren kann repackt der Provider das am Last Hop auf seiner Seite so wie auch mein Linux erstmal mehrere kleine Packages sammelt und dann ein grosses draus macht. Das springt wohl erst an wenn auf der Leitung ein Rückstau von ca. 100kByte vorhanden ist. Aber wie gesagt, nur PPP. Andere Provider machen das selten, vermutlich weils halt viel RAM blockiert.



    1 mal bearbeitet, zuletzt am 01.08.16 01:58 durch Crass Spektakel.

  10. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: elf 01.08.16 - 10:49

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > Wenn dem so wäre. Wieso müsste man sich dann überlegen TCP zu
    > beschleunigen? Immerhin könnte man seine, what ever, 50 Segmente einfach
    > ins Netz brüllen und die Gegenseite schickt dann ein einzelnes ACK, nachdem
    > sie 50 Segmente empfangen haben.

    Korrekt. Das machen die heutigen Clients exakt so. Es gibt aber auch noch veraltete Clients, die jedes einzelne Segment bestätigen. Das verstopft naturgemäß die Upload-Bandbreite, das Verfahren ist aber nicht notwendig. Wieviele Segmente unbestätigt auf die Reise gehen, wird im Laufe einer bestehenden Verbindung ermittelt. Je mehr Pakete unbeschadet ankommen, umso mehr schickt der Sender unbestätigt auf Reise. Daher steigt die Downloadrate mit zunehmender Zeit (wenn der Server und Client richtig konfiguriert sind).
    TCP sieht immer schon vor, dass man mit einem ACK sämtliche Segmente bestätigt, die vorher schon da waren, d.h. der Sender weiß, dass alle vorhergehenden Segmente nicht mehr erneut gesendet werden müssen und können vergessen werden. Manche TCP-Stacks sind aber so stur und senden unabhängig aller anderen Segmente einfach ein ACK für ihr gerade aus der Queue bearbeiteten Segment.

    > Hat nur einen Nachteil... wann und welche der 50 Segmente schickt man neu?
    Das stand im Artikel: SACK - eine Protokollerweiterung von TCP, um nicht sämtliche Segmente ab dem letzten ACK erneut senden zu müssen, sondern nur diejenigen, die wirklich noch ausstehen.

    > Bedenke. Ein ACK ist nicht damit spezifiziert, das dort eine unbestimmte
    > Anzahl an Sequenznummern enthalten sind, sondern immer genau eine.
    Richtig, nix anders behaupte ich doch.

    > Daher
    > braucht ein ACK auch kein Body. Sondern besteht nur aus dem IP Header.

    Nicht ganz, es besteht aus dem TCP-Header, das oberhalb des IP-Stacks angesiedelt ist. Und was willst du mir damit sagen? Ich schrieb doch im letzten Beitrag, dass das letzte Ack das letzte Segment und sämtliche Segmente davor bestätigt. Da brauche ich nur dieses eine Feld im TCP-Header.
    Bei SACK geht es dann noch weiter, das heutzutage praktisch alle TCP-Implementierungen beherrschen. Selbst meine Vuduo/Dreambox.

    Und um auf deine aller erste Frage einzugehen: Das Problem bei TCP ist nicht das Übertragen großer Datenmengen über große Bandbreiten. Das Problem sind *kleine* Datenmengen, weil es viel zu lange dauert, bis ein verlorenes Segment als fehlend erkannt wird. Nervig bei interaktiver Bedienung, es scheint dann immer mal wieder etwas zu hängen. Bei Verbindungen zu entlegenen Regionen in dieser Welt ist eine Interaktion praktisch unmöglich.
    Selbst in meinem LAN zu Hause habe ich damit zu kämpfen, weil mit dem ersten Verbindungsaufbau zum NAS die RTT (round-trip-time) festgelegt wird, die bei mir zu Hause aber exorbitant hoch ist, weil das NAS erst aus dem Standby aufwachen muss. Das dauert mitunter 15s, fehlende Pakete werden damit erst bis zu 90s verspätet erneut gesendet. Filme von Platte schauen ist damit nervig, hab ich aber nun halbwegs in den Griff bekommen, weil ich das mit dem RTT rausbekommen habe und gegenmaßnahmen ergriffen habe.
    Und frag nicht, warum im LAN Pakete verloren gehen - ich weiß es nicht, die Suche danach (nur jedes 10.000-100.000ste Paket fehlt) ist weit aufwändiger als der Workaround, der für mich für speziell diesen einen Fall passt.

  11. Re: Das ziehlt vor allem auf Asymetrische Leitungen

    Autor: Martin F. 04.08.16 - 00:19

    JouMxyzptlk schrieb:
    --------------------------------------------------------------------------------
    > Gucky schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ich habe hier 32:1 DSL 16000.. (16Mbit/s Down, 0,8Mbit/s Up) ich dachte
    > das
    > > wäre standart....
    >
    > Nein, Standard bei 16000 down und 1000 up, schau mal in die sync-raten
    > deiner Firtzbox. Wenn es weniger ist: Anrufen.

    Mein letzter Stand war, dass bei Drittanbietern, die den Telekomanschluss nutzen, nur 800 kbit/s zur Verfügung stehen, weil Bandbreite für Telefonie (VoIP) reserviert wird, während man bei der Telekom unabhängig davon analog telefoniert.

    --
    Bitte prüfen Sie, ob Sie diesen Beitrag wirklich ausdrucken müssen!

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH, Bonn-Röttgen
  2. DMK E-BUSINESS GmbH, Berlin-Potsdam, Köln, Chemnitz
  3. Fraunhofer-Institut für Integrierte Schaltungen IIS, Erlangen
  4. Luft- und Thermotechnik Bayreuth GmbH, Goldkronach

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 21,99€
  2. 18,69€
  3. gratis


Haben wir etwas übersehen?

E-Mail an news@golem.de


5G: Nokias und Ericssons enge Bindungen zu Chinas Führung
5G
Nokias und Ericssons enge Bindungen zu Chinas Führung

Nokia und Ericsson betreiben viel Forschung und Entwicklung zu 5G in China. Ein enger Partner Ericssons liefert an das chinesische Militär.
Eine Recherche von Achim Sawall

  1. Quartalsbericht Ericsson mit Topergebnis durch 5G in China
  2. Cradlepoint Ericsson gibt 1,1 Milliarden Dollar für Routerhersteller aus
  3. Neben Huawei Telekom wählt Ericsson als zweiten 5G-Ausrüster

Corsair K60 RGB Pro im Test: Teuer trotz Viola
Corsair K60 RGB Pro im Test
Teuer trotz Viola

Corsair verwendet in der K60 Pro RGB als erster Hersteller Cherrys neue preiswerte Viola-Switches. Anders als Cherrys günstige MY-Schalter aus den 80ern hinterlassen diese einen weitaus besseren Eindruck bei uns - der Preis der Tastatur hingegen nicht.
Ein Test von Tobias Költzsch

  1. Corsair K100 RGB im Test Das RGB-Monster mit der Lichtschranke
  2. Corsair Externes Touchdisplay ermöglicht schnelle Einstellungen
  3. Corsair One a100 im Test Ryzen-Wasserturm richtig gemacht

Energiewende: Wie die Begrünung der Stahlindustrie scheiterte
Energiewende
Wie die Begrünung der Stahlindustrie scheiterte

Vor einem Jahrzehnt suchte die europäische Stahlindustrie nach Technologien, um ihren hohen Kohlendioxid-Ausstoß zu reduzieren, doch umgesetzt wurde fast nichts.
Eine Recherche von Hanno Böck

  1. Wetter Warum die Klimakrise so deprimierend ist