Re: Netzwerkproblem GBit -> 100MBit

Hallo,

Mirko Guldner wrote:

Nirgends so direkt, deshalb das "tendenziell"; ich lese aber auch
nirgends, dass für diesen Fall - 100MBit Clients am Ende einer
GBit-Kette - flow control zwingend notwendig sei.

"Zwingend Notwendig" ist eine eher seltsame Formulierung. Bremsen an
einem Auto sind auch nicht zwingend notwendig, solange man mit dem Auto
alleine über die Avus fährt. Es gibt aber unzweifelhaft einen Grund
warum die meisten Autos funktionierende Bremsen haben. Genauso ist es
mit flow control auf Layer II. Die werden das nicht aus spass an der
freud' erfunden und implementiert haben, sondern dafür gibt es bestimmt
einen Grund, oder?

In diesem Thread zb:

http://groups.google.de/group/novell.support.netware.5x.install-upgrade/browse_thread/thread/a8c4cd15dd7e275a/2ff371b422c8aa9a?lnk=st&q=flow+control+gigabit+100mbit+netware&rnum=1&hl=en#2ff371b422c8aa9a

wird dir Ursache nicht im möglicherweise fehlenden flow control gesucht.

Indirekt schon, weil Marcel mehrfach auf Firmware updates für die
Switche hinweist. Zwar erwähnt er nicht explizit Flow Control, aber
gerade das führt immer mal wieder zu Problemen.

Dieses hier:

http://ftp.cwi.nl/CWIreports/PNA/PNA-E0518.pdf

habe ich zwar nicht komplett gelesen und noch weniger verstanden

Kann ich nicht lesen, dabei schmiert mein Acrobat nachvollziehbar ab.

- aber
beim Überfliegen fand ich keinen Hinweis darauf, dass es Fälle gibt, wo
flow control auf Ethernet-Ebene für vernünftige Performance notwendig
sei.

Siehe oben. Wenn es nicht notwendig ist, warum gibt's dass dann?

Dagegen wird hier (und auch an anderen Stellen) erwähnt, dass das
Ziel von "hop-to-hop flow control" sei, /temporäre/ Traffic-Staus zu
beheben - also nicht prinzipiell unterschiedliche Geschwindigkeiten
zwischen Client und Server.

Von Prinzipiell hat ja auch niemand was geschrieben. Natürlich kann man
ohne flow-control auskommen, man muss nur die Buffer und die CPU in den
Switchen unendlich groß und schnell machen, dann braucht man auch kein
Flow-Control mehr. Dass das nicht geht liegt in der Natur der Sache.
Also wird es bei unterschiedlichen Geschwindigkeiten zwischen Server und
clients immer wieder Situationen geben, in denen der Switch die mit
1GB/s reinkommenden Daten nicht mehr zwischenspeichern kann (was er
logischerweise muss ,weil er sie ja nur 10 mal langsamer an den Client
abliefern kann), und dann *muss* der Switch entweder den schnelleren
Sender ausbremsen können, oder er muss Pakete wegschmeißen. Wann und wie
oft das passiert, hängt in erster Linie von der Größe der Puffer im
Switch ab. Es steht stark zu vermuten, dass in eurem Fall die Puffer in
den Ciscos um ein vielfaches Größer sind als in den kleinen Switchen.

Gerade bei mehreren Switchen im Pfad wird die Sache zudem
unübersichtlich, weil nicht ohne weiteres klar ist wer jetzt überhaupt
puffert, und wer wen ausbremsen muss, also ist es auch sehr schwer
rauszukriegen wo das schiefgeht.

Nehmen wir mal Dein Beispiel: Der Server sendet mit GB zum Cisco. Der
kann theoretisch die Daten "volle pulle" zum nächsten Switch
weiterleiten, da ja auch GB. Im idealfall wird er das "cut-through"
machen, also komplett ohne die Daten selber überhaupt zu puffern. Da
geht's aber schon los, er *kann* das so machen, er kann aber auch store
and forward machen, dann würde der schon puffern. Das hängt potentiell
von der Einstellung des Switches ab, aber eben auch von der aktuellen
Trafficsituation *auf dem ganzen* Switch.

Der nächste Switch muss jetzt die Daten die mit 1GB/s reinkommen auf
jeden Fall puffern, weil es ja nur mit 100mb/s weitergeht. Jetzt nehmen
wir einfach mal an, dessen Puffer laufen dabei voll, warum auch immer.
Mit funktionierender flow control, muss der Switch jetzt den Cisco per
Pause-Frame ausbremsen. Der hat jetzt selber wieder mindestens zwei
Möglichkeiten, darauf zu reagieren: Entweder er gibt die Bremse
(vorrausgestzt er "kapiert" das überhaupt), *direkt* an der Server
weiter, oder er fängt jetzt selber erstmal an auf dem Port zu puffern,
und wartet ob der andere Switch irgendwann wieder Daten haben will, die
er dann aus seinem eigenen Puffer bedient. Wenn das klappt, merkt der
Server von dem ganzen gar nichts.


Mit "in den Griff kriegen" meine ich natürlich ohne massive
Retransmissions und mit vernünftiger Geschwindigkeit.

Das kann TCP an der Stelle nicht mehr leisten. Bei Dir geht es um NCP,
also kopieren von Daten vom Server zum Client über TCP.
Der Client sagt dem Server, "ich möchte bitte die Datei XYZ lesen, und
ich selber kann z.B. 64kb Daten "auf einmal" annehmen (TCP Window). Der
Server knallt dann so schnell er kann, eben diese 64kb in ca. 1.5kb
großen Häppchen in Richtung Client, und zwar ohne auf *irgendeine*
Rückmeldung in der Zwischenzeit zu warten. Erst dann wartet der Server
auf ein "ACK" vom Client, idealerweise ein ACK, der da sagt "ich habe
alle 64kb erfolgreich bekommen, hau rein, mach weiter mit den nächsten
64kb". Wenn aber in der Mitte ein Switch ein Problem hatte die 64kb
komplett Zwichenzuspeichern, und nehmen wir auch mal an Flow Control hat
eben nicht funktioniert, dann kommt beim Client eben *nicht* alles an,
sondern nur Teile davon. Es ist nicht vorherzusagen welche Teile, es
kann genausogut nur ein Paket irgendwo in der Mitte fehlen, oder mehrere
in einer Reihe am Anfang oder am Ende. Alles ist da möglich.

Nehmen wir also mal an, irgendein Paket fehlt. Jetzt wartet der Client
erstmal. Und wartet. Und wartet. Und wartet. Und wartet. Schließlich
könnte das Paket ja doch noch kommen. Dann wartet er noch ein bisschen
(Du merkst vielleicht, dass ich darauf hinaus will, dass diese Wartezeit
im Vergleich zu den üblichen Laufzeiten von Daten in einem Netz *extrem*
lange ist, gerade bei TCP). Irendwann, nachdem in eben diesen Zeiten
gemessen eine Ewigkeit vergangen ist, schickt der Client jetzt ein ACK
an den Server, in dem sinngemäß drinsteht "ich hab' die ersten 32kb
bekommen, was ist denn jetzt mit dem Rest"? Daraufhin schickt der Server
freundlicherweise die fehlenden 32kb nochmal (hoffentlich zumindest. Je
nach konfiguration und Applikation, kann es sogar sein, dass der Server
die *gesamten* 64kb komplett neu schickt, was die übelste aller
Möglichkeiten wäre). Dann geht der ganze Spaß *unverändert* von vorne
los. TCP würde nur dann reagieren und z.b. das TCP Window verkeinern,
wenn der *Client* selber zu langsam wäre die Daten anzunehmen
(Stichwort: sliding Window). Dem ist aber eben nicht so, der Client
selber könnte ja viel schneller.


Bei den Netzwerkkarten ist es z.B. laut Monitor deaktiviert - vielleicht
ist ja das das Problem.

Sehr gut möglich. Dass es dann mit den Ciscos alleine trotzdem
funktioniert, mag problemlos in dem größeren Puffer der Ciscos liegen,
sodass in dem Fall Flow Control zwischen Server und Cisco schlicht gar
nicht gebraucht wird.

Mir ist die Sache zwar nicht wirklich klar (Ethernet flow control vs.
TCP flow control), aber ich hab' jetzt immerhin ein paar Ansatzpunkte...

Es gibt genau ein Scenario mit dem TCP überhaupt nicht umgehen kann, und
das ist die Kombination von Windowing und Paketverlust in einem Lan,
also wenn es um wirklich hohe Geschwindigkeiten geht. Das ist z.B. der
Grund, warum Netzwerkprobleme mit IPX erst auffallen wenn sie wirklich
*massiv* sind, wogegen TCP in dem Fall nur noch vor sich hin kriecht.

Natürlich kann man theoretisch die Auswirkungen dieser Probleme auch auf
TCP Ebene mindern. Wenn man z.B. TCP dazu zwingt, jedes einzelne Paket
zu bestätigen (Delayed ACK anybody?), löst sich das Problem sofort in
Luft auf, weil der Server ja jetzt immer auf eine Antwort vom Client
wartet bevor er die nächsten Daten aufs Kabel kippt. Dummerweise geht
dabei die allgemeine Performance logischerweise in die Grütze, weil sich
die Anzahl der Pakete auf dem Kabel für die gleiche übertragene
Datenmenge nahezu verdoppelt. Und auch in einem LAN haben Pakete nunmal
Laufzeiten. *Wenn* also ein Netz bei TCP streams ohne delayed acks
schneller ist als mit, ist das Netz kaputt, und anstatt das ganze Netz
auszubremsen, sollte man lieber das kaputte Netz reparieren.

CU,
--
Massimo Rosen
Novell Support Connection Sysop
No emails please!
http://www.cfc-it.de
.

Relevant Pages

  • suspect bug in vge(4)
    ... The high-level view of the problem is that the client seems to stall ... HTTPS server. ... not only printed for TLS/SSL issues but simply also for broken TCP ... To me it sounds like a broken implementation of hardware generated ...
    (freebsd-current)
  • Re: Log Out Issues
    ... UDP is the way to go for internet games. ... Apparently the extra overhead in TCP can cause a lot more lag in your game, ... >> Lets say the client sends a log out request to the server reliably. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Log Out Issues
    ... your perormance may be worse than TCP. ... would be if your protocol anticipates packet loss and does not ... >>> Lets say the client sends a log out request to the server reliably. ...
    (microsoft.public.win32.programmer.networks)
  • Re: [2.6.24.3][net] bug: TCP 3rd handshake abnormal timeouts
    ... server via TCP and non-persistent connections and all application level ... "Sometimes" when establishing a TCP connection to the server, ... Here is a simplified version of what _both_ the server and the client ...
    (Linux-Kernel)
  • Re: [2.6.24.3][net] bug: TCP 3rd handshake abnormal timeouts
    ... server via TCP and non-persistent connections and all application level ... "Sometimes" when establishing a TCP connection to the server, ... Here is a simplified version of what _both_ the server and the client ...
    (Linux-Kernel)