14
FlowControll bei 10Gbs Server Uplink und 1Gbs Clients aktivieren?
Hallo, hoffe hier kann mir jemand auf meine Frage eine Antwort geben. Und zwar -Wenn man ein 48 Port Switch hat, mit einem 10Gbs Uplink woran wiederrum der Server mit seiner 10Gbs Netzwerkkarte hängt, dazu noch etliche Client PCs die mit 1Gbs verbunden sind mit den restlichen Switchports, dabei aber auch noch ein paar uralt Terminals hängen die nur mit 10Mbits verbunden sind, dann noch ein WLan AP wo ein paar Geräte teilweise nur mit 22Mbit/s verbunden sind
-sollte man da dieses Flow Control auf dem Switch aktivieren?
Ich meine - der Server weiß ja nix davon, dass die Clients nur mit 1Gbs angebunden sind, und wenn der Server Daten an die CLients verteilt, haut er die doch erstmal mit 10G raus, was der Client nicht verarbeiten kann und der Switch wird sofort einen Buffer Overflow haben und ein großteil der Pakete werden gedropt...
wie verhält es sich in so einer Umgebung? Flowcontroll tunlichst einschalten, oder lieber auslassen?
Der Server spannt noch ein paar VLANs auf und gibt diese ebenfalls weiter über den 10Gbs Uplink port an den switch (Trunk port) - FlowControll stoppt doch das Phy Interface des Servers - nicht das virtuelle, oder?
-sollte man da dieses Flow Control auf dem Switch aktivieren?
Ich meine - der Server weiß ja nix davon, dass die Clients nur mit 1Gbs angebunden sind, und wenn der Server Daten an die CLients verteilt, haut er die doch erstmal mit 10G raus, was der Client nicht verarbeiten kann und der Switch wird sofort einen Buffer Overflow haben und ein großteil der Pakete werden gedropt...
wie verhält es sich in so einer Umgebung? Flowcontroll tunlichst einschalten, oder lieber auslassen?
Der Server spannt noch ein paar VLANs auf und gibt diese ebenfalls weiter über den 10Gbs Uplink port an den switch (Trunk port) - FlowControll stoppt doch das Phy Interface des Servers - nicht das virtuelle, oder?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 563749
Url: https://administrator.de/contentid/563749
Ausgedruckt am: 24.11.2024 um 18:11 Uhr
14 Kommentare
Neuester Kommentar
Hallo erstmal...
wenn ich mich richtig erinnere, machen die beiden Endgeräte miteinander aus, mit welcher Rate Daten transferiert werden können...das wird im ersten Paket übermittelt, bzw. die Antwort auf die erste Anfrage enthält, mit welcher Geschwindigkeit Daten empfangen werden können.
Wenn also der Server was zu liefern hat...dann fragt der erstmal nach dem Empfänger, ob der überhaupt da ist. Wenn der Empfänger da ist, dann meldet der dem Server, dass er da ist und ob er bereit ist und mit welcher Geschwindigkeit von ihm Daten empfangen werden können.
Danach richtet sich der Server dann und schickt die Daten entsprechend raus.
Dass dein Switch nen 10Gbs uplink hat...ja, das ist schön, das interessiert den Client mit der 1Gbs Netzwerkkarte aber wenig.
Auch auf die Gefahr hin, dass ich mich jetzt schrecklich blamiere....ich meine das so mal gelernt zu haben...ihr dürft mich gerne berichtigen und euren Spott über mich ausschütten... :P
wenn ich mich richtig erinnere, machen die beiden Endgeräte miteinander aus, mit welcher Rate Daten transferiert werden können...das wird im ersten Paket übermittelt, bzw. die Antwort auf die erste Anfrage enthält, mit welcher Geschwindigkeit Daten empfangen werden können.
Wenn also der Server was zu liefern hat...dann fragt der erstmal nach dem Empfänger, ob der überhaupt da ist. Wenn der Empfänger da ist, dann meldet der dem Server, dass er da ist und ob er bereit ist und mit welcher Geschwindigkeit von ihm Daten empfangen werden können.
Danach richtet sich der Server dann und schickt die Daten entsprechend raus.
Dass dein Switch nen 10Gbs uplink hat...ja, das ist schön, das interessiert den Client mit der 1Gbs Netzwerkkarte aber wenig.
Auch auf die Gefahr hin, dass ich mich jetzt schrecklich blamiere....ich meine das so mal gelernt zu haben...ihr dürft mich gerne berichtigen und euren Spott über mich ausschütten... :P
Hmm...dieses Handover kenne ich nur bei der FAX übertragung :D aber wenn dem so wäre -warum gibts dann überhaupt diese Flusskontrolle/steuerung?
FlowControl schalte ich grundsätzlich inzwischen auf allen Seiten aus. Das bringt inzwischen mehr Probleme als es löst.
Einziger Einsatzzweck war zuletzt, Überlastungen aufgrund zu hoher Datenrate zu verhindern. Das können die Protokolle auf den Layern darüber (TCP, UDP, DCCP) aber allesamt besser als das Ethernet-Flowcontrol.
Bei TCP z.B. werden Receive-Windows zwischen den Gegenstellen ausgehandelt, die dann während der Datenübertragung vergrößert oder verkleinert werden. Gehen z.B. aufgrund von zu hoher Datenrate Pakete verloren, die nicht mehr durch den Link passen, wird das Fenster verkleinert und so die Datenrate reduziert. En Detail bin ich in diesem Post mal darauf eingegangen.
Falls du noch irgendwo Halbduplex-Verbindungen betreibst (z.B. ziemlich alte Richtfunk- oder Glasfaser-Anschlüsse mit nur einer Faser), kann an diesen Stellen Flowcontrol noch wichtig sein, sonst würde ich das inzwischen überall abschalten.
PAUSE-Frames führen an vielen Switches dazu, dass die Datenübertragung auf dem gesamten Port gedrosselt resp. pausiert wird und nicht nur selektiv für einzelne Datenströme (wie es bei TCP wäre). Das macht sich dann als Packetloss im Netzwerk bemerkbar und das ist z.B. bei VoIP-Telefonie ständig als Aussetzer oder Knacken hörbar.
Für den Fall, dass du das Receive-Window von TCP meinst: Das ist quasi so, nur wird nicht die Datenrate sondern die Größe des Receive-Buffers des Empfängers ausgehandelt. Das hat zwar implizit Auswirkungen auf die Geschwindigkeit - aber die Geschwindigkeit selbst wird nicht ausgehandelt, weil die Gegenstellen selbst ja auch nicht wissen, wie hoch die Datenrate untereinander ist.
Für UDP gibt es keine standardisierten Verfahren, aber die meisten Anwendungen, die UDP benutzen, haben entweder einen Steuerkanal mit dem sie sich austauschen, wie viel Packetloss es gab (was dann auf überlastete Wege hindeutet) oder es werden direkt Protokolle wie DCCP genutzt.
*schütt...*
Einziger Einsatzzweck war zuletzt, Überlastungen aufgrund zu hoher Datenrate zu verhindern. Das können die Protokolle auf den Layern darüber (TCP, UDP, DCCP) aber allesamt besser als das Ethernet-Flowcontrol.
Bei TCP z.B. werden Receive-Windows zwischen den Gegenstellen ausgehandelt, die dann während der Datenübertragung vergrößert oder verkleinert werden. Gehen z.B. aufgrund von zu hoher Datenrate Pakete verloren, die nicht mehr durch den Link passen, wird das Fenster verkleinert und so die Datenrate reduziert. En Detail bin ich in diesem Post mal darauf eingegangen.
Falls du noch irgendwo Halbduplex-Verbindungen betreibst (z.B. ziemlich alte Richtfunk- oder Glasfaser-Anschlüsse mit nur einer Faser), kann an diesen Stellen Flowcontrol noch wichtig sein, sonst würde ich das inzwischen überall abschalten.
PAUSE-Frames führen an vielen Switches dazu, dass die Datenübertragung auf dem gesamten Port gedrosselt resp. pausiert wird und nicht nur selektiv für einzelne Datenströme (wie es bei TCP wäre). Das macht sich dann als Packetloss im Netzwerk bemerkbar und das ist z.B. bei VoIP-Telefonie ständig als Aussetzer oder Knacken hörbar.
Zitat von @Uschade:
wenn ich mich richtig erinnere, machen die beiden Endgeräte miteinander aus, mit welcher Rate Daten transferiert werden können...das wird im ersten Paket übermittelt, bzw. die Antwort auf die erste Anfrage enthält, mit welcher Geschwindigkeit Daten empfangen werden können.
wenn ich mich richtig erinnere, machen die beiden Endgeräte miteinander aus, mit welcher Rate Daten transferiert werden können...das wird im ersten Paket übermittelt, bzw. die Antwort auf die erste Anfrage enthält, mit welcher Geschwindigkeit Daten empfangen werden können.
Für den Fall, dass du das Receive-Window von TCP meinst: Das ist quasi so, nur wird nicht die Datenrate sondern die Größe des Receive-Buffers des Empfängers ausgehandelt. Das hat zwar implizit Auswirkungen auf die Geschwindigkeit - aber die Geschwindigkeit selbst wird nicht ausgehandelt, weil die Gegenstellen selbst ja auch nicht wissen, wie hoch die Datenrate untereinander ist.
Für UDP gibt es keine standardisierten Verfahren, aber die meisten Anwendungen, die UDP benutzen, haben entweder einen Steuerkanal mit dem sie sich austauschen, wie viel Packetloss es gab (was dann auf überlastete Wege hindeutet) oder es werden direkt Protokolle wie DCCP genutzt.
Auch auf die Gefahr hin, dass ich mich jetzt schrecklich blamiere....ich meine das so mal gelernt zu haben...ihr dürft mich gerne berichtigen und euren Spott über mich ausschütten... :P
*schütt...*
Ist der Uplink ausgelastet? Würde mich wundern.
Drr Switch ist ein Non-Blocking Switch?
Drr Switch ist ein Non-Blocking Switch?
Der Uplink Port langweilt sich, weil der ja mit 10Gbs unterwegs ist :D
ich wusste halt nur nicht, wie es sich mit den langsamen clients verhält, die eben nur mit 1Gbs oder gar nur 100Mbs verbunden sind. Halfduplex gibts nichtmehr im Netzwerk
Switch ist ein Unifi USW Pro 48 POE
ich wusste halt nur nicht, wie es sich mit den langsamen clients verhält, die eben nur mit 1Gbs oder gar nur 100Mbs verbunden sind. Halfduplex gibts nichtmehr im Netzwerk
Switch ist ein Unifi USW Pro 48 POE
Es ist ein non-blocking swzitch, von daher ist deine Angst unbegründet.
non blocking heist doch, das er mehr Switchleistung auf dem Backplane hat, als die Ports in summe haben und das mal 2 wegen FullDuplex, oder? der Unifi ist ja mit 88Gbs Nonblocking leistung angegeben..er hat aber ja schon 48 Ports mit je 1Gbs, und dann noch 4 Ports mit 10Gbs...da müsste der switch ja eigentlich mehr als 176Gbs haben - aber da ist der nur als Total Switching capacity angegeben - nicht aber als Non Blicking ? *confused*
Nicht alles zusammen Würfeln.
88 Gbs ist der non-blocking throughput und die Backplane hat 176 Gbs Kapazität und ca. 130 Mps forwarding Leistung bei welcher Paketgröße auch immer.
Für ein Switch mit 48 Ports zu 1 Gbit und ein paar SFP+ also völlig in Ordnung für alle nicht low latency Anwendungsszenarien.
"Full Duplex" gibt es im dem Sinne ab Gigabit aufwärts nicht mehr, weil der Port immer in dem Modus ist. 10 und 100 Mbit können im Full Duplex Dein, müssen aber nicht.
88 Gbs ist der non-blocking throughput und die Backplane hat 176 Gbs Kapazität und ca. 130 Mps forwarding Leistung bei welcher Paketgröße auch immer.
Für ein Switch mit 48 Ports zu 1 Gbit und ein paar SFP+ also völlig in Ordnung für alle nicht low latency Anwendungsszenarien.
"Full Duplex" gibt es im dem Sinne ab Gigabit aufwärts nicht mehr, weil der Port immer in dem Modus ist. 10 und 100 Mbit können im Full Duplex Dein, müssen aber nicht.
Ahh ok, besten dank 
also du bist auch der meinung - FlowControl ausschalten?
Ich dächte mal was gelesen zu haben, dass man das bei 10Gbs aktivieren sollte
aber per Default ist es selbst beim 10G Model, dem US 16XG ausgeschaltet...die werden schon wissen warum...hoffe ich
Was ist an switchen für LowLatency anders?
also du bist auch der meinung - FlowControl ausschalten?
Ich dächte mal was gelesen zu haben, dass man das bei 10Gbs aktivieren sollte
aber per Default ist es selbst beim 10G Model, dem US 16XG ausgeschaltet...die werden schon wissen warum...hoffe ichWas ist an switchen für LowLatency anders?
Hast du den einen Grund für Flow Control? Hast du was laufen, was keinen Verlust (Loss) verkraften würde?
Low Latency Switches sieht man bei iSCSI oder FCoE öfters. Außerdem addieren diese Switches keine nennenswerten Latenzen wenn sie hart arbeiten müssen und eine ungünstige Anzahl und Größenverteilung von Paketen haben.
Die Hersteller geben für "normale" Switches gern Forward-Leistung und Latenzen an, die mit unrealistischen Paketgrößen und Mischungen einhergehen.
Low Latency Switches sieht man bei iSCSI oder FCoE öfters. Außerdem addieren diese Switches keine nennenswerten Latenzen wenn sie hart arbeiten müssen und eine ungünstige Anzahl und Größenverteilung von Paketen haben.
Die Hersteller geben für "normale" Switches gern Forward-Leistung und Latenzen an, die mit unrealistischen Paketgrößen und Mischungen einhergehen.
VOIP Telefone...ich glaube die laufen über UDP...sonst würde mir jetzt nichts einfallen was noch als LowLatency aplikation läuft. Kann sein dass es noch irgendwas gibt - aber da könnte ich doch explizit für den Port und dem Zielport ein eigenes VLAN daraus machen, sodass die nicht gestört werden...oder würde das da garnix bringen?
VoIP ist kein Low Latency Anwendung in diesem Sinne.
Stell dir Mal vor, du hast ein FC-SAN mit Flash oder SSDs und dein Switch schwankt bei sich verändernden Throughput... Das wäre kontraproduktiv.
Stell dir Mal vor, du hast ein FC-SAN mit Flash oder SSDs und dein Switch schwankt bei sich verändernden Throughput... Das wäre kontraproduktiv.
Ach sowas meinst du... Gut, wir haben zwar auch ein San, das ist aber über FC direkt mit dem Server gekoppelt, also nicht über iscsi.
Aber VoIP nutzt doch UDP als Protokoll, und wenn es da Paket Verluste gibt, wird man das doch hören denke ich
Aber VoIP nutzt doch UDP als Protokoll, und wenn es da Paket Verluste gibt, wird man das doch hören denke ich
Es muss im Falle von VoIP schon eine gewisse Anzahl an Paketen verloren gehen, dass man das hört... Im LAN passiert das sehr selten und wenn, dann ist einiges im Argen.
