Re: Ethernet bounding

Hallo,

Am Montag 14 Januar 2002 13:29 schrieb Bernd Walter:
> On Mon, Jan 14, 2002 at 08:47:13AM +0100, Mirko Richter wrote:
> > Am Samstag 12 Januar 2002 19:54 schrieb Bernd Walter:
> > > On Sat, Jan 12, 2002 at 01:35:26PM +0100, Mirko Richter wrote:
> > > > Am Freitag 11 Januar 2002 19:52 schrieb Oliver Fromme:
> > > > > Andreano, Marco <hwkanm(at)handwerkskammer-freiburg.de> wrote:
> > >
> > > Das Spielchen funktioniert nicht Fehlerfrei.
> > > Du kannst damit nicht ausschliessen, daß die Packetreihenfolge
> > > umsortiert wird.
> > > Wenn die Reihenfolge durcheinandergerät kommt das einem Packetverlust
> > > gleich.
> >
> > Der TCP/IP-Stack fängt sowas problemlos ab, insofern das "Durcheinander"
> > im Rahmen bleibt. -> Sonst würde ja auch das ganze Internet nicht
> > funktionieren.
>
> Richtig.
> Das macht jedoch in jedem Fall Mechanismen wie delayed acks kaputt, sorgt
> für effektiv verkleinerte Windows.
> Es gibt jede Menge unangenehmer Probleme dadurch.
> Schliemstenfalls wird dadurch ein Packetverlust provoziert.
>
> Abgesehen davon gibt es mehr als nur TCP - andere haben auch ihre Probleme
> damit.
>
> > Verschiedene Routen bedeuten da ja auch, das sie Pakete in
> > unterschiedlicher Reihenfolge eintrudeln, na und, dan werden Sie halt vom
> > empfänger wieder richtig "zusammengebastelt".
>
> Im Internet werden Packete auch nicht derart durcheinandergerüttelt wenn
> alles richtig konfiguriert ist. Provider mögen stabile Routen.
> Das hier denoch einiges im Argen ist kann man deutlich sehen:
>
> 3054107 packets received
> 1627983 acks (for 1738841223 bytes)
> 37513 duplicate acks
> 0 acks for unsent data
> 2207143 packets (1989258034 bytes) received in-sequence
> 5306 completely duplicate packets (2574141 bytes)
> 241 old duplicate packets
> 1296 packets with some dup. data (338532 bytes duped)
> 51762 out-of-order packets (47593798 bytes)
> 1375 packets (1375 bytes) of data after window
> 1375 window probes
> 47995 window update packets
> 90 packets received after close
> 363 discarded for bad checksums
> 0 discarded for bad header offset fields
> 0 discarded because packet too short
>
<--- cut --->
> Wenn die Packete gleichlang sind wird selbsverständlich in der Regel
> auch das zuerst angefangene zuerst ankommen - Packete müssen aber nicht
> immer gleichlang sein.
> Mit einem FTP Download kann man das nur bedingt simulieren.
> Interessant wird es z.B. dann wenn die Clientanwendung nicht mitkommt
> und der Sender recht oft das Receivewindow auffüllt und kleine
> Endpackete schickt - Browser sind typische Kandidaten.

Wie gesagt, dort wo wir das System eingesetzt haben, existiert ein ziemlich
großes Netz mit mehreren Routern und auch unterschiedlichen Wegen zu den
einzelnen Gebäuden (Funk- und Optische Strecken, Standleitungen,
Wählverbindungen etc.), welche sich nun auch noch andern können (z.B.
Witterung). Dort konnten wir solche Probleme nicht bzw. nur in geringem
Umfang feststellen. Und an dem Proxy hängen verdammt viele Browser.

<--- cut --->

> > Und was mache ich, wenn mir 1Gbit nicht mehr reicht?
> > (meine Dual-Alpha hat nämlich keine Probleme den Gbit-Link
> > "vollzublasen" - aber momentan reichts noch :) )
> >
> > Dan kann ich entweder:
> > 1. einfach 2 (oder mehr) Gbit-Interfaces nehmen
> > oder
> > 2. warten, bis es 10 Gbit gibt.
>
> Wenn du mit mehr als 2Gbit zwischen 2 Rechnern Daten verschicken willst
> solltest du dich fragen ob Ethernet die richtige Wahl ist.
> Wenn du mehrere Clients hast ist eine Sessionbasierte Bündelung auch
> wieder kein Problem - bei Gbit wirst du ausserdem ohne Session-
> verteilung aufgrund der großen Sendebuffer viel schneller mit
> Round-Robin auf die Nase fallen.
>
> Out-of-order Behandlung ist nicht mehr als ein Workaround um einen
> Netzwerkfehler schneller in den Griff zu bekommen.
> Das ist keineswegs eine Entschuldigung das Netzwerkdesign schleifen
> zu lassen - In-order ist immer noch am besten.

Ich wollte das auch nicht als "Allheilmittel" darstellen, zumal 4x 100Mbit
duchaus teurer sein kann als einmal 1Gbit. In Unserem Fall war das allerdings
die kostengünstigere Variante. Der HP ProCurve 9304 hatte nuch freie 100Mbit
Ports aber keine Gbit Ports mehr und alle Modul-Slots waren belegt. Der Kunde
hätte wohl kaum mitgespielt, wenn ich ihm gesagt hätte er solle doch mal
schell noch einen 9308-er bei uns bestellen, und das wegen einem Rechner....

MfG Mirko

-- 
+--[ Mirko Richter (RHCE) ]------------------------+
|   Mirko Richter                                  |
|   Networks & Communicationsystems                |
|   Ernst-Thaelmann-Str. 5, D-06774 Soellichau     |
|   E-MAIL: m.richter(at)ngi-box.de                   |
|   Tel. +49/(0)34243/3369-50           \\\\       |
|   Fax. +49/(0)34243/3369-28           (O O)      |
+-----------------------------------oOOo-(_)-oOOo--+
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message