30
Netzwerkgeschwindigkeit mit Windows 7 Clients langsam
Hallo,
ich habe ein Problem mit der Netzwerkgeschwindigkeit in unserer Firma. So wie es aussieht ist die Geschwindigkeit bei Windows 7 Rechnern um einiges langsamer als es sein sollte.
Als Server wurde Iperf auf Windows Storage Server 2012 R2, Ubuntu Server, IPCop und Synology NAS gestartet.
Clients:
Es sind unterschiedliche Rechner zum Einsatz gekommen von einer Workstation bis zum Laptop und als Betriebssystem Windows 7, Windows 10, Ubuntu Desktop und aus lauter Verzweiflung auch einen Rechner mit Windows XP.
Es wurde mit aktivierter und deaktivierter Firewall getestet.
Die Netze sind im Moment nicht voneinander getrennt. Was ich eigentlich ändern wollte und im Zuge dieser Arbeit auf das Problem aufmerksam wurde.
Rechner wurden auf unterschiedlichen Netzwerkanschlüssen angesteckt.
TCP Autotuning wurde auf Windows 7 Clients auch testweise deaktiviert.
Als Switch kommen HP 2530-24GS und Dlink DGS-3100 zum Einsatz.
Die ermittelten Wert wurden auf einen der oben genannten Server ermittelt. Die anderen Server sind minimal abweichend.
Windows 10 64bit: ~ 942 Mbits/sec
Windows 7 64bit: ~ 278 Mbits/sec
Windows XP 32bit: ~253 Mbits/sec
Ubuntu 12.04 LTS 32bit: ~896 Mbits/sec
Ubuntu 12.04 LTS 64bit: ~934 Mbits/sec
Weitere Tests quer durch:
Server: Windows 7 64bit
Client: Windows 10 64bit
Geschwindigkeit: 811 Mbits/sec
Die gleichen Rechner nur Client und Server vertauscht
Geschwindigkeit: 466 Mbits/sec
Bei diesem Ergebnis bin ich gerade etwas überrascht. Hätte mit um die 280 gerechnet.
Server: Windows 10 64bit
Client: Windows Storage Server 2012 R2
Geschwindigkeit: 873 Mbits/sec
Server: Windows 7 64bit
Client: Windows Storage Server 2012 R2
Geschwindigkeit: 739 Mbits/sec
Server: Windows Storage Server 2012 R2
Client: Windows 10 64bit
Geschwindigkeit: 921 Mbits/sec
Server: Windows Storage Server 2012 R2
Client: Windows 7 64bit
Geschwindigkeit: 256 Mbits/sec
Server: IPCop
Client: Windows 10 64bit
Geschwindigkeit: 915 Mbits/sec
Server: IPCop
Client: Windows Storage Server 2012 R2
Geschwindigkeit: 825 Mbits/sec
Server: IPCop
Client: Windows 7 64bit
Geschwindigkeit: 260 Mbits/sec
Server: Windows 7 64bit
Client: Windows 7 64bit
Geschwindigkeit: 289 Mbits/sec
Bei den beiden Windows 7 PCs wurde Client/Server vertauscht
Geschwindigkeit: 257 Mbits/sec
Übersehe ich da irgend was offensichtliches oder hat jemand eine Idee was die Ursache bei der Geschwindigkeit von Windows 7 ist?
Und nein ich möchte die Windows 7 Clients noch nicht auf Windows 10 updaten ;)
Danke
Lg
Zendara
ich habe ein Problem mit der Netzwerkgeschwindigkeit in unserer Firma. So wie es aussieht ist die Geschwindigkeit bei Windows 7 Rechnern um einiges langsamer als es sein sollte.
Als Server wurde Iperf auf Windows Storage Server 2012 R2, Ubuntu Server, IPCop und Synology NAS gestartet.
Clients:
Es sind unterschiedliche Rechner zum Einsatz gekommen von einer Workstation bis zum Laptop und als Betriebssystem Windows 7, Windows 10, Ubuntu Desktop und aus lauter Verzweiflung auch einen Rechner mit Windows XP.
Es wurde mit aktivierter und deaktivierter Firewall getestet.
Die Netze sind im Moment nicht voneinander getrennt. Was ich eigentlich ändern wollte und im Zuge dieser Arbeit auf das Problem aufmerksam wurde.
Rechner wurden auf unterschiedlichen Netzwerkanschlüssen angesteckt.
TCP Autotuning wurde auf Windows 7 Clients auch testweise deaktiviert.
Als Switch kommen HP 2530-24GS und Dlink DGS-3100 zum Einsatz.
Die ermittelten Wert wurden auf einen der oben genannten Server ermittelt. Die anderen Server sind minimal abweichend.
Windows 10 64bit: ~ 942 Mbits/sec
Windows 7 64bit: ~ 278 Mbits/sec
Windows XP 32bit: ~253 Mbits/sec
Ubuntu 12.04 LTS 32bit: ~896 Mbits/sec
Ubuntu 12.04 LTS 64bit: ~934 Mbits/sec
Weitere Tests quer durch:
Server: Windows 7 64bit
Client: Windows 10 64bit
Geschwindigkeit: 811 Mbits/sec
Die gleichen Rechner nur Client und Server vertauscht
Geschwindigkeit: 466 Mbits/sec
Bei diesem Ergebnis bin ich gerade etwas überrascht. Hätte mit um die 280 gerechnet.
Server: Windows 10 64bit
Client: Windows Storage Server 2012 R2
Geschwindigkeit: 873 Mbits/sec
Server: Windows 7 64bit
Client: Windows Storage Server 2012 R2
Geschwindigkeit: 739 Mbits/sec
Server: Windows Storage Server 2012 R2
Client: Windows 10 64bit
Geschwindigkeit: 921 Mbits/sec
Server: Windows Storage Server 2012 R2
Client: Windows 7 64bit
Geschwindigkeit: 256 Mbits/sec
Server: IPCop
Client: Windows 10 64bit
Geschwindigkeit: 915 Mbits/sec
Server: IPCop
Client: Windows Storage Server 2012 R2
Geschwindigkeit: 825 Mbits/sec
Server: IPCop
Client: Windows 7 64bit
Geschwindigkeit: 260 Mbits/sec
Server: Windows 7 64bit
Client: Windows 7 64bit
Geschwindigkeit: 289 Mbits/sec
Bei den beiden Windows 7 PCs wurde Client/Server vertauscht
Geschwindigkeit: 257 Mbits/sec
Übersehe ich da irgend was offensichtliches oder hat jemand eine Idee was die Ursache bei der Geschwindigkeit von Windows 7 ist?
Und nein ich möchte die Windows 7 Clients noch nicht auf Windows 10 updaten ;)
Danke
Lg
Zendara
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: 285007
Url: https://administrator.de/forum/netzwerkgeschwindigkeit-mit-windows-7-clients-langsam-285007.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
30 Kommentare
Neuester Kommentar
Ich hatte mal ein ähnliches Problem an einem Standort. Bis mir irgendwann aufgefallen ist, dass die Win7 Notebooks gleichzeitig per Kabel und WLAN verbunden waren. WLAN aus > alles wieder schnell.
Hallo Freenode,
das mit dem Wlan kann ich in meinem Fall fast ausschließen.
Bei den Windows 7 Clients handelt es sich zum Großteil um normale PCs.
Auf meinem Notebook habe ich LAN und WLAN aktiviert und als Betriebssystem Windows 10.
Ich kann mir vorstellen dass das Problem welches du beschreibst durchaus zutreffen kann wenn LAN und WLAN im gleichen Netz sind und der Client vielleicht mit dem Gateway Probleme hat.
Aber danke für den Tip werde ihn zur Sicherheit berücksichtigen.
das mit dem Wlan kann ich in meinem Fall fast ausschließen.
Bei den Windows 7 Clients handelt es sich zum Großteil um normale PCs.
Auf meinem Notebook habe ich LAN und WLAN aktiviert und als Betriebssystem Windows 10.
Ich kann mir vorstellen dass das Problem welches du beschreibst durchaus zutreffen kann wenn LAN und WLAN im gleichen Netz sind und der Client vielleicht mit dem Gateway Probleme hat.
Aber danke für den Tip werde ihn zur Sicherheit berücksichtigen.
Hast du die Kartentreiber der NICs mal upgedated auf den Win 7 Rechnern ?
Du solltest da am besten immer die original und aktuellsten Treiber der Chipsatz Hersteller (Intel, Realtek, Marvell etc.) verwenden. Niemals die default von Windows oder der HW Hersteller, da die meist alt und nicht aktuell sind.
Das könnte ggf. das Problem fixen.
Die Unterschiede zeigen ja ganz eindeutig das es nur am Win7 liegt.
Interessant wäre es einmal auf der Win7 Hardware eine Linux Live CD (z.B. Knoppix) zu booten und zu checken wie da die Performance Daten sind.
Auch im doch ggf. vorhandene HW Probleme vollständig auszuschliessen.
Du solltest da am besten immer die original und aktuellsten Treiber der Chipsatz Hersteller (Intel, Realtek, Marvell etc.) verwenden. Niemals die default von Windows oder der HW Hersteller, da die meist alt und nicht aktuell sind.
Das könnte ggf. das Problem fixen.
Die Unterschiede zeigen ja ganz eindeutig das es nur am Win7 liegt.
Interessant wäre es einmal auf der Win7 Hardware eine Linux Live CD (z.B. Knoppix) zu booten und zu checken wie da die Performance Daten sind.
Auch im doch ggf. vorhandene HW Probleme vollständig auszuschliessen.
Ich habe zB 2 Notebooks die identisch sind. Einmal mit Windows 7 einmal mit Windows 10. -> unterschiedliche Geschwindigkeit.
2 alte identische Notebooks mit Windows XP und Ubuntu. -> unterschiedliche Geschwindigkeit.
3 Grafik PC wo die Einzelteile 4K € kosten mit 1x Win10 zum testen 2xWin7 im Einsatz. -> unterschiedliche Geschwindigkeit
Die meisten PCs in der Firma sind selbst zusammengebaute Rechner mit unterschiedlichen Motherboards von unterschiedlichen Herstellern mit unterschiedlichen Chipsets.
Die einzige gemeinsamkeit welche ich sehe ist Windows 7.
2 alte identische Notebooks mit Windows XP und Ubuntu. -> unterschiedliche Geschwindigkeit.
3 Grafik PC wo die Einzelteile 4K € kosten mit 1x Win10 zum testen 2xWin7 im Einsatz. -> unterschiedliche Geschwindigkeit
Die meisten PCs in der Firma sind selbst zusammengebaute Rechner mit unterschiedlichen Motherboards von unterschiedlichen Herstellern mit unterschiedlichen Chipsets.
Die einzige gemeinsamkeit welche ich sehe ist Windows 7.
Alles schön und gut, bestätigt aber nicht, dass du überall die aktuellsten Chiptreiber für die NICs installiert hast 
Zitat von @Zendara:
Hallo Freenode,
das mit dem Wlan kann ich in meinem Fall fast ausschließen.
Bei den Windows 7 Clients handelt es sich zum Großteil um normale PCs.
Auf meinem Notebook habe ich LAN und WLAN aktiviert und als Betriebssystem Windows 10.
Ich kann mir vorstellen dass das Problem welches du beschreibst durchaus zutreffen kann wenn LAN und WLAN im gleichen Netz sind und der Client vielleicht mit dem Gateway Probleme hat.
Aber danke für den Tip werde ihn zur Sicherheit berücksichtigen.
Hallo Freenode,
das mit dem Wlan kann ich in meinem Fall fast ausschließen.
Bei den Windows 7 Clients handelt es sich zum Großteil um normale PCs.
Auf meinem Notebook habe ich LAN und WLAN aktiviert und als Betriebssystem Windows 10.
Ich kann mir vorstellen dass das Problem welches du beschreibst durchaus zutreffen kann wenn LAN und WLAN im gleichen Netz sind und der Client vielleicht mit dem Gateway Probleme hat.
Aber danke für den Tip werde ihn zur Sicherheit berücksichtigen.
Joa, habe auch im Nachgang erst gesehen, dass normale Workstations dabei sind. ;)
aktuellste Chipsatz Treiber ??
Ich habe mir den aktuellen Chipsatz Treiber für das Model und Betriebssystem von der Acer Seite herruntergeladen und installiert.
Ich bin gerade noch an einem anderen Test dran und suche mir parallel andere Treiber.
Leider läuf mir gerade die Zeit weg.
Werde morgen meine frisch gewonnenen Erkenntnisse posten.
Für heute bedanke ich mich für eure bisherige Hilfe und Teilnahme.
lg und einen schönen Abend.
Ich bin gerade noch an einem anderen Test dran und suche mir parallel andere Treiber.
Leider läuf mir gerade die Zeit weg.
Werde morgen meine frisch gewonnenen Erkenntnisse posten.
Für heute bedanke ich mich für eure bisherige Hilfe und Teilnahme.
lg und einen schönen Abend.
von der Acer Seite herruntergeladen und installiert.
Genau DAS sollst du eben nicht sondern den Treiber DIREKT vom Chipsatz Hersteller herunterladen !!!Z.B. Realtek: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNi ...
oder Intel: https://downloadcenter.intel.com
...um mal die verbreitesten zu nennen.
Guten Morgen
Bezüglich Treiber habe ich ja geschrieben, dass ich noch nach einer alternative zum Acer Treiber suche.
Diesr Chipsatz ist auf https://www.broadcom.com/support/?gid=9 nicht angeführt und der Treiber der dem am nächsten kommt lässt sich nicht installieren.
Ausgabe von SIW:
Werde noch versuchen einen Rechner frisch aufzusetzen nur mit Windows 7 und mit den aktuellsten Treiber Versionen.
Das dauert leider etwas da ich grad nicht wirklich einen Rechner frei habe.
Der nächste Test den ich gemacht habe, um evt. Fehler bei Iperf auszuschließen ist ein Kopiervorgang von einem Server auf Lokal und wieder zurück.
Um etwas Ablenlung zubekommen habe ich ein Scipt geschrieben das die Zeit mit protokolliert.
Das File ist 15,1 GB groß
Testdurchlauf 1:
Windows 10: SRV -> Lokal = 151 sec
Windows 10: Lokal -> SRV = 179 sec
Windows 7: SRV -> Lokal = 220 sec
Windows 7: Lokal -> SRV = 211 sec
Testdurchlauf 2:
Windows 10: SRV -> Lokal = 161 sec
Windows 10: Lokal -> SRV = 176 sec
Windows 7: SRV -> Lokal = 185 sec
Windows 7: Lokal -> SRV = 211 sec
Testdurchlauf 3 mit einem anderen FileServer:
Windows 10: SRV -> Lokal = 163 sec
Windows 10: Lokal -> SRV = 140 sec
Windows 7: SRV -> Lokal = 202 sec
Windows 7: Lokal -> SRV = 233 sec
Die der Unterschied beim kopieren ist zwar nicht so groß wie dir Resultate bei Iperf aber doch deutlich.
Im Internet bin ich noch über ein paar andere Informationen gestoßen die ggf. hilfreich sein könnten.
Die Werte sagen mir nur bedingt was aber vielleicht kann jemand von euch damit etwas anfangen.
Ausgabe von Windows 10
netsh interface tcp show global
netsh interface ipv4 show interfaces
Ausgabe von Windows 7
netsh interface tcp show global
netsh interface ipv4 show interfaces
So ich teste mal weiter und widme mich wieder der Treiberthematic.
Lg
Zendara
Bezüglich Treiber habe ich ja geschrieben, dass ich noch nach einer alternative zum Acer Treiber suche.
Diesr Chipsatz ist auf https://www.broadcom.com/support/?gid=9 nicht angeführt und der Treiber der dem am nächsten kommt lässt sich nicht installieren.
Ausgabe von SIW:
Netzwerkkarte 1
Modell Broadcom NetLink (TM) Gigabit Ethernet
Hersteller Broadcom
Beschreibung Broadcom NetLink (TM) Gigabit Ethernet
Name [SIW] Broadcom Corporation NetXtreme BCM57786 Gigabit Ethernet PCIe [Acer Incorporated [ALI]]
Aufschrift (gehört zu) LAN-Verbindung
Status Verbunden
MAC Adresse XX:XX:XX:XX:XX:XX
Typ Ethernet 802.3
Geschwindigkeit 1000 Mbps
Driver Provider Not Available
Treiber Version 15.6.0.6
Treiber Datum 3-27-2013Werde noch versuchen einen Rechner frisch aufzusetzen nur mit Windows 7 und mit den aktuellsten Treiber Versionen.
Das dauert leider etwas da ich grad nicht wirklich einen Rechner frei habe.
Der nächste Test den ich gemacht habe, um evt. Fehler bei Iperf auszuschließen ist ein Kopiervorgang von einem Server auf Lokal und wieder zurück.
Um etwas Ablenlung zubekommen habe ich ein Scipt geschrieben das die Zeit mit protokolliert.
set logfile=d:\Copy_file_time.log
set lokalpath=d:
set srvpath=\\192.168.0.6\freigabe
set file=testfile.dd
set dumpfile=%Computername%_%file%
if exist %logfile% del %logfile%
set startzeit=%time%
echo Von Server auf Lokal - START -%startzeit%>>%logfile%
copy "%srvpath%\%file%" "d:\" /Y
set endezeit=%time%
echo Von Server auf Lokal - Ende -%endezeit%>>%logfile%
set startzeit=%time%
echo Von Lokal auf Server - START -%startzeit%>>%logfile%
copy "%lokalpath%\%file%" "%srvpath%\%dumpfile%" /Y
set endezeit=%time%
echo Von Lokal auf Server - Ende -%endezeit%>>%logfile%
if exist "%srvpath%\%dumpfile%" del "%srvpath%\%dumpfile%"
if exist "%lokalpath%\%file%" del "%lokalpath%\%file%"
start %logfile%Das File ist 15,1 GB groß
Testdurchlauf 1:
Windows 10: SRV -> Lokal = 151 sec
Windows 10: Lokal -> SRV = 179 sec
Windows 7: SRV -> Lokal = 220 sec
Windows 7: Lokal -> SRV = 211 sec
Testdurchlauf 2:
Windows 10: SRV -> Lokal = 161 sec
Windows 10: Lokal -> SRV = 176 sec
Windows 7: SRV -> Lokal = 185 sec
Windows 7: Lokal -> SRV = 211 sec
Testdurchlauf 3 mit einem anderen FileServer:
Windows 10: SRV -> Lokal = 163 sec
Windows 10: Lokal -> SRV = 140 sec
Windows 7: SRV -> Lokal = 202 sec
Windows 7: Lokal -> SRV = 233 sec
Die der Unterschied beim kopieren ist zwar nicht so groß wie dir Resultate bei Iperf aber doch deutlich.
Im Internet bin ich noch über ein paar andere Informationen gestoßen die ggf. hilfreich sein könnten.
Die Werte sagen mir nur bedingt was aber vielleicht kann jemand von euch damit etwas anfangen.
Ausgabe von Windows 10
netsh interface tcp show global
Globale TCP-Parameter
--------------------------------------------------------------------
Zustand der empfangsseitigen Skalierung : enabled
Chimney-Abladezustand : disabled
NetDMA-Zustand : disabled
Direkter Cachezugriff (DCA) : disabled
Autom. Abstimmungsgrad Empfangsfenster : normal
Add-On "Überlastungssteuerungsanbieter" : none
ECN-Funktion : disabled
RFC 1323-Zeitstempel : disabled
RTO (anfänglich) : 3000
Zustand der Empfangssegmentzusammenfügung : disabled
Nicht-SACK-RTT-Widerstandsfähigkeit : disabled
Maximale SYN-Neuübertragungen : 2netsh interface ipv4 show interfaces
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
7 5 1500 disconnected Drahtlosnetzwerkverbindung
1 50 4294967295 connected Loopback Pseudo-Interface 1
12 30 1500 disconnected Ethernet
24 5 1500 disconnected LAN-Verbindung* 4
6 20 1500 connected Ethernet 2
19 10 1500 connected Local Area ConnectionAusgabe von Windows 7
netsh interface tcp show global
Globale TCP-Parameter
----------------------------------------------
Empfangsseite : enabled
Chimney-Abladestatus : automatic
NetDMA-Status : enabled
Direkter Cachezugriff (DCA) : disabled
Autom. Abstimmungsgrad Empfangsfenster : normal
Add-On "Überlastungssteuerungsanbieter" : none
ECN-Funktion : disabled
RFC 1323-Zeitstempel : disablednetsh interface ipv4 show interfaces
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
18 10 1500 connected LAN-VerbindungSo ich teste mal weiter und widme mich wieder der Treiberthematic.
Lg
Zendara
dass ich noch nach einer alternative zum Acer Treiber suche.
Chipsatz im Geräte Manager nachsehen oder im Datenblatt und auf die Webseite des Chipsatz Herstellers gehen.Kopieren über Windows SMB ist sehr kontraproduktiv und macht die Performance Aussage vollkommen unbrauchbar.
Der Grund ist das SMB erheblich ineffizient da es nur sehr kleine Pakete nutzt.
Erschwerend kommt dazu das der Datenfluss abhängig ist von CPU Leistung, Platten- und Controller Perfornce des Servers und NIC Durchsatz abhängig ist.
All das verfälscht das Ergebnis.
Besser ist es bei iPerf zu bleiben oder NetIO zu verwenden, da diese Tools den Nettodurchsatz anzeigen unabhängig von Peripherie.
Hallo zusammen,
ich habe auch einige PCs im Unternehmen wo man bei den Treibern Einstellungen vornehmen kann.
Und da kann man meist auch auswählen, ob man die Optimierung für "Throughput" oder aber "Stability"
benutzen möchte und bei Stabilität ist der PC um einiges langsamer als wenn man die Option für den
Durchsatz aktiviert!
Daten dann sicherlich schon im Cache lagen macht zusätzlich keinen Sinn.
bringt noch einmal andere Werte.
Das ist eben ein leidiges Thema und hat meistens oder sehr oft auch nicht nur einen Hintergrund
oder eine Fehlerquelle an der es dann liegt.
Wir sind nur ein kleines KMU Unternehmen mit xyz Mitarbeitern und benutzen daher auch nur
"kleine" Switche der bis 600 € Klasse.
- Klar kann man machen aber dann erwarte ich auch nicht die Geschwindigkeit vom, theoretisch
Möglichen Durchsatz
Die Netzwerkadapter onBoard kann man doch auch nehmen.
- Klar ist das schon nur Intel Adpater sei es nun Desktop oder Server bringen nicht nur mittels
Treibereinstellungen und sauber programmierter und guter Treiber Vorteile!
Wozu einen richtige RAID Controller mit Cache-Modul und nicht der OnBoard verbaute.
- Damit die Daten (15 GB) auch schnell auf das RAID geschrieben werden können!
Was nützt der letzte Tuning Tipp für die NICs wenn das RAID zu lahm ist die Daten zu schreiben?
Warum die Server via LAG oder gleich via 10 GBit/s anbinden?
- Damit erst gar kein Flaschenhals entsteht und der Switch gleich von vorneherein auszuschließen ist!
Bzw. die Anbindung der Server an den Switch.
Warum einen 3000 Switch kaufen und den dann auch noch "stapeln" mit dem 200 € Switch geht es doch auch?
- Na klar geht das auch nur wenn Switche gestapelt werden und non blocking bzw. cut ´n through Switche sind
kommt es meist gar nicht zu solchen Erlebnissen wie sie hier im Forum immer wieder dargestellt oder berichtet
werden.
Wer gerade einen günstigen Switch im Angebot hat, von dem kaufen wir, die sind ja heute alle kompatibel
zu einander.
- Jo, nur die Switche eines Herstellers sind es auch und lassen sich dann auch problemlos stapeln.
Wir haben eine Firewall xyz (IPCop) oder Eigenbau.
- Sagte aber auch rein gar cnihts über deren Leistungsfähigkeit etwas aus und sehr oft werden Layer2
Switche verbaut und dann muss die Firewall das auch noch alles obendrein noch routen und warum sollte
man einen ~15 GB Datei immer wieder durch die Firewall schleifen? Es ist halt schon ein Unterschied ob
dort ein Intel Core i3 oder eine Intel Xeon E5 Prozessor drinnen werkelt!
Wir haben einen Windows yxz Server
- Und wie viel RAM ist zum puffern der Daten drin bevor sie auf das RAID geschrieben werden?
Welche CPU werkelt dort? Sind dort OnBoard NICs verbaut oder Intel Karten die einen eigenen
DSP (Digitalen Signal Prozessor) mitbringen und die CPU richtig entlasten!?
Mag sein das es an einigen oder mehreren bzw. sogar an allen Punkten bei Dir liegt oder an gar keinem,
aber ohne dass Du mehr Angaben machst ist das hier eher eine Runde heiteres Topfschlagen und Raten.
Und wegen der Geschwindigkeit der NICs die in den PCs verbaut worden sind würde ich mir dann auch
nicht solche Sorgen machen wollen.
Sicherlich willst Du noch nicht Upgraden auf Windows 10 nur wenn sich dort im TCP(IP Stack merklich etwas
gegenüber den Windows 7 basierenden PCs getan hat, kommen wir der Sache hier auch nie auf den Grund!
Mach doch mal einen Test und Upgrade nur einen PC!
Gruß
Dobby
ich habe auch einige PCs im Unternehmen wo man bei den Treibern Einstellungen vornehmen kann.
Und da kann man meist auch auswählen, ob man die Optimierung für "Throughput" oder aber "Stability"
benutzen möchte und bei Stabilität ist der PC um einiges langsamer als wenn man die Option für den
Durchsatz aktiviert!
Kopieren über Windows SMB ist sehr kontraproduktiv und macht die Performance Aussage
vollkommen unbrauchbar.
Finde ich auch denn alleine der erste Test der dann auch noch wieder holt wurde und dievollkommen unbrauchbar.
Daten dann sicherlich schon im Cache lagen macht zusätzlich keinen Sinn.
Besser ist es bei iPerf zu bleiben oder NetIO zu verwenden, da diese Tools den Nettodurchsatz
anzeigen unabhängig von Peripherie.
iPerf in der neusten Version kann mittels eines Parameters sogar alle CPU Kerne nutzen undanzeigen unabhängig von Peripherie.
bringt noch einmal andere Werte.
Das ist eben ein leidiges Thema und hat meistens oder sehr oft auch nicht nur einen Hintergrund
oder eine Fehlerquelle an der es dann liegt.
Wir sind nur ein kleines KMU Unternehmen mit xyz Mitarbeitern und benutzen daher auch nur
"kleine" Switche der bis 600 € Klasse.
- Klar kann man machen aber dann erwarte ich auch nicht die Geschwindigkeit vom, theoretisch
Möglichen Durchsatz
Die Netzwerkadapter onBoard kann man doch auch nehmen.
- Klar ist das schon nur Intel Adpater sei es nun Desktop oder Server bringen nicht nur mittels
Treibereinstellungen und sauber programmierter und guter Treiber Vorteile!
Wozu einen richtige RAID Controller mit Cache-Modul und nicht der OnBoard verbaute.
- Damit die Daten (15 GB) auch schnell auf das RAID geschrieben werden können!
Was nützt der letzte Tuning Tipp für die NICs wenn das RAID zu lahm ist die Daten zu schreiben?
Warum die Server via LAG oder gleich via 10 GBit/s anbinden?
- Damit erst gar kein Flaschenhals entsteht und der Switch gleich von vorneherein auszuschließen ist!
Bzw. die Anbindung der Server an den Switch.
Warum einen 3000 Switch kaufen und den dann auch noch "stapeln" mit dem 200 € Switch geht es doch auch?
- Na klar geht das auch nur wenn Switche gestapelt werden und non blocking bzw. cut ´n through Switche sind
kommt es meist gar nicht zu solchen Erlebnissen wie sie hier im Forum immer wieder dargestellt oder berichtet
werden.
Wer gerade einen günstigen Switch im Angebot hat, von dem kaufen wir, die sind ja heute alle kompatibel
zu einander.
- Jo, nur die Switche eines Herstellers sind es auch und lassen sich dann auch problemlos stapeln.
Wir haben eine Firewall xyz (IPCop) oder Eigenbau.
- Sagte aber auch rein gar cnihts über deren Leistungsfähigkeit etwas aus und sehr oft werden Layer2
Switche verbaut und dann muss die Firewall das auch noch alles obendrein noch routen und warum sollte
man einen ~15 GB Datei immer wieder durch die Firewall schleifen? Es ist halt schon ein Unterschied ob
dort ein Intel Core i3 oder eine Intel Xeon E5 Prozessor drinnen werkelt!
Wir haben einen Windows yxz Server
- Und wie viel RAM ist zum puffern der Daten drin bevor sie auf das RAID geschrieben werden?
Welche CPU werkelt dort? Sind dort OnBoard NICs verbaut oder Intel Karten die einen eigenen
DSP (Digitalen Signal Prozessor) mitbringen und die CPU richtig entlasten!?
Mag sein das es an einigen oder mehreren bzw. sogar an allen Punkten bei Dir liegt oder an gar keinem,
aber ohne dass Du mehr Angaben machst ist das hier eher eine Runde heiteres Topfschlagen und Raten.
Und wegen der Geschwindigkeit der NICs die in den PCs verbaut worden sind würde ich mir dann auch
nicht solche Sorgen machen wollen.
Sicherlich willst Du noch nicht Upgraden auf Windows 10 nur wenn sich dort im TCP(IP Stack merklich etwas
gegenüber den Windows 7 basierenden PCs getan hat, kommen wir der Sache hier auch nie auf den Grund!
Mach doch mal einen Test und Upgrade nur einen PC!
Gruß
Dobby
Guten Morgen,
danke für die rege und ausführliche Anteilnahme.
@aqui
Bezüglich des Netzwerkkarten Treiber habe ich die aktuellste Version jetzt runter geladen und installiert. Der Chipsatz der im Notebook verbaut ist wird zwar nicht direkt angeführt aber da es sowieso der einziger Treiber ist der verfügbar ist...
Nach einem neustart und erneuten Test komme ich wieder nur auf 294 Mbits/sec.
Weiter Versuche mit diesem Notebook werde ich jetzt abbrechen.
@108012
Was den Switch betrifft hast du sicherlich nicht unrecht aber da ich mit allen Rechnern auf den gleichen Switchs hänge und ich mit einigen eine sehr hohe Performance erreiche denke ich kann man diese Möglichkeit beiseitelassen.
Die Grundbelastung unseres Netzwerks ist auch eher gering auch wenn man die Backups nicht unterschätzen darf aber die laufen ja nur zu gewissen Zeiten.
Was aber zu ignorieren ist da ich zum Testen einen Client und einen Server auf einen managed Switch angeschlossen habe. Genau so wurden die Rechner mit einem Crossover Netzwerkkabel verbunden und auch einen ganz einfachen Standard Switch gesteckt.
Jeder Versuch mit dem gleichen Ergebnis.
Die CPU ist ein Intel(R) Celeron(R) CPU G1610 @ 2x2.60GHz mit 8 GB RAM. Die Auslastung der CPU und Speicher kommen nie auf über 10%.
Ich benutzt die onboard Netzwerkkarte und auch günstige TP-Link PCIe Netzwerkkarten.
Die Firewall habe ich nur erwähnt weil ich auf dieser Iperf als Server für Tests gestartet habe. Diese ist ja auch nicht das Problem da die Tests mit Windows 10 wunderbar funktionieren.
Aber gehe ich richtig in der Annahme, dass wenn dies der Fall wäre dieses Problem jeder haben müsste der Windows 7 benutzt?
Zum testen habe ich einen PC genommen der von der Leistung bei uns eher durchschnittlich ist.
Zur Hardware:
Motherboard: EVGA CLassified SR-2
CPU: 2x Xeon X5650 @2,67 GHz
16GB RAM
Netzwerk: 2x PCIE Gigabit Ethernet Marvell Yukon 88E8057 onboard
Grafikarte: Nvidia Geforce GTX 980
Ergebnis mit Windows 7 und aktuellen Treibern – 301 Mbits/sec
Ergebnis mit Windows 10 - 916 Mbits/sec
Hat von euch niemand ähnliche Ergebnisse? Ich gebe mich ja damit zufrieden wenn es mit Windows 7 nicht schneller geht aber wenn das nur bei mir vorkommt macht das in Anbetracht der Kombination der Testszenarien nicht wirklich Sinn.
Danke
lg
Zendara
danke für die rege und ausführliche Anteilnahme.
@aqui
Bezüglich des Netzwerkkarten Treiber habe ich die aktuellste Version jetzt runter geladen und installiert. Der Chipsatz der im Notebook verbaut ist wird zwar nicht direkt angeführt aber da es sowieso der einziger Treiber ist der verfügbar ist...
Nach einem neustart und erneuten Test komme ich wieder nur auf 294 Mbits/sec.
Name [SIW] Broadcom Corporation NetXtreme BCM57786 Gigabit Ethernet PCIe [Acer Incorporated [ALI]]
Weiter Versuche mit diesem Notebook werde ich jetzt abbrechen.
@108012
Was den Switch betrifft hast du sicherlich nicht unrecht aber da ich mit allen Rechnern auf den gleichen Switchs hänge und ich mit einigen eine sehr hohe Performance erreiche denke ich kann man diese Möglichkeit beiseitelassen.
Die Grundbelastung unseres Netzwerks ist auch eher gering auch wenn man die Backups nicht unterschätzen darf aber die laufen ja nur zu gewissen Zeiten.
Wozu einen richtige RAID Controller mit Cache-Modul und nicht der OnBoard verbaute.
Hier bin ich definitiv schuldig! Ich bevorzuge bei den meisten Server Sicherheit statt Performance. Aber warum nicht das Optimum aus dem Netzwerk rausholen und einige Verbindungen gibt es trotzdem wo auch im Optimal fall ein voll funktionierendes Netzwerk der Flaschenhals sein sollte.Als Switch kommen HP 2530-24GS und Dlink DGS-3100 zum Einsatz.
Sorry das es hier zu Missverständnissen gekommen ist. Wir haben nicht 2 Switchs die oben angeführt sind sonder mehrere zB. 3 x Dlink DGS3100 die gestapelt sind.Was aber zu ignorieren ist da ich zum Testen einen Client und einen Server auf einen managed Switch angeschlossen habe. Genau so wurden die Rechner mit einem Crossover Netzwerkkabel verbunden und auch einen ganz einfachen Standard Switch gesteckt.
Jeder Versuch mit dem gleichen Ergebnis.
Wir haben eine Firewall xyz (IPCop) oder Eigenbau.
Mein Problem betrifft nicht den Traffic der über die Firewall geht (noch nicht) es betrifft das Lan selbst egal wie ich es aufbaue.Die CPU ist ein Intel(R) Celeron(R) CPU G1610 @ 2x2.60GHz mit 8 GB RAM. Die Auslastung der CPU und Speicher kommen nie auf über 10%.
Ich benutzt die onboard Netzwerkkarte und auch günstige TP-Link PCIe Netzwerkkarten.
Die Firewall habe ich nur erwähnt weil ich auf dieser Iperf als Server für Tests gestartet habe. Diese ist ja auch nicht das Problem da die Tests mit Windows 10 wunderbar funktionieren.
Sicherlich willst Du noch nicht Upgraden auf Windows 10 nur wenn sich dort im TCP(IP Stack merklich etwas gegenüber den Windows 7 basierenden PCs getan hat, kommen wir der Sache hier auch nie auf den Grund!
Das ist richtig und eine Upgrade wäre eine logische Vorgehensweise.Aber gehe ich richtig in der Annahme, dass wenn dies der Fall wäre dieses Problem jeder haben müsste der Windows 7 benutzt?
Mach doch mal einen Test und Upgrade nur einen PC!
Zum testen habe ich einen PC genommen der von der Leistung bei uns eher durchschnittlich ist.
Zur Hardware:
Motherboard: EVGA CLassified SR-2
CPU: 2x Xeon X5650 @2,67 GHz
16GB RAM
Netzwerk: 2x PCIE Gigabit Ethernet Marvell Yukon 88E8057 onboard
Grafikarte: Nvidia Geforce GTX 980
Ergebnis mit Windows 7 und aktuellen Treibern – 301 Mbits/sec
Ergebnis mit Windows 10 - 916 Mbits/sec
Hat von euch niemand ähnliche Ergebnisse? Ich gebe mich ja damit zufrieden wenn es mit Windows 7 nicht schneller geht aber wenn das nur bei mir vorkommt macht das in Anbetracht der Kombination der Testszenarien nicht wirklich Sinn.
Danke
lg
Zendara
Hallo, ich habe heute mal wieder einige unserer Klienten gemessen, alle in Verbindung zu unserem einzigen Server.
Mit iperf bzw. Jperf
Server ist ein SBS 2011, alle Klienten haben Windows 7 Prof installiert, in der Regel alles onboard-NIC, komplette
Hardware GigaBit-Geräte.
Ich messe im ungünstigsten Fall bei einm der Klienten lediglich 275 MBit/s und beim "schnellsten" Klienten messe ich
420 MBit/s
Welche Werte sollte denn in der Praxis absolut möglich sein? Was kann ich prüfen? Könnte es am Server liegen?
(Im Server werkelt ein LSO SAS / SATA - Controller mit 4 HDDs im RAID)
Danke euch!
Mit iperf bzw. Jperf
Server ist ein SBS 2011, alle Klienten haben Windows 7 Prof installiert, in der Regel alles onboard-NIC, komplette
Hardware GigaBit-Geräte.
Ich messe im ungünstigsten Fall bei einm der Klienten lediglich 275 MBit/s und beim "schnellsten" Klienten messe ich
420 MBit/s
Welche Werte sollte denn in der Praxis absolut möglich sein? Was kann ich prüfen? Könnte es am Server liegen?
(Im Server werkelt ein LSO SAS / SATA - Controller mit 4 HDDs im RAID)
Danke euch!
In der Praxis sind auch bei ganz schlechten Realtek Chipsätzen die die System CPU belasten (also worst Case) immer Wert um die 500-bis 600 Mbit/s realistisch !
NICs mit Intel oder Broadcom usw. also technisch besseren Chipsätzen schaffen in der Regel immer Wert die zw. 700 und 900 Mbit/s liegen.
Mit deinen 270 Mbits ist also definitiv etwas faul. Da gibt es 2 mögliche Ursachen:
Wenn der Intel hat dann solltest du den Treiber updaten auf den aktuellsten. Niemals den embeddeten von Windows nehmen. Das hilft in der Regel.
Außerdem kannst du ja auch mit iperf oder jperf am Server selber messen ob er der böse Bube ist !!
NICs mit Intel oder Broadcom usw. also technisch besseren Chipsätzen schaffen in der Regel immer Wert die zw. 700 und 900 Mbit/s liegen.
Mit deinen 270 Mbits ist also definitiv etwas faul. Da gibt es 2 mögliche Ursachen:
- Aktiviertes Flow Control auf dem Ethernet Switch ! Das sollte generell IMMER deaktiviert sein im Switch Setup.
- Autonegitiation Problem, also ein Speed- und Duplex Mismatch an dem Port. Hier hilft es wenn du den Speed und Duplex Wert einmal fest, statisch im NIC Setup (Treiber) auf 1G und Fulldup setzt und nochmal misst.
Könnte es am Server liegen?
Klar wenn der einen schlechten NIC Chipsatz hat. Sowas wie realtek usw. wäre an einem Server tödlich.Wenn der Intel hat dann solltest du den Treiber updaten auf den aktuellsten. Niemals den embeddeten von Windows nehmen. Das hilft in der Regel.
Außerdem kannst du ja auch mit iperf oder jperf am Server selber messen ob er der böse Bube ist !!
Hi, danke für die Tips!
Server ist ein SuperMicro mit Dual-Intel 82576 Gigabit Ethernet Controller, einer der beiden LAN-Anschlüsse ist angeschlossen.
Treiber ist veraltet, ist ein Intel-Treiber, ich werde bei Gelegenheit den neuesten von Intel installieren, kann ich freilich erst machen wenn
keiner da ist. Die Einstellungen im Treiber / des Ports mach ich dann nach dem Updates des Treibers.
Ich habe diese Woche 7 verschiedene Klienten gemessen, meinst du ich muss an jedem Klienten auf Full 1G manuell stellen oder war das auf den Server bezogen? Wie soll das denn gehen wenn wir hier 100 Klienten hätten? Ich kann mir nicht vorstellen daß der Fehler in jedem Klienten steckt, alle Klienten haben ja durchgängig schlechte Werte zum / vom Server, also ich werde mich erstmal auf den Server konzentrieren.
Zum Switch, der ist unmanaged, ich kann als Flow-Control nicht beeinflussen. Würdest du auf alle Fälle einen managed empfehlen?
Iperf oder Jperf am Server? Dachte ich kann nur Server-Modus oder Klient-Modus starten, wie soll das gehen?
Server ist ein SuperMicro mit Dual-Intel 82576 Gigabit Ethernet Controller, einer der beiden LAN-Anschlüsse ist angeschlossen.
Treiber ist veraltet, ist ein Intel-Treiber, ich werde bei Gelegenheit den neuesten von Intel installieren, kann ich freilich erst machen wenn
keiner da ist. Die Einstellungen im Treiber / des Ports mach ich dann nach dem Updates des Treibers.
Ich habe diese Woche 7 verschiedene Klienten gemessen, meinst du ich muss an jedem Klienten auf Full 1G manuell stellen oder war das auf den Server bezogen? Wie soll das denn gehen wenn wir hier 100 Klienten hätten? Ich kann mir nicht vorstellen daß der Fehler in jedem Klienten steckt, alle Klienten haben ja durchgängig schlechte Werte zum / vom Server, also ich werde mich erstmal auf den Server konzentrieren.
Zum Switch, der ist unmanaged, ich kann als Flow-Control nicht beeinflussen. Würdest du auf alle Fälle einen managed empfehlen?
Iperf oder Jperf am Server? Dachte ich kann nur Server-Modus oder Klient-Modus starten, wie soll das gehen?
meinst du ich muss an jedem Klienten auf Full 1G manuell stellen oder war das auf den Server bezogen?
Nein das musst du nicht. Es reicht ja auch einfach mal den Switch ganz auszuschliessen und ihn mal direkt mit einem Patchkabel Back to Back (NIC to NIC) mit dem Server zu verbinden.Dann iperf anschmeissen und messen. Damit bekommst du dann verlässliche Werte OHNE Switch Infrastruktur dazwischen also was die Karten wirklich nackt bringen.
Genau das MUSS über die Switchinfrastruktur natürlich auch möglich sein sofern dein Netz keine Engpässe irgendwo durch Überbuchung hat.
Erreicht man genau diese Bandbreite mit Switch dann nicht, kann es nur einer der 2 oben genannten Fehler sein oder eben eine Überbuchung. Letzteres kann man aber nur raten wenn man dein Netzdesign nicht kennt.
Wenn es ein billiger unmanaged Switch ist dann kannst du Flow Control komplett ausschliessen. Solche Switches können das technisch dann nicht.
Allerdings sind die dann verstärkt anfällig für einen Autonegotiation Mismatch. Es ist sehr wahrscheinlich das du ggf. so ein Problem hast. Dummerweise kann man bei unmanaged Switches eben wegen der fehlenden Managebarkeit das nicht prüfen. Deshalb gehören solche Switches niemals in ein Firmenumfeld was auch ein blutiger Laie eigentlich wissen sollte.
Was dann passiert bei einem Mismatch ist das die Collision Rate ouf dem Switchport dann prozentual zum Traffic Volumen steigt und so den Durchsatz drückt.
Du kannst hier nicht viel machen wegen der sehr eingeschränkten Troubleshooting Optionen, das ist klar.
Da bleibt dir dann nur probieren.
- Als erstes Treiber auf den aktuellsten Stand bringen
- Dann Back to Back Test um einen verlässlichen Referenzwert zu bekommen an dem an sich überhaupt orientieren kann. Hier musst du darauf achten auch Clients mit anderem Chipset mal zu testen.
- Dann mit Switch testen und hier kannst du dann einzig nur an der NIC Karte mal mit statischen Speed und Duplex Werten testen.
Den Test hab ich als nächstes vor, mal direkt NIC zu NIC, aber wie gesagt, kann ich im laufenden Betrieb nicht machen, eigentlich erst nach 22 Uhr (Schichtbetrieb) oder am WE.
Ich hab vorhin den einen Klienten nochmal gemessen, diesmal mit nur einem Switch, also dem Hauptswitch dazwischen, die Werte waren besser, von vorher so um die 400 MBit/s auf jetzt ca 500 MBit/s - aber der direkte Test wäre noch interessant, danach dann
Treiber neu drauf beim Server und die Einstellungen kontrollieren die du nanntest. Dann kann ich mehr sagen.
Werde das so machen wie du sagst dann kann ich die neuen Fakten nennen.
Ich hab vorhin den einen Klienten nochmal gemessen, diesmal mit nur einem Switch, also dem Hauptswitch dazwischen, die Werte waren besser, von vorher so um die 400 MBit/s auf jetzt ca 500 MBit/s - aber der direkte Test wäre noch interessant, danach dann
Treiber neu drauf beim Server und die Einstellungen kontrollieren die du nanntest. Dann kann ich mehr sagen.
Werde das so machen wie du sagst dann kann ich die neuen Fakten nennen.
Auf die sind wir dann mal gespannt. Was hast du dann da für ungemanagte Gurkenswitches ??
Genau.
Gurkenswitch, naja, nichteinmal, ist ein TP-Link, glaube TL-SG1016,
habe den damals mit einem Kollegen zusammen ausgesucht, da war das Netzwerk allerdings noch nicht so umfassend wie es halt jetzt ist.
Habe damals auch jemanden gefragt von einer IT-Firma, die haben damals noch für uns regelmäßig gearbeitet. Der hatte keine Einwände.
Hab den Typ grad nochmal schnell gegoogelt, scheint nicht schlecht zu sein das Teil (für einen unmanaged).
edit: typ passt glaube ich nicht, der scheint managed, ich schau mal nach...
edit2: also es ist der TL-SG1016D, also unmanaged
der TL-SG1016DE wäre managed
Gurkenswitch, naja, nichteinmal, ist ein TP-Link, glaube TL-SG1016,
habe den damals mit einem Kollegen zusammen ausgesucht, da war das Netzwerk allerdings noch nicht so umfassend wie es halt jetzt ist.
Habe damals auch jemanden gefragt von einer IT-Firma, die haben damals noch für uns regelmäßig gearbeitet. Der hatte keine Einwände.
Hab den Typ grad nochmal schnell gegoogelt, scheint nicht schlecht zu sein das Teil (für einen unmanaged).
edit: typ passt glaube ich nicht, der scheint managed, ich schau mal nach...
edit2: also es ist der TL-SG1016D, also unmanaged
der TL-SG1016DE wäre managed
da war das Netzwerk allerdings noch nicht so umfassend wie es halt jetzt ist.
Das ist der übliche Fehler der immer gemacht wird IT-Firma, die haben damals noch für uns regelmäßig gearbeitet. Der hatte keine Einwände.
Das war vermutlich kein Netzwerker sondern ein Windows Frickler oder die IT Firma hat keinerlei Netzwerk KnowHow. Kein Netzwerker würde dir so eine Antwort geben bei einem Firmennetzwerk. Es sei denn du bist Klempner Röhricht mit 2 PCs und ner FritzBox.Unmanaged in Firmen ist generell ein NoGo aber egal. Was nicht ist ist nicht und du musst erstmal mit dem testen was du hast.
Hallo und Guten Morgen,
konnte am WE die Messungen machen, here we go:
Server SBS 2011
NIC Intel 82576 Dual Gigabit
Alter Treiber 11.0.5.22 vom 06.04.2009
Neuer Treiber 12.7.28.0 vom 26.05.2015
Speed-Mode alt auf auto jetzt auf fix 1GBit/s Vollduplex
Netzwerk-Geschwindigkeitsmessungen:
- alle Angaben in MBit/s
- Messung mit Jperf 60 Sekunden pro Durchgang
- Speed ist Durchschnitt aus 60 Sekunden = 60 Messungen
- nach Treiberinstallation NIC Server Neustart des Servers
Klient PC16; HP Z400; NIC Broadcom NetXtreme Gigabit Ethernet
Treiber 17.2.0.2 vom 03.07.2015
a) Standard-Verbindung wie in der Praxis
365, 422, 360
b) Verbindung nur über den einen Hauptswitch
492, 496, 483
c) Verbindung nur über Hauptswitch und NIC des Servers auf Fullduplex 1 GBit/s fix
495, 498, 495
d) Verbindung direkt über Cross-Kabel Back to Back mit
NIC des Servers auf Fullduplex 1 GBit/s fix
517, 533, 518
e) Verbindung direkt über Cross-Kabel Back to Back mit
NIC des Servers auf Fullduplex 1 GBit/s fix und
neuem Server NIC Intel Treiber
516, 530, 545
Klient PC30; Fujitsu mit
NIC Realtek PCIe GBE Family Controller
Version 7.37.1229.2010 vom 29.12.2010
a) Verbindung direkt über Cross-Kabel Back to Back mit
NIC des Servers auf Fullduplex 1 GBit/s fix und
neuem Server NIC Intel Treiber
275, 278, 271
Wie man sieht hat Back to Back leider nicht das gebracht wie erwartet und erhofft.
Praxis-Verbindung über zwei, drei Switche kann man sagen ist 100 MBit/s langsamer als direkt nur über den einen Hauptswitch.
Am unmanaged Switch liegts wohl auch nicht. Server NIC mit neuem Treiber auch nicht besser.
Frage zur Methode, hat die Konfiguration der HDDs im Server Einfluss auf die Jperf-Messung? Oder misst Jperf nur NIC zu NIC und die Daten kommen und gehen je direkt in und aus dem RAM zwischen Server und Klient? Also egal ob Server / Klient mit HDD, SSD oder Raid usw?
Andere Faktoren die die Messung beeinflussen? CPU-Speed? RAM-Speed?
Was das Raid vom Server angeht, ich vermute nämlich so oder so, daß unser Server-Raid zu langsam ist für aktuelle Verhältnisse und die gestiegenen Ansprüche und Erwartungen.
Merci
konnte am WE die Messungen machen, here we go:
Server SBS 2011
NIC Intel 82576 Dual Gigabit
Alter Treiber 11.0.5.22 vom 06.04.2009
Neuer Treiber 12.7.28.0 vom 26.05.2015
Speed-Mode alt auf auto jetzt auf fix 1GBit/s Vollduplex
Netzwerk-Geschwindigkeitsmessungen:
- alle Angaben in MBit/s
- Messung mit Jperf 60 Sekunden pro Durchgang
- Speed ist Durchschnitt aus 60 Sekunden = 60 Messungen
- nach Treiberinstallation NIC Server Neustart des Servers
Klient PC16; HP Z400; NIC Broadcom NetXtreme Gigabit Ethernet
Treiber 17.2.0.2 vom 03.07.2015
a) Standard-Verbindung wie in der Praxis
365, 422, 360
b) Verbindung nur über den einen Hauptswitch
492, 496, 483
c) Verbindung nur über Hauptswitch und NIC des Servers auf Fullduplex 1 GBit/s fix
495, 498, 495
d) Verbindung direkt über Cross-Kabel Back to Back mit
NIC des Servers auf Fullduplex 1 GBit/s fix
517, 533, 518
e) Verbindung direkt über Cross-Kabel Back to Back mit
NIC des Servers auf Fullduplex 1 GBit/s fix und
neuem Server NIC Intel Treiber
516, 530, 545
Klient PC30; Fujitsu mit
NIC Realtek PCIe GBE Family Controller
Version 7.37.1229.2010 vom 29.12.2010
a) Verbindung direkt über Cross-Kabel Back to Back mit
NIC des Servers auf Fullduplex 1 GBit/s fix und
neuem Server NIC Intel Treiber
275, 278, 271
Wie man sieht hat Back to Back leider nicht das gebracht wie erwartet und erhofft.
Praxis-Verbindung über zwei, drei Switche kann man sagen ist 100 MBit/s langsamer als direkt nur über den einen Hauptswitch.
Am unmanaged Switch liegts wohl auch nicht. Server NIC mit neuem Treiber auch nicht besser.
Frage zur Methode, hat die Konfiguration der HDDs im Server Einfluss auf die Jperf-Messung? Oder misst Jperf nur NIC zu NIC und die Daten kommen und gehen je direkt in und aus dem RAM zwischen Server und Klient? Also egal ob Server / Klient mit HDD, SSD oder Raid usw?
Andere Faktoren die die Messung beeinflussen? CPU-Speed? RAM-Speed?
Was das Raid vom Server angeht, ich vermute nämlich so oder so, daß unser Server-Raid zu langsam ist für aktuelle Verhältnisse und die gestiegenen Ansprüche und Erwartungen.
Merci
Hast du den Speedtest mit TCP oder UDP Frames gemacht ??
UDP wäre nochmal sinnvoll zu wissen, da da der Handshaking Overhead entfällt.
So oder so sind die Ergebnisse erschreckend. 50% Auslastung schafft das nur im Back to Back Test.
Da ist es dann auch klar das die Werte über die Infrastruktur nicht viel besser sind.
Die kannst du vermutlich ausschliessen dann als Fehlerquelle.
Wenn du Back to Back auch sowohl mit statischem als auch mit auto Speed und Duplex und das (WICHTIG) immer beidseitig eingestellt gemessen hast sind das recht üble Werte.
Würde bedeuten das deine NIC Hardware den Gig Link höchstens zu 50% auslasten kann.
Ein sehr sehr schlechter Wert den man für Realtek Chipsätze tolerieren könnte aber nicht für Broadcom oder Intel Chipsätze.
Dort sollte immer ein Durchsatz von mindesten 70% erreichbar sein. In der Regel liegt der max. Durchsatz dort bei um die 80-90%
CPU und RAM Speed beeinflussen die Messungen nicht. Jedenfalls nicht bei Chipsätzen wo das Packet Handling im Offload passiert wie bei diesen Chipsätzen.
Interessant wären nochmal Back to Back Messungen mit reiner Intel HW oder reiner Broadcom HW.
Idealerweise mit sowas wie NetIO http://www.ars.de/ars/ars.nsf/docs/netio was auch immer die korrespondierende RX und TX Rate anzeigt beim Test. M.E. macht iperf das aber auch mit dem entsprechenden Schalter.
Server RAID usw. ist bei diesen Tests vollkommen außen vor.
Logisch denn die SW erzeugt den Traffic direkt auf der NIC. Das ist ja gerade der tiefere Sinn dieser Messungen und Tools, das sie alle anderen Einflüsse wie Platten, Bus, Filesystem oder Sharing Protokolle wie FTP oder SMB/CIFS außen vor halten. Reine Netto Daten also was die Infrastruktur kann.
50% Durchsatz ist wahrlich schlecht für einen Gig Port. Das schaffen auch einfachste Realtek Chipsets über die Rechner CPU immer.
UDP wäre nochmal sinnvoll zu wissen, da da der Handshaking Overhead entfällt.
So oder so sind die Ergebnisse erschreckend. 50% Auslastung schafft das nur im Back to Back Test.
Da ist es dann auch klar das die Werte über die Infrastruktur nicht viel besser sind.
Die kannst du vermutlich ausschliessen dann als Fehlerquelle.
Wenn du Back to Back auch sowohl mit statischem als auch mit auto Speed und Duplex und das (WICHTIG) immer beidseitig eingestellt gemessen hast sind das recht üble Werte.
Würde bedeuten das deine NIC Hardware den Gig Link höchstens zu 50% auslasten kann.
Ein sehr sehr schlechter Wert den man für Realtek Chipsätze tolerieren könnte aber nicht für Broadcom oder Intel Chipsätze.
Dort sollte immer ein Durchsatz von mindesten 70% erreichbar sein. In der Regel liegt der max. Durchsatz dort bei um die 80-90%
CPU und RAM Speed beeinflussen die Messungen nicht. Jedenfalls nicht bei Chipsätzen wo das Packet Handling im Offload passiert wie bei diesen Chipsätzen.
Interessant wären nochmal Back to Back Messungen mit reiner Intel HW oder reiner Broadcom HW.
Idealerweise mit sowas wie NetIO http://www.ars.de/ars/ars.nsf/docs/netio was auch immer die korrespondierende RX und TX Rate anzeigt beim Test. M.E. macht iperf das aber auch mit dem entsprechenden Schalter.
Server RAID usw. ist bei diesen Tests vollkommen außen vor.
Logisch denn die SW erzeugt den Traffic direkt auf der NIC. Das ist ja gerade der tiefere Sinn dieser Messungen und Tools, das sie alle anderen Einflüsse wie Platten, Bus, Filesystem oder Sharing Protokolle wie FTP oder SMB/CIFS außen vor halten. Reine Netto Daten also was die Infrastruktur kann.
50% Durchsatz ist wahrlich schlecht für einen Gig Port. Das schaffen auch einfachste Realtek Chipsets über die Rechner CPU immer.
Hi,
alles bisher mit TCP
Auf dem Server läuft iperf als Serverprozess,
bei den Klienten nutze ich JPerf 2.0.2
Alle Einstellungen im JPerf habe ich gelassen, ausser die Transmit-Dauer von 10 Sekunden auf 60 Sekunden gesetzt, und die Einheit
von KBits auf MBits eingestellt.
Standardeinstellungen bei Programmstart sind ausserdem Buffer Length 2 MBytes und TCP Windows Size 56 KBytes
Ich habe grade mal mit folgenden Optionen gemessen: Buffer Lenght auf 512 KBytes und TCP Windows Size ebenfalls auf 512 KBytes,
in Anlehnung an http://www.nwlab.net/art/iperf/ unter "Werte aus der Praxis",
Ergebnisse mit diesen Einstellungen, 3 Durchgänge a 60 Sekunden: 772, 770, 773 MBit/s
Deutlich besser.
Hab ich bei den Messungen vorher was falsch gemacht? Denke nicht, da die Einstellungen / Optionen ja verändert wurden, ich gehe davon aus daß in der Praxis die Buffer Lenght nicht 512 KBytes ist und die TCP Window Size auch nicht, bzw. welche Faktoren bestimmern das denn in der Praxis wenn meine Anwendung des Klienten Daten vom Server holt oder die dorthin schreiben möchte??
Der Vollständigkeit halber der Befehlt der letzten Messungen:
bin/iperf.exe -c 192.168.100.2 -P 1 -i 1 -p 5001 -w 512.0K -l 512.0K -f m -t 60
UDP:
Messung mit Einstellungen UDP Bandwith 1 MByte/sec UDP Buffer Size 41 KBytes UDP Pakt Size 1,500 Bytes (alles Standardeinstellungen so wie wenn man das Programm öffnet): bei 60 Messungen wurden 7.15 MBytes transferiert mit je 1.00 MBits/sec - es kommt eine Warnung: did not receive ack of last datagram after 10 tries. Sent 5103 datagrams - hier scheint was nicht zu stimmen... ? Habe nur eine Messung gemacht.
Gruß
alles bisher mit TCP
Auf dem Server läuft iperf als Serverprozess,
bei den Klienten nutze ich JPerf 2.0.2
Alle Einstellungen im JPerf habe ich gelassen, ausser die Transmit-Dauer von 10 Sekunden auf 60 Sekunden gesetzt, und die Einheit
von KBits auf MBits eingestellt.
Standardeinstellungen bei Programmstart sind ausserdem Buffer Length 2 MBytes und TCP Windows Size 56 KBytes
Ich habe grade mal mit folgenden Optionen gemessen: Buffer Lenght auf 512 KBytes und TCP Windows Size ebenfalls auf 512 KBytes,
in Anlehnung an http://www.nwlab.net/art/iperf/ unter "Werte aus der Praxis",
Ergebnisse mit diesen Einstellungen, 3 Durchgänge a 60 Sekunden: 772, 770, 773 MBit/s
Deutlich besser.
Hab ich bei den Messungen vorher was falsch gemacht? Denke nicht, da die Einstellungen / Optionen ja verändert wurden, ich gehe davon aus daß in der Praxis die Buffer Lenght nicht 512 KBytes ist und die TCP Window Size auch nicht, bzw. welche Faktoren bestimmern das denn in der Praxis wenn meine Anwendung des Klienten Daten vom Server holt oder die dorthin schreiben möchte??
Der Vollständigkeit halber der Befehlt der letzten Messungen:
bin/iperf.exe -c 192.168.100.2 -P 1 -i 1 -p 5001 -w 512.0K -l 512.0K -f m -t 60
UDP:
Messung mit Einstellungen UDP Bandwith 1 MByte/sec UDP Buffer Size 41 KBytes UDP Pakt Size 1,500 Bytes (alles Standardeinstellungen so wie wenn man das Programm öffnet): bei 60 Messungen wurden 7.15 MBytes transferiert mit je 1.00 MBits/sec - es kommt eine Warnung: did not receive ack of last datagram after 10 tries. Sent 5103 datagrams - hier scheint was nicht zu stimmen... ? Habe nur eine Messung gemacht.
Gruß
Du solltest am Client auch mit iPerf messen um nicht Äpfel mit Birnen usw.. Die GUI ist Java und das bringt manche Systeme aus dem Takt. Nur um jeglichen Overhead zu vermeiden der das Ergebnis beeinflussen kann.
770 Mbit ist realistisch und ein Wert mit dem man leben kann. Nicht perfekt aber gut.
Alles was drunter ist unter 700 ist eher schlecht.
Wenn messen dann immer UDP das ist am genauesten. Ein oder 2 fehlende ACKs sind nicht schlimm. Bei mehr solltest du dir aber Gedanken machen.
770 Mbit ist realistisch und ein Wert mit dem man leben kann. Nicht perfekt aber gut.
Alles was drunter ist unter 700 ist eher schlecht.
Wenn messen dann immer UDP das ist am genauesten. Ein oder 2 fehlende ACKs sind nicht schlimm. Bei mehr solltest du dir aber Gedanken machen.
Hi aqui,
OK, hab jetzt nochmal stichpunktartig "anders" gemessen. Auf dem Server läuft wie gehabt iperf als Server und auf dem Klienten habe ich per CMD manuell mit iperf gemessen, mit folgenden Messungen: 287, 304, 293, 276, 284, 284, 280, 268, 278, 279
Also wie man es dreht und wendet, ob mit iperf oder mit JPerf ist denke ich scheinbar, oder eigentlich offensichtlich egal. Auch wenn ich das durchaus nachvollziehen kann, daß eine Java-Anwendung anders agiert / reagiert als eine nicht Java-Anwendung. Allerdings misst JPerf denke ich auch nicht komplett anders wie iperf. JPerf basiert ja auf iperf.
Ich gebe dir auf alle Fälle so oder so Recht, daß alles unter 700 einfach schlecht ist.
Welche Parameter sollte ich denn für die Messung mit UDP verwenden? Ist das was ich mit der einen einzigen bisher durchgeführten Messung mit UDP gemessen habe OK? Also 60 Messungen 7.15 MBytes OK? Ist das ein guter Wert?
Und wie war das mit dem Thema was ich dich zuletzt fragte, Zitat von mir:
" Hab ich bei den Messungen vorher was falsch gemacht? Denke nicht, da die Einstellungen / Optionen ja verändert wurden, ich gehe davon aus daß in der Praxis die Buffer Lenght nicht 512 KBytes ist und die TCP Window Size auch nicht, bzw. welche Faktoren bestimmern das denn in der Praxis wenn meine Anwendung des Klienten Daten vom Server holt oder die dorthin schreiben möchte??"
Danke dir!
OK, hab jetzt nochmal stichpunktartig "anders" gemessen. Auf dem Server läuft wie gehabt iperf als Server und auf dem Klienten habe ich per CMD manuell mit iperf gemessen, mit folgenden Messungen: 287, 304, 293, 276, 284, 284, 280, 268, 278, 279
Also wie man es dreht und wendet, ob mit iperf oder mit JPerf ist denke ich scheinbar, oder eigentlich offensichtlich egal. Auch wenn ich das durchaus nachvollziehen kann, daß eine Java-Anwendung anders agiert / reagiert als eine nicht Java-Anwendung. Allerdings misst JPerf denke ich auch nicht komplett anders wie iperf. JPerf basiert ja auf iperf.
Ich gebe dir auf alle Fälle so oder so Recht, daß alles unter 700 einfach schlecht ist.
Welche Parameter sollte ich denn für die Messung mit UDP verwenden? Ist das was ich mit der einen einzigen bisher durchgeführten Messung mit UDP gemessen habe OK? Also 60 Messungen 7.15 MBytes OK? Ist das ein guter Wert?
Und wie war das mit dem Thema was ich dich zuletzt fragte, Zitat von mir:
" Hab ich bei den Messungen vorher was falsch gemacht? Denke nicht, da die Einstellungen / Optionen ja verändert wurden, ich gehe davon aus daß in der Praxis die Buffer Lenght nicht 512 KBytes ist und die TCP Window Size auch nicht, bzw. welche Faktoren bestimmern das denn in der Praxis wenn meine Anwendung des Klienten Daten vom Server holt oder die dorthin schreiben möchte??"
Danke dir!
ob mit iperf oder mit JPerf ist denke ich scheinbar, oder eigentlich offensichtlich egal.
Ja das stimmt..leider ! Es ist immer gleich schlecht 
Allerdings misst JPerf denke ich auch nicht komplett anders wie iperf. JPerf basiert ja auf iperf.
Das ist richtig ! Ging nur darum beim messen absolut gleiche Bedingungen zu schaffen um Verfälschungen sicher auszuschliessen.Welche Parameter sollte ich denn für die Messung mit UDP verwenden?
Ganz einfach: Den Schalter -u in der Kommandozeile Die Hilfe Funktion (oder Dr. Google) helfen da für die Syntax !https://www.thomas-krenn.com/de/wiki/TCP_und_UDP_Netzwerk_Performance_mi ...
Gilt für NetIO und iPerf !
Ggf. auch mal mit mehreren Streams messen ob das nochwas verändert.
Was deinen Fragen anbetrifft hast du nix falsch gemacht. iPerf und NetIO messen ertsmal nur was physisch auf dem Draht möglich ist.
Dann kommen weitere Faktoren dazu wie Framsize z.B. SMB/CIFS ist ein sehr unökonomische Protokoll was sehr viele kleine Frames benutzt. Viele Billigswitches im Consumer Sektor sind aber da gerade schlecht was die Forwarding Rate anbetrifft. Langsame Platten und Plattencontroller machen ein übriges. Da kann man also noch mit weiteren Einschränkungen rechnen. Die sind dann aber nicht mehr Netzwerk abhängig.
Es gilt mit den Messungen ja erstmal primär das netzwerk auszuschliessen oder zu bestimmen ob es an der Transport Infrastruktur als solchem liegt.
Leider scheint das bei dir der Fall zu sein. Solch eine grottenschlechte Performance auf dem Netz selber ist ganz sicher nicht nromal. Das ist klar das da alles im Schneckentempo agiert bei dir.
Das Problem zu lösen ist also oberste Priorität.
Hallo,
wollte nur mal kurz einen Status da lassen.
Mein Chef hat sich eingeschaltet und der hat wiederrum eine uns schon bekannt EDV-Firma aktiviert, ich arbeite also aktuell mit denen zusammen an dem Problem. Ich war anfang dieser Woche nicht da und konnte nicht weiter machen, allerdings hatte ich zuletzt vor einer Woche, also Freitags mit denen telefonisch Kontakt und seitdem hat sich keiner mehr gemeldet. Es läuft also nicht ganz so in dem Sinne wie es mein Chef erwartet hat. Aber egal, das nur nebenbei, Politik und Philosophie ist ja hier nicht das Thema. Ich werde jedenfalls montags je nach dem was ich sonst halt so machen muss mal nachfragen was los ist und ob es neue Erkenntnisse gibt oder nicht...
Was ich zur Sache noch sagen kann, wenn ich zwischen zwei (beliebigen) Klienten mit iperf / Jperf messe habe ich auch dann sehr schlechte Werte, also egal ob ich vom Klient zum Server messe, in der Live-Umgebung mit Switchen usw oder Back-2-Back oder vom Klient zum Klient mit Switch die Werte sind schlecht und ich komme nie über 500 MBit/s - ich frage mich von daher, ob die Messmethode falsch ist.
Gruß
wollte nur mal kurz einen Status da lassen.
Mein Chef hat sich eingeschaltet und der hat wiederrum eine uns schon bekannt EDV-Firma aktiviert, ich arbeite also aktuell mit denen zusammen an dem Problem. Ich war anfang dieser Woche nicht da und konnte nicht weiter machen, allerdings hatte ich zuletzt vor einer Woche, also Freitags mit denen telefonisch Kontakt und seitdem hat sich keiner mehr gemeldet. Es läuft also nicht ganz so in dem Sinne wie es mein Chef erwartet hat. Aber egal, das nur nebenbei, Politik und Philosophie ist ja hier nicht das Thema. Ich werde jedenfalls montags je nach dem was ich sonst halt so machen muss mal nachfragen was los ist und ob es neue Erkenntnisse gibt oder nicht...
Was ich zur Sache noch sagen kann, wenn ich zwischen zwei (beliebigen) Klienten mit iperf / Jperf messe habe ich auch dann sehr schlechte Werte, also egal ob ich vom Klient zum Server messe, in der Live-Umgebung mit Switchen usw oder Back-2-Back oder vom Klient zum Klient mit Switch die Werte sind schlecht und ich komme nie über 500 MBit/s - ich frage mich von daher, ob die Messmethode falsch ist.
Gruß
und ich komme nie über 500 MBit/s - ich frage mich von daher, ob die Messmethode falsch ist.
Mit iPerf bitte einmal mit mehreren "Streams" messen und dann noch einmal sehen was passiert, denn das ist auch manchmal das Problem,dass man mit iPerf nicht die Leitung mit nur einem "Stream" gar nicht "voll ausfüllt"!
Gruß
Dobby
Hi Dobby,
ich hatte weiter oben ja schon geschrieben und gefragt ob ich was falsch mache respektive was falsch messe oder mit falschen Einstellungen messe...?
Jetzt sagst du, daß ich in iperf / Jperf andere Einstellungen verwenden soll, das wäre ja wieder so wie ich es nicht wollte bzw inwiefern kann man denn dann die Ergebnisse in die Praxis übertragen? Ich will doch nicht nur am Iperf so weit rumstellen daß ich dann Ergebnisse über 900 MBit/s herausbekomme, ich will eher faktisch wissen, was auf der Leitung geht. Und wenn nix geht oder eben zu wenig, dann muss die Ursache gefunden werden.
Ich zitiere mich selbst:
" Hab ich bei den Messungen vorher was falsch gemacht? Denke nicht, da die Einstellungen / Optionen ja verändert wurden, ich gehe davon aus daß in der Praxis die Buffer Lenght nicht 512 KBytes ist und die TCP Window Size auch nicht, bzw. welche Faktoren bestimmern das denn in der Praxis wenn meine Anwendung des Klienten Daten vom Server holt oder die dorthin schreiben möchte??"
Frage ist also, ob iperf mir praxisnahe Werte meldet oder nicht. Welche Einstellungen verwenden denn andere Programme und Dienste auf Klienten wenn sie auf den Server schreiben oder von dort lesen? Welchen Werten im iperf entspricht das?
Und nochmal, warum wird in der Praxis stets iperf benutzt wenn es nur mit Einstellungen gute Werte liefert?
Freilich gibt es sicher auch Admins und deren Netzwerke die einfach iperf starten ohne Werte zu verändern und es kommen Werte über 900 MBit/s raus, aber ich bin sicher nicht der einzige und wir haben hier sicher nicht das einzige Netzwerk, wo ich mit Standardwerten im iperf schlechte Werte messe.
Ich ging bisher davon aus, iperf ausführen ohne was einstellen zu müssen und schauen was es misst,
jetzt scheint es mittlerweile so zu sein daß ich richtig messen soll, also hab ich was falsch gemacht. Ich dachte ich mache iperf auf und starte es und habe ein neutrales kleines Werkzeug was mir immer unter unveränderten Bedingungen meine Geschwindigkeiten misst.
ich hatte weiter oben ja schon geschrieben und gefragt ob ich was falsch mache respektive was falsch messe oder mit falschen Einstellungen messe...?
Jetzt sagst du, daß ich in iperf / Jperf andere Einstellungen verwenden soll, das wäre ja wieder so wie ich es nicht wollte bzw inwiefern kann man denn dann die Ergebnisse in die Praxis übertragen? Ich will doch nicht nur am Iperf so weit rumstellen daß ich dann Ergebnisse über 900 MBit/s herausbekomme, ich will eher faktisch wissen, was auf der Leitung geht. Und wenn nix geht oder eben zu wenig, dann muss die Ursache gefunden werden.
Ich zitiere mich selbst:
" Hab ich bei den Messungen vorher was falsch gemacht? Denke nicht, da die Einstellungen / Optionen ja verändert wurden, ich gehe davon aus daß in der Praxis die Buffer Lenght nicht 512 KBytes ist und die TCP Window Size auch nicht, bzw. welche Faktoren bestimmern das denn in der Praxis wenn meine Anwendung des Klienten Daten vom Server holt oder die dorthin schreiben möchte??"
Frage ist also, ob iperf mir praxisnahe Werte meldet oder nicht. Welche Einstellungen verwenden denn andere Programme und Dienste auf Klienten wenn sie auf den Server schreiben oder von dort lesen? Welchen Werten im iperf entspricht das?
Und nochmal, warum wird in der Praxis stets iperf benutzt wenn es nur mit Einstellungen gute Werte liefert?
Freilich gibt es sicher auch Admins und deren Netzwerke die einfach iperf starten ohne Werte zu verändern und es kommen Werte über 900 MBit/s raus, aber ich bin sicher nicht der einzige und wir haben hier sicher nicht das einzige Netzwerk, wo ich mit Standardwerten im iperf schlechte Werte messe.
Ich ging bisher davon aus, iperf ausführen ohne was einstellen zu müssen und schauen was es misst,
jetzt scheint es mittlerweile so zu sein daß ich richtig messen soll, also hab ich was falsch gemacht. Ich dachte ich mache iperf auf und starte es und habe ein neutrales kleines Werkzeug was mir immer unter unveränderten Bedingungen meine Geschwindigkeiten misst.
