7
Cisco SG500X - welche Übertragungsraten sind realistisch?
Hallo,
ich habe mir wie hier
Vorschläge für Backbone ca. 150 Clients 1GB
bereits einmal diskutiert, nun 3 von den SG500X Small Business Switchen von Cisco zugelegt.
Nun habe ich erst einmal 2 Switche in als "Nativ Stack" in Betrieb genommen, einen meiner ESX Server über 8 x 1 GB Ports mit CAT6 Leitungen direk an
ein LAG (am Switch ohne LACP, am Server Teaming mit IP HASH ) angeschlossen. Gleichzeitig hängt noch meine WS und ein physicher Server direkt mit 1 GB/s an
einem der SG500X.
Die alten HP 1810G Switche habe ich über ein LACP LAG über 2x1GB/s Ports verbunden.
An den Cisco Switchen habe ich bis auf die LAG'S sonst nur die Grundeinstellungen vorgenommen und die neueste Firmware 1.4.0.8 eingespielt.
Bei meinen Tests die ich mit jperf (iperf) gemacht habe, bekomme ich nur um die 250 Mbit/s - sowohl zum physischen als auch in die virtuellen Server -
übertragen.
Da hatte ich mir schon etwas mehr erhofft, dass habe ich mit den HP Switchen auch geschafft. Wenn man bedenkt, dass die Cisco Geräte schon allein von
der Ausstattung (Speicher, Prozessor) mehr können hatte ich mit 600 - 800Mbyte/s schon gerechnet.
Eigentlch hoffe ich nur, dass ich etwas falsch konfiguiert habe oder noch nicht richtig (standard) eingestelllt ist.
Deshalb wollte ich mal wissen, was kann man von den Switchen realistisch erwarten?
ich habe mir wie hier
Vorschläge für Backbone ca. 150 Clients 1GB
bereits einmal diskutiert, nun 3 von den SG500X Small Business Switchen von Cisco zugelegt.
Nun habe ich erst einmal 2 Switche in als "Nativ Stack" in Betrieb genommen, einen meiner ESX Server über 8 x 1 GB Ports mit CAT6 Leitungen direk an
ein LAG (am Switch ohne LACP, am Server Teaming mit IP HASH ) angeschlossen. Gleichzeitig hängt noch meine WS und ein physicher Server direkt mit 1 GB/s an
einem der SG500X.
Die alten HP 1810G Switche habe ich über ein LACP LAG über 2x1GB/s Ports verbunden.
An den Cisco Switchen habe ich bis auf die LAG'S sonst nur die Grundeinstellungen vorgenommen und die neueste Firmware 1.4.0.8 eingespielt.
Bei meinen Tests die ich mit jperf (iperf) gemacht habe, bekomme ich nur um die 250 Mbit/s - sowohl zum physischen als auch in die virtuellen Server -
übertragen.
Da hatte ich mir schon etwas mehr erhofft, dass habe ich mit den HP Switchen auch geschafft. Wenn man bedenkt, dass die Cisco Geräte schon allein von
der Ausstattung (Speicher, Prozessor) mehr können hatte ich mit 600 - 800Mbyte/s schon gerechnet.
Eigentlch hoffe ich nur, dass ich etwas falsch konfiguiert habe oder noch nicht richtig (standard) eingestelllt ist.
Deshalb wollte ich mal wissen, was kann man von den Switchen realistisch erwarten?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 253797
Url: https://administrator.de/forum/cisco-sg500x-welche-uebertragungsraten-sind-realistisch-253797.html
Ausgedruckt am: 12.04.2025 um 15:04 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
Frage: mit welchem Betriebssystem hast du getestet?
Wir hatten mal das gleiche Problem, getestet wurde mit Win7-Clients und iPerf. Egal wie wir die Switches geschaltet haben, mehr als 230-250 MBit/s ging nie.
Auch als wir die Clients ganz ohne Switches direkt verkabelt haben...
Dann mit Linux-Clients mit Intel-Netzwerkkarten getestet und schon zeigte iperf auf Gigabit-Leitungen 990MBit/s...
Unser Schluss: iperf für Windows ist für die Tonne.
netio hat unter Windows realistischere Werte angezeigt.
Gruß
Frage: mit welchem Betriebssystem hast du getestet?
Wir hatten mal das gleiche Problem, getestet wurde mit Win7-Clients und iPerf. Egal wie wir die Switches geschaltet haben, mehr als 230-250 MBit/s ging nie.
Auch als wir die Clients ganz ohne Switches direkt verkabelt haben...
Dann mit Linux-Clients mit Intel-Netzwerkkarten getestet und schon zeigte iperf auf Gigabit-Leitungen 990MBit/s...
Unser Schluss: iperf für Windows ist für die Tonne.
netio hat unter Windows realistischere Werte angezeigt.
Gruß
1
Hallo DerSchorsch,
das ist auch mein Setup. Ich teste morgen mit netio.
das ist auch mein Setup. Ich teste morgen mit netio.
Also meine schlechten Übertragungsraten hatten 2 Ursachen:
1. Das Tool iperf was ich zum Ermitteln der Transferraten verwendet habe.
2. Der Netzwerkadapter meines Rechners
Mit netio und einem Windows 7 Rechner (Dell Optiplex 380 - Broadcom NetLink Adapter) komme ich auf über 100MByte/s. Mit meinem Notebook komme ich auch mit netio (am selben Netzwerkport, Kabel etc) kaum über 40MByte/s. Obwohl ich schon ein HP ProBook 6560b habe, von dem ich eigentlich etwas mehr erwartet hätte. Aber die NIC's in den portablen Geräten sind wohl alle eher von bescheidener Qualität.
Jedenfalls bin ich erleichtert, dass es nicht ein generelles Problem gibt.
1. Das Tool iperf was ich zum Ermitteln der Transferraten verwendet habe.
2. Der Netzwerkadapter meines Rechners
Mit netio und einem Windows 7 Rechner (Dell Optiplex 380 - Broadcom NetLink Adapter) komme ich auf über 100MByte/s. Mit meinem Notebook komme ich auch mit netio (am selben Netzwerkport, Kabel etc) kaum über 40MByte/s. Obwohl ich schon ein HP ProBook 6560b habe, von dem ich eigentlich etwas mehr erwartet hätte. Aber die NIC's in den portablen Geräten sind wohl alle eher von bescheidener Qualität.
Jedenfalls bin ich erleichtert, dass es nicht ein generelles Problem gibt.
Teste erstmal den Durchsatz auf einem einzigen Switch von Port zu Port ohne über den Stack Link zu gehen.
Dort sollte mit NetIO mindestens annähernd Wirespeed rasukommen.
Achte daraf das am Switch und Test Client Ethernet Flowcontrol ausgeschaltet ist !
Oft werden dort billige Chipsätze von Realtek usw. verwendet die sehr billig, da dumm, sind und deshalb einen Großteil des internen L2 Paket Handlings der Rechner CPU aufbürden satt es lokal im Chipsatz zu verarbeiten. Der gemeine Blödmarkt Kunde will ja erstmal kein Geld ausgeben und deshalb wird bekanntlich an jeder Schraube beim Hersteller geknausert im billigen Consumer Bereich. You get what you payed for....!
Das kostet eine Menge Performance und Delay. Oft kitzeln die Original Chipsatz Treiber noch etwas mehr raus als die vom Hersteller oder die Windows Treiber aber Wunder darfst du da nicht erwarten.
Ohne zu wissen welche Chipsätze dort verbaut sind können wir also auch nur wild im freien Fall raten.
Mit Intel, Marvell oder Broadcam Ethernet Chips sollte es diese Engpässe aber nicht geben. Einen aktuellen Intel Treiber (nicht HP) vorausgesetzt !
Dort sollte mit NetIO mindestens annähernd Wirespeed rasukommen.
Achte daraf das am Switch und Test Client Ethernet Flowcontrol ausgeschaltet ist !
komme ich auf über 100MByte/s
Das zeigt ja schon klar das es NICHT an den Switches liegt...was auch verwunderlich wäre. Entspricht mit 800Mbit/s annähernd Wirespeed.Obwohl ich schon ein HP ProBook 6560b habe, von dem ich eigentlich etwas mehr erwartet hätte
Zeigt das du nicht auf die Details achtest. Der Hersteller der HW ist völlig irrelevant. Es kommt einzig und allein auf den Ethernet Chipsatz an was dort verbaut ist.Oft werden dort billige Chipsätze von Realtek usw. verwendet die sehr billig, da dumm, sind und deshalb einen Großteil des internen L2 Paket Handlings der Rechner CPU aufbürden satt es lokal im Chipsatz zu verarbeiten. Der gemeine Blödmarkt Kunde will ja erstmal kein Geld ausgeben und deshalb wird bekanntlich an jeder Schraube beim Hersteller geknausert im billigen Consumer Bereich. You get what you payed for....!
Das kostet eine Menge Performance und Delay. Oft kitzeln die Original Chipsatz Treiber noch etwas mehr raus als die vom Hersteller oder die Windows Treiber aber Wunder darfst du da nicht erwarten.
Ohne zu wissen welche Chipsätze dort verbaut sind können wir also auch nur wild im freien Fall raten.
Mit Intel, Marvell oder Broadcam Ethernet Chips sollte es diese Engpässe aber nicht geben. Einen aktuellen Intel Treiber (nicht HP) vorausgesetzt !
Zitat von @aqui:
Teste erstmal den Durchsatz auf einem einzigen Switch von Port zu Port ohne über den Stack Link zu gehen.
Dort sollte mit NetIO mindestens annähernd Wirespeed rasukommen.
Teste erstmal den Durchsatz auf einem einzigen Switch von Port zu Port ohne über den Stack Link zu gehen.
Dort sollte mit NetIO mindestens annähernd Wirespeed rasukommen.
Genau so habe ich getestet.
Achte daraf das am Switch und Test Client Ethernet Flowcontrol ausgeschaltet ist !
Folwcontrol ist und war an. Ich könnte noch einmal ohne Testen. Aber warum? Ich will doch reale Ergebnisse und Flowcontrol sollte doch eingeschaltet sein?
Das zeigt ja schon klar das es NICHT an den Switches liegt...was auch verwunderlich wäre. Entspricht mit 800Mbit/s
annähernd Wirespeed.
annähernd Wirespeed.
Ja teilweise sogar höher 118 MByte/s. Das ist ja auch völlig OK für die Preisklasse der Switche, nur die vorher mit iperf gemessenen 250 Mbit/s haben mich verwirrt.
> Obwohl ich schon ein HP ProBook 6560b habe, von dem ich eigentlich etwas mehr erwartet hätte
Zeigt das du nicht auf die Details achtest. Der Hersteller der HW ist völlig irrelevant. Es kommt einzig und allein auf den
Ethernet Chipsatz an was dort verbaut ist.
Zeigt das du nicht auf die Details achtest. Der Hersteller der HW ist völlig irrelevant. Es kommt einzig und allein auf den
Ethernet Chipsatz an was dort verbaut ist.
Nein, das zeigt das Du Dich in der PC-Welt nicht so gut auskennst. Jeder der Ahnung von Hardware hat, weiß dass das ProBook ein Business Laptop mit gehobener Ausstattung ist. Und hier ist eine "Intel(R) 82579V" verbaut. Das sollte eigentlich schon einer der besseren Laptop NIC sein.
Deshalb meine Enttäuschung, dass hier nur 40 MByte/s mit netio herauskommen. Ich habe vorher nochmal den neuesten Originaltreiber von der Intelseite installiert. Dann habe ich mit
netsh winsock reset
netsh int ip reset
die IP-Einstellungen resettet.
Ich hätte mit einem Billigheimer aus dem Supermarkt niemals einen Performancetest durchgeführt.
Mit Intel, Marvell oder Broadcam Ethernet Chips sollte es diese Engpässe aber nicht geben. Einen aktuellen Intel Treiber (nicht HP) vorausgesetzt !
Und das verstehe ich eben nicht, da ich ja einen Intel NIC habe. Der Broadcom NIC der PC schaffte ja fast die 3 fache Rate am gleichen Port!
Vielleicht ist an den Einstellungen der Karte etwas verstellt, hier müsste ich noch einmal auf Standard gehen.
Oder besser ich boote mal ein Linux Live System und messe damit.
Asche auf mein Haupt. Und Entschuldigung an HP und Intel.
Ich habe gerade noch einmal den NIC-Treiber auf meinem Notebook komplett deinstalliert und neu installiert. Eine neue Messung mit netio vorgenommen und immer noch die bescheidenen Messwerte so um die 30 MByte/s bekommen. Dabei hatte ich den Task-Manager geöffnet und gesehen, dass bei der Messung der Systemdienst sich mit 25% CPU Last eingeklinkt hat. Das war mir suspekt.
Dann habe ich noch einmal die Adapter-Eigenschaften geprüft und gesehen, dass da ein Protokoll "AVM-VPN Driver" gebunden ist. Da fiel mir ein, dass ich für einen Kollegen mal diese Fritz VPN-Software für den Zugriff auf sein Home-Office testen sollte.
Nach dem Test habe ich wohl vergessen, die Software wieder zu deinstallieren.
Also habe ich kurzer Hand die Bindung des Protokolls vom Adapter gelöst (Haken raus) und noch einmal gemessen.
Und siehe da:
TCP connection established.
Packet size 1k bytes: 73.88 MByte/s Tx, 66.91 MByte/s Rx.
Packet size 2k bytes: 103.77 MByte/s Tx, 67.90 MByte/s Rx.
Packet size 4k bytes: 111.68 MByte/s Tx, 86.08 MByte/s Rx.
Packet size 8k bytes: 111.28 MByte/s Tx, 89.32 MByte/s Rx.
Packet size 16k bytes: 111.73 MByte/s Tx, 92.15 MByte/s Rx.
Packet size 32k bytes: 111.92 MByte/s Tx, 91.17 MByte/s Rx.
Done.
Das Problem sitzt halt meistens zwischen Bildschirm und Stuhllehne.
Also wäre auch dieses Problem gelöst.
Ich habe gerade noch einmal den NIC-Treiber auf meinem Notebook komplett deinstalliert und neu installiert. Eine neue Messung mit netio vorgenommen und immer noch die bescheidenen Messwerte so um die 30 MByte/s bekommen. Dabei hatte ich den Task-Manager geöffnet und gesehen, dass bei der Messung der Systemdienst sich mit 25% CPU Last eingeklinkt hat. Das war mir suspekt.
Dann habe ich noch einmal die Adapter-Eigenschaften geprüft und gesehen, dass da ein Protokoll "AVM-VPN Driver" gebunden ist. Da fiel mir ein, dass ich für einen Kollegen mal diese Fritz VPN-Software für den Zugriff auf sein Home-Office testen sollte.
Nach dem Test habe ich wohl vergessen, die Software wieder zu deinstallieren.
Also habe ich kurzer Hand die Bindung des Protokolls vom Adapter gelöst (Haken raus) und noch einmal gemessen.
Und siehe da:
TCP connection established.
Packet size 1k bytes: 73.88 MByte/s Tx, 66.91 MByte/s Rx.
Packet size 2k bytes: 103.77 MByte/s Tx, 67.90 MByte/s Rx.
Packet size 4k bytes: 111.68 MByte/s Tx, 86.08 MByte/s Rx.
Packet size 8k bytes: 111.28 MByte/s Tx, 89.32 MByte/s Rx.
Packet size 16k bytes: 111.73 MByte/s Tx, 92.15 MByte/s Rx.
Packet size 32k bytes: 111.92 MByte/s Tx, 91.17 MByte/s Rx.
Done.
Das Problem sitzt halt meistens zwischen Bildschirm und Stuhllehne.
Also wäre auch dieses Problem gelöst.
Folwcontrol ist und war an.
Böses Faul ! Ist in einem Netzwerk generell immer abgeschaltet...oder sollte so sein ! Jeder der Ahnung von Hardware hat, weiß dass das ProBook ein Business Laptop mit gehobener Ausstattung ist. Und hier ist eine "Intel(R) 82579V" verbaut. Das sollte eigentlich schon einer der besseren Laptop NIC sein.
Ahem...genau DAS war ja mit dem Hinweis auf billige Chips genau gemeint. Sorry, aber du kannst nicht erwarten das Forumsteilnehmer wissen in welchem aller weltweit verfügbaren Laptops welcher Chipsatz verbaut ist.Hättest DU den Hinweis auf Intel gegeben wäre diese Diskussion obsolet gewesen !
Wenn der Intel Chip lahmt liegts zu 98% am Treiber der vermutlich nicht der direkte von Intel ist.
Oder eben am aktivierten Flow Control ?!
Aber gut das du den pöhsen Puhmann ja nun gefunden hast !
