Warum erhalte ich 950 Mbit / s, aber nur 360 Mbit / s bei Gigabit-Ethernet?

Ich habe zwei Desktop-Computer direkt miteinander sprechen. Beide verfügen über Gigabit-Ethernet-fähige Netzwerkadapter. Das sind 1 Gbit / s oder 1000 Mbit / s. Ich habe sie verbunden mit einem brandneuen 10 Meter langen Cat6 UTP gerade Kabel und ich ziemlich nah an diesem theoretischen Maximum. Der Windows Task-Manager (Registerkarte "Netzwerk") zeigt 844 - 946 Mbit / s in eine Richtung an. In der anderen Richtung werden jedoch nur 326 - 365 Mbit / s angezeigt.

Local: 192.168.100.152
Remote: 192.168.100.151

Auf dem lokalen Computer wird Windows 8.1 Pro ausgeführt, und ich habe eine Remoteverbindung mit dem anderen Computer hergestellt, auf dem Windows Vista Ultimate ausgeführt wird.

Iperf Ergebnisse

Ich habe Iperf benutzt, um ein paar Tests durchzuführen. Ich habe den Test jedes Mal 60 Sekunden lang durchgeführt. Ich habe den Test 10 Mal für jede Kommunikationsrichtung durchgeführt. Ich habe dann diese Tabelle mit Testergebnissen zusammengestellt, um einen Durchschnitt zu erhalten.

192.168.100.152 -> 192.168.100.151          106 MB/s
192.168.100.152 -> 192.168.100.151          107 MB/s
192.168.100.152 -> 192.168.100.151          108 MB/s
192.168.100.152 -> 192.168.100.151          107 MB/s
192.168.100.152 -> 192.168.100.151          107 MB/s
192.168.100.152 -> 192.168.100.151          104 MB/s
192.168.100.152 -> 192.168.100.151          101 MB/s
192.168.100.152 -> 192.168.100.151          108 MB/s
192.168.100.152 -> 192.168.100.151          108 MB/s
192.168.100.152 -> 192.168.100.151          108 MB/s
----------------------------------------------------
Min: 101 MB/s    Max: 108 MB/s    Avg: 106.4 MB/s (851.2 Mbps)

192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.0 MB/s
192.168.100.152 <- 192.168.100.151          41.0 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.0 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
-----------------------------------------------------
Min: 41.0 MB/s    Max: 41.1 MB/s    Avg: 41.07 MB/s (328.56 Mbps)

Meine Frage ist, warum ist es in die andere Richtung so viel langsamer?

Windows Task-Manager

Dies ist das Netzwerkdiagramm, das bei der Durchführung der Tests in Iperf angezeigt wird.

Beachten Sie das Diagramm in den folgenden beiden Screenshots!

Haben Sie bemerkt, wie es von "1 Gbit / s" auf "500 Mbit / s" in der oberen rechten Ecke gewechselt ist, als ich vom Senden zum Empfangen von Daten gewechselt bin? Warum hat es das getan? Erkennt es irgendwie, dass der andere Netzwerkport die Hälfte von 1 Gbit / s ist, wenn er in die eine Richtung geht, aber dennoch voll, wenn er in die andere Richtung geht?

Dateiübertragungstest

Ich habe noch einige Tests mit einer Datendatei durchgeführt, um realistischere Messungen von Festplatte zu Festplatte zu erzielen. Zu diesem Zweck habe ich eine 1 GB-Datei erstellt. Ich habe nur standardmäßige Windows-Dateifreigabefunktionen verwendet. Vom lokalen Computer aus stellte ich eine Verbindung zur C $ -Freigabe auf dem Remotecomputer her und zog die Datei zwischen sich hin und her (Seilspringen), wobei ich den Dateinamen jedes Mal änderte. Ich habe alles nach besten Kräften geplant und das habe ich bekommen.

192.168.100.152 -> 192.168.0.151    1073741824 Byte    25 s    40,96 MB/s
192.168.100.152 -> 192.168.0.151    1073741824 Byte    20 s    51.2 MB/s
192.168.100.152 -> 192.168.0.151    1073741824 Byte    16 s    64 MB/s
192.168.100.152 -> 192.168.0.151    1073741824 Byte    16 s    64 MB/s
192.168.100.152 <- 192.168.0.151    1073741824 Byte    11 s    93.091 MB/s
192.168.100.152 <- 192.168.0.151    1073741824 Byte    34 s    30.118 MB/s
192.168.100.152 <- 192.168.0.151    1073741824 Byte    11 s    93.091 MB/s
192.168.100.152 <- 192.168.0.151    1073741824 Byte    11 s    93.091 MB/s

Der im Windows-Dateikopiediagramm angegebene Durchsatz erzählt eine andere Geschichte. Hier lade ich zwei Dateien nacheinander an zwei verschiedenen Orten auf derselben Festplatte herunter. Die erste Kopie zeigte, dass 107 MB / s bis zu 41% erhalten blieben, und die zweite Kopie zeigte, dass 98,9 MB / s bis zu 87% erhalten blieben.

Das stimmt also mit den Ergebnissen überein, die ich mit dem Iperf-Tool erzielt habe. Nun, hier ist, wie es aussieht, wenn ich auf den Remote-Computer hochlade.

Es hält 103 MB / s bei bis zu 73% und erreicht stinkende 27,3 MB / s bei 82% und erreicht 49,1 MB / s bei 93%.

Hier sind zwei weitere lustige "Achterbahn" -Diagramme.

Update 1 - Verbindungsgeschwindigkeit

Ich habe versucht, den WLAN-Adapter auf dem Remotecomputer zu deaktivieren. (Der WLAN-Adapter war auf dem lokalen Computer bereits deaktiviert.) Ich denke, das hat Timtech mit diesem Kommentar gemeint. Ich hatte den gleichen Gedanken: Wenn sowohl kabelgebundene als auch kabellose Adapter gleichzeitig aktiviert sind, wird der Durchsatz des kabelgebundenen Adapters auf die Stufe des WLAN-Adapters begrenzt (Anpassung an den langsamsten Adapter aus Kompatibilitätsgründen). Weil der WLAN-Adapter (in diesem Fall DWA-160 Wireless N) vom Vista-Computer normalerweise als "52 Mbps" - "104 Mbps" -Verbindung erkannt wird.

In der folgenden Abbildung wird der Remotecomputer als Server und der lokale Computer als Client eingerichtet (192.168.100.152 <- 192.168.100.151).

Das Trennen des WLAN-Adapters auf dem Remotecomputer half jedoch nicht bei meinem geringen Durchsatz bei meiner Kabelverbindung.

Nicht nur das! Im Windows Task-Manager auf dem Remotecomputer wird die Verbindungsgeschwindigkeit für den verkabelten Adapter (LAN 1) als "1 Gbit / s" angezeigt. Wenn Sie sich auf die Screenshots oben beziehen, können Sie sehen, dass es als "500 Gbit / s" -Link auf dem lokalen Computer erkannt wird. Für dieselbe kabelgebundene Verbindung sagt Windows Vista, dass es sich um eine 1-Gbit / s-Verbindung handelt, während Windows 8.1 Pro für eine 500-Gbit / s-Verbindung steht.

So sieht es auf dem Remotecomputer aus, wenn ich ihn als Client und den lokalen Computer als Server einrichte (192.168.100.152 -> 192.168.100.151).

Wie Sie hier sehen können, werden ca. 95% der 1-Gbit / s-Verbindung genutzt. Das entspricht 950 Mbit / s. Es ist genau das, was ich im Test oben bekommen habe. Aber umgekehrt ist eine ganz andere Geschichte.

Update 2 - Duplexing und MDI-X

Wie von einigen von Ihnen vorgeschlagen, habe ich mir die Duplexeinstellungen angesehen. Sowohl der lokale als auch der Remote-Computer wurden in den automatischen Aushandlungsmodus versetzt, wie Sie in den folgenden Screenshots sehen können.

Ich habe versucht, auf beiden Computern auf "1.0 Gbit / s Vollduplex" umzustellen. Ich habe dann die gleichen Tests wie zuvor mit Iperf durchgeführt. Mit einem lokalen Computer als Server und einem entfernten Computer als Client erhalte ich max. 950 Mbit / s. Mit einem lokalen Computer als Client und einem entfernten Computer als Server erhalte ich ungefähr 360 Mbit / s.

Hier sehen Sie diese Screenshots.

Was Sie hier sehen, ist das Diagramm für das Hoch- und Herunterladen zwischen den beiden Computern. Der höhere Graph (95 - 98% Auslastung) ist lokal zu fern (Upstream 192.168.100.152 -> 192.168.100.151). Der untere Graph (~ 33% Auslastung) ist von lokal zu lokal entfernt (stromabwärts 192.168.100.152 <- 192.168.100.151).

Um Probleme mit Auto MDI-X auszuschließen, habe ich einen dieser Crossover-Adapter an einem Ende des Kabels (dem lokalen Computer) angeschlossen.

Das würde das Kabel sicher zu einem Crossover-Kabel machen. Verdammt, ich habe es sogar mit einem Netzwerktester testen lassen! Es ist in der Tat jetzt gekreuzt (Stifte 1/3, 2/6)!

Jetzt habe ich also eine echte Crossover-Kabelverbindung zwischen den beiden Computern und ich habe manuell "1,0 Gbit / s Vollduplex" eingestellt. Trotzdem habe ich immer noch das gleiche Problem. Noch mehr Ideen? Neben der Aktualisierung des Vista-Computers (oder Neuinstallation des 8.1-Computers)?

Update 3 - Software- oder Hardwarebeschränkung?

Ich vermute, dass ich zwei Betriebssysteme habe, die nicht miteinander kompatibel sind. Sie sind beide Windows-Systeme, aber nicht alle Windows-Systeme sind gleich. Ich muss versuchen, Vista auf beiden oder 8.1 Pro auf beiden zu verwenden und zu sehen, welche Art von Durchsatz ich erhalte. Das bedeutet, ein Upgrade zu kaufen. Verdammt du Microsoft.

Beide Computer sind übrigens maßgefertigt. Hier sind einige Spezifikationen.

Local
-----
Gigabyte GA-EP45-UD3R
Intel Core 2 Quad Q9650
Intel P45
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Realtek 8111C chips (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows 8.1 Pro 64-bit

Remote
------
Gigabyte GA-X38-DQ6
Intel Core 2 Duo E4500
Intel X38
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Dual Realtek 8111B chip (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows Vista Ultimate 64-bit

Tonny schlug vor, dass der Vista-Computer möglicherweise einen schlechten Realtek-Chip verwendet. Also habe ich diese Spezifikationen ausgegraben. Ich sehe jetzt, dass der Vista-Rechner eine B-Revision von 8111 verwendet, während der lokale Rechner eine C-Revision desselben Chips verwendet. Bedeutet das etwas? Beide sind vom Hersteller eindeutig für 1000 Mbit (so) spezifiziert. Könnte es sein, dass 8111B so viel schlechter abschneidet (360 Mbit / s)?

Diese Laufwerke erreichen eine Burst-Rate von 107 MB / s. Das ist genau die Nummer, die ich im Test auf dem lokalen Computer gesehen habe. Aber selbst das dauerhafte sequentielle oder zufällige Lesen / Schreiben von möglicherweise 55 MB / s bedeutet NICHT 360 Mbit / s. Das sollte mir ungefähr 440 Mbit / s und nicht die 360 ​​Mbit / s bringen, die ich bekomme. Ich vermute also nicht, dass dies der Engpass ist, zumal beide dasselbe Laufwerksmodell verwenden. Außerdem ist der Dateikopiervorgang eine Sache, aber Iperf verwendet überhaupt keine Festplatten, sondern nur RAM-Speicher für die Tests.

Update 4 - TCP Checksum Offload

Wie von Tonny vorgeschlagen, habe ich versucht, das TCP-Prüfsummen-Offloading auszuschalten (für IPv4 und IPv6).

Ich habe auch "Speed ​​& Duplex" für beide Computer auf "Auto" zurückgestellt. Aber das hat nicht geholfen. Ich habe immer noch den geringen Durchsatz in der einen und den hohen in der anderen Richtung.

Update 5 - Neue Treiberversion

Ich habe versucht, die Treiberversion sowohl lokal als auch remote auf die neueste Version zu aktualisieren, die von der Gigabyte-Website und der Realtek-Website heruntergeladen wurde.

Update path...

On local (RTL8111C):
8.1.510.2013 (2013-05-10, Microsoft)
8.20.815.2013 (2013-08-15, Realtek)

On remote (RTL8111B):
6.241.623.2010 (2010-06-23, Realtek)
6.250.908.2011 (2011-09-08, Realtek)
6.252.1109.2012 (2012-11-09, Realtek)

Ich habe immer noch den gleichen miesen Durchsatz in eine Richtung.

Update 6 - CPU-Auslastung

Ich habe die CPU-Auslastung überprüft. Dies sollte kein Problem sein. Hier sind meine Erkenntnisse.

On local...

Download: 4 - 10 %
Upload:   4 - 10 %
Idle:     0 -  4 %

On remote...

Download: 24 - 38 %
Upload:   10 - 25 %
Idle:      1 -  6 %

Lokal (herunterladen, hochladen, inaktiv) ...

Remote (herunterladen, hochladen, im Leerlauf) ...

Die Fernbedienung verbraucht viel mehr CPU-Leistung, aber dies ist auch die mit dem langsameren Core 2 Duo. Bei meinen Tests hat es den Wert von 38% jedoch nie überschritten. Was hier besonders interessant ist, ist, dass es beim Herunterladen (lokal -> remote) so viel mehr CPU-Leistung verbraucht als beim Hochladen (lokal <- remote).

Bei einem Durchsatz von 950 Mbit / s werden 38% und bei 360 Mbit / s 25% verwendet. Auch die Kernauslastung ist nicht ausgewogen, es wird ein Kern mehr als der andere verwendet. Ich bin mir nicht sicher, welche Schlussfolgerung ich daraus ziehen soll. Der lokale Computer zeigt keine Core-Auslastung an, daher kann ich ihn nicht vergleichen. Die CPU-Auslastung ist jedoch sogar auf dem lokalen Computer (10% beim Herunterladen / Hochladen).

Update 7 - Neuer Intel Gigabit-Netzwerkadapter

Ich habe jetzt einen brandneuen PCI-Express Gigabit-Netzwerkadapter von Intel als Ersatz für den eingebauten Realtek RTL8111B auf dem Remote-Computer installiert, der beim Hochladen angeblich zu langsam ist. Die Produktnummer des Intel Adapters lautet EXPI9301CT. Dieser Adapter soll laut Bewertungen, die ich gelesen habe, sehr gut sein. Ich möchte dies nur als möglichen Engpass ausschließen.

Ich habe jetzt einige Tests mit Iperf für Windows durchgeführt und hier sind die Ergebnisse.

Lokal (herunterladen, hochladen) ...

Remote (herunterladen, hochladen) ...

Im Durchschnitt ist dieser Adapter tatsächlich etwas langsamer als der Realtek-Adapter. Ich denke, es hat einen geringeren Overhead als der Realtek und als Ergebnis davon einen stabileren kontinuierlichen Durchsatz. Aber selbst mit diesem Intel-Adapter erhalte ich immer noch nur etwa 360 Mbit / s in die eine und 950 Mbit / s in die andere Richtung.

local: 192.168.100.152 (win 8, realtek 8111c)
remote: 192.168.100.154 (vista, intel desktop ct)

192.168.100.152 -> 192.168.100.154    113 MB/s
192.168.100.152 -> 192.168.100.154    104 MB/s
192.168.100.152 -> 192.168.100.154    103 MB/s
192.168.100.152 -> 192.168.100.154    104 MB/s
192.168.100.152 -> 192.168.100.154    102 MB/s
192.168.100.152 -> 192.168.100.154    104 MB/s
192.168.100.152 -> 192.168.100.154    101 MB/s
192.168.100.152 -> 192.168.100.154    102 MB/s
192.168.100.152 -> 192.168.100.154    101 MB/s
192.168.100.152 -> 192.168.100.154    104 MB/s
----------------------------------------------
Max: 113 MB/s    Min: 101 MB/s    Avg: 103.8 MB/s

192.168.100.152 <- 192.168.100.154    42.2 MB/s
192.168.100.152 <- 192.168.100.154    41.2 MB/s
192.168.100.152 <- 192.168.100.154    41.1 MB/s
192.168.100.152 <- 192.168.100.154    43.0 MB/s
192.168.100.152 <- 192.168.100.154    42.3 MB/s
192.168.100.152 <- 192.168.100.154    42.3 MB/s
192.168.100.152 <- 192.168.100.154    40.2 MB/s
192.168.100.152 <- 192.168.100.154    40.9 MB/s
192.168.100.152 <- 192.168.100.154    41.3 MB/s
192.168.100.152 <- 192.168.100.154    42.0 MB/s
-----------------------------------------------
Max: 43.0 MB/s    Min: 40.2 MB/s    Avg: 41.65 MB/s

Ich habe keine Ahnung, warum es bei 113 MB / s im ersten Testlauf, lokal zu Remote, seinen Höchststand erreicht hat. Diese Geschwindigkeit wurde während des gesamten Testlaufs beibehalten. Die Grafik war mit 113 MB / s nahezu flach. Wie zuvor habe ich für jeden Lauf ein Intervall von 60 Sekunden verwendet. Beim nächsten Durchlauf fiel er jedoch auf 104 MB / s.

Wie Sie an diesen Werten erkennen können, habe ich mit diesem Intel-Adapter immer noch den gleichen Durchsatz wie mit dem eingebauten Realtek-Adapter. Ich kann also mit Sicherheit sagen, dass es nichts mit dem Adapter selbst zu tun hat. Wir können also aufhören, den RTL8111B als minderwertigen / geringeren Chip als den RTL8111C auf dem anderen Motherboard zu bezeichnen. Dies ähnelt immer mehr einem Software- / Betriebssystem- / Konfigurationsproblem oder allen drei Dingen auf einmal.

Update 8 - Tolle Ergebnisse mit Ubuntu LINUX

Nachdem ich alle anderen Optionen ausgeschöpft hatte, entschied ich mich schließlich, einige Tests mit Linux durchzuführen, und ich bekam großartige Ergebnisse. Ich habe ein Ubuntu Linux 13.10 Live-System und Iperf für Linux (Version 2.0.5-3) sowohl auf dem lokalen als auch auf dem Remote-Computer verwendet. Hier sind die Ergebnisse.

=======================================================
REALTEK 8111C <-> REALTEK 8111B | IPERF ON UBUNTU LINUX
=======================================================

local: 192.168.100.152
remote: 192.168.100.151

192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
----------------------------------------------
Max: 112 MB/s    Min: 112 MB/s    Avg: 112 MB/s

192.168.100.152 <- 192.168.100.151    110 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    110 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
----------------------------------------------
Max: 111 MB/s    Min: 110 MB/s    Avg: 110.8 MB/s

Lokal (herunterladen, hochladen, inaktiv) ...

Wie Sie sehen, erhalte ich unter Ubuntu den gleichen Durchsatz in beide Richtungen. Liegt es daran, dass ich auf beiden Computern dasselbe Betriebssystem verwende, oder ist das etwas anderes? Bekomme ich den gleichen Durchsatz, wenn auf beiden Computern die gleichen Windows-Versionen eingerichtet wären? Ich verstehe nicht, warum es wichtig wäre, wenn ich auf einem Computer eine leicht veraltete Windows-Version, nämlich Vista, und auf dem anderen die neueste Version, verwende. Ich meine, Vista ist immer noch ein aktuelles und unterstütztes Betriebssystem, das von Microsoft gesichert wird . Windows XP ist eine andere Geschichte.

Aber ich weiß, dass sie alles tun, um Vista zu töten. Beispielsweise wird das neueste Office 2013 unter Windows Vista absichtlich nicht unterstützt. Ich bin sicher, Microsoft wünscht sich, dass Vista nie passiert ist. Genau wie sie sich wünschen werden, dass Windows 8.0 noch nie passiert ist. Aber ich bin normalerweise genauso hartnäckig wie sie und aktualisiere meine Windows-Installationen erst, wenn ich es unbedingt muss.

Die Frage ist also, wie mit zwei verschiedenen Windows-Versionen derselbe Durchsatz in beide Richtungen erzielt werden kann. Windows Vista sollte Gigabit-fähig sein - es ist kein 20 Jahre altes Betriebssystem oder so, es ist nicht Windows 95, von dem wir sprechen. Vista ist ein modernes Betriebssystem. Ich habe noch nicht getestet, ob auf beiden Computern dieselbe Windows-Version ausgeführt wird. Möglicherweise besteht ein Unterschied in der TCP-Implementierung oder zwischen den beiden Betriebssystemversionen. Wenn ja, dann werde ich wahrscheinlich gezwungen sein, die Vista-Maschine zu aktualisieren. Entweder das oder auf Linux umsteigen. Ich bin nicht bereit, mehr für weniger zu bezahlen. Warum sollte ich Windows aktualisieren müssen, um den Gigabit-Durchsatz in beide Richtungen zu erzielen? ...

Update 9 ...

Kabel

Ich habe versucht, das Kabel umzukehren. Ich habe die gleichen Ergebnisse wie zuvor. Ich habe auch ein neues Cat 6 Patchkabel bekommen und dieses ausprobiert. Die Durchsatztestergebnisse waren die gleichen. Das Kabel ist hier also nicht das Problem. Ich habe nur vorkonfektionierte Patchkabel verwendet. Die Verkabelung sollte also korrekt sein. Ich plane jedoch, meine eigenen Installationskabel später zu terminieren.

FW und AV

Für Firewall (FW) und Anti-Virus (AV) verwende ich keine FW- oder AV-Software von Drittanbietern. Ich habe nur die Windows Firewall und die Security Essentials. Ich habe beide auf beiden Maschinen deaktiviert. Die Durchsatztestergebnisse waren die gleichen wie zuvor.

LAN-Geschwindigkeitstest

Ich habe LAN Speed ​​Test Lite 1.3 auf dem lokalen Computer installiert. Ich glaube, dass der Test zwischen dem Speicher auf lokalem und dem Festplattenlaufwerk auf Fernmaschine durchgeführt wird. Ich bin mir nicht sicher. Es wird jedoch nach einem Freigabepfad auf dem Remote-Computer gefragt. Ich habe o $ share auf der Fernbedienung verwendet.

Upload: 427 Mbps
Download: 420 Mbps

Ich vertraue diesen Ergebnissen nicht zu sehr. Wenn Sie sich das Diagramm ansehen, können Sie feststellen, dass es während des Tests sehr unterschiedlich ist. Der Test war ein "sukzessiver" Test, dh zuerst einen Test schreiben (hochladen) und dann einen Test lesen (herunterladen). Wenn Sie einen gleichzeitigen Upload- / Download-Test durchführen, ist der Gesamtdurchsatz offensichtlich geringer. Aber solche Tests interessieren mich nicht. Bisher habe ich nur "aufeinanderfolgende" Tests mit beiden Dateiübertragungstests in Windows (Filesharing / smb) und in Iperf durchgeführt.

Ich habe keine Speicher-zu-Speicher-Tests mit LAN Speed ​​Test durchgeführt, da ein Programm namens LST Server auf der Fernbedienung erforderlich ist und für dieses Programm eine Registrierung erforderlich ist, um es zu verwenden.

Update 10 ...

Festplattenlaufwerkstests

Ich habe Crystal Disk Mark 3.0.3 zum Testen der Festplatten verwendet. Hier sind die Ergebnisse.

Local disk: 118 MB/s read, 113 MB/s write
Remote disk: 70 MB/s read, 69 MB/s write

Dies sind sequentielle Lese- und Schreibgeschwindigkeiten basierend auf 5 Läufen und einer Last von 1000 MB.

Dies ist der lokale Datenträger (Datenträgermarkierung, Lesen, Schreiben) ...

Und das ist die Remote-Festplatte ...

Aber ich verstehe das nicht ... diese Ergebnisse scheinen widersprüchlich.

Okey, die lokale Festplatte kann mit 118 MB / s lesen, so dass der gemeldete Upload mit ca. 100 MB / s möglich wäre. Die entfernte Festplatte kann sie jedoch nicht empfangen, wenn sie nur mit einer Schreibgeschwindigkeit von 69 MB / s arbeiten kann. Aber durch eine magische Wendung bekomme ich im Durchschnitt immer noch etwas mehr als 100 MB / s Upload.

In die andere Richtung zu gehen ist sinnvoller. Wenn die entfernte Festplatte mit 70 MB / s lesen und die lokale Festplatte mit 113 MB / s schreiben kann, sollte der Download nicht schneller als 70 MB / s sein. Ich bekomme durchschnittlich ca. 40 MB / s Download. Das würde vernünftig erscheinen.

Daher kann ich aus diesen Ergebnissen keine Schlussfolgerung ziehen. Ich meine, das Laufwerk auf dem lokalen Computer wird kaum benutzt. Es ist auch die Festplatte, auf der sich das Betriebssystem befindet, und es ist die einzige Partition auf diesem System. Während die Remote-Festplatte fast voll ist, ist sie auch mit mehreren Partitionen partitioniert. Es wird jedoch nicht für das Betriebssystem verwendet. Ich habe hier den Laufwerksbuchstaben O:für den Test ausgewählt, da dies die Partition mit dem meisten freien Speicherplatz ist.

(Beachten Sie, dass ich C:in den vorherigen Tests einen Laufwerksbuchstaben verwendet habe, der sich auf einem vollständig separaten Seagate-Laufwerk befindet, auf dem sich das Betriebssystem auf dem Remotecomputer befindet. Daher sind diese Werte nicht vergleichbar.)

Schreibe Caching

Mit aktiviertem Disk Write Caching habe ich diese Ergebnisse erhalten.

Local to remote: 106 MB/s
Remote to local: 42.2 MB/s

Ich habe dann das Schreibcaching auf allen Laufwerken auf der Fernbedienung und auf dem lokalen Laufwerk deaktiviert.

Ich habe keinen Neustart durchgeführt, da kein Neustart erforderlich war, damit die Änderungen wirksam werden. Ich habe dann folgende Ergebnisse bekommen.

Local to remote: 106 MB/s
Remote to local: 42.1 MB/s

Es gab praktisch keine Veränderung. Kein Neustart und kein Neustart wurde angefordert.

QOS-Paket

Anschließend deaktivierte ich QOS Packet Scheduler für den entsprechenden Adapter auf dem Remotecomputer und dann auf dem lokalen Computer.

Local to remote: 107 MB/s
Remote to local: 41.9 MB/s

Keine wesentliche Änderung hier. Wieder wurde kein Neustart und kein Neustart angefordert.

Jumbopakete

Anschließend habe ich Jumbo-Pakete aktiviert, für die ich die 4-GB-Einstellung verwendet habe, da 4 KB die größte MTU-Größe ist, die auf beiden Computern unterstützt wird.

Local to remote: 105 MB/s
Remote to local: 33.3 MB/s

Hier war der Upload (lokal zu remote) nicht betroffen, aber der Download-Durchsatz wurde erheblich reduziert. Es wurde kein Neustart angefordert, aber ich entschied mich trotzdem, beide Computer neu zu starten, nur aus gutem Grund. Ich habe dann die gleichen Tests erneut durchgeführt und diese Ergebnisse erhalten.

Local to remote: 117 MB/s
Remote to local: 33.2 MB/s

Der Upload ist jetzt noch schneller, aber der Download ist immer noch langsamer als vor diesen Änderungen, auch nach dem Neustart. Ich hätte erwartet, dass beide ein wenig nach oben gehen. Was bedeutet das?

Basierend auf Ihrer Antwort:

@ewhac Die TCP-Fenstergröße auf dem lokalen Computer unterscheidet sich normalerweise von der Fenstergröße auf dem Remotecomputer. Der Standardwert ist 0.06 MB lokal (Win 8) und 0.01 MB remote (Vista). Müssen sie den gleichen Wert haben? Wie kann ich die MSS erraten? Wäre das der Schalter -m ("Maximale Segmentgröße drucken")? Normalerweise lege ich nichts davon fest. Warum sollte ich müssen? - Sammy 30. November um 21:39

Die Größe des TCP-Fensters gibt die maximale Datenmenge an, die der TCP-Stack vor dem Anhalten und Warten auf Bestätigungen vom Remotecomputer aus dem Kabel entfernt. Die Tatsache, dass das TCP-Fenster auf dem Vista-Computer viel kleiner ist als auf dem Windows Se7en-Computer, unterstützt die Theorie, dass Sie die Pipe nicht genug füllen, bevor Sie blockieren und auf ACKs warten.

Daher würde ich zuerst versuchen, die TCP-Fenstergröße auf dem Vista-Computer mithilfe des -wArguments zu erhöhen . 0,01 MB sind eine wenig hilfreiche Einheit. Ich schätze, es sind 16 KB. Beginnen Sie also mit 16 KB und führen Sie einen Test durch:

iperf -c -w 16K ...

Verdoppeln Sie die Fenstergröße und wiederholen Sie den Test:

iperf -c -w 32K ...

Hoffentlich solltest du einen Geschwindigkeitsanstieg beobachten. Verdoppeln Sie die Fenstergröße weiter, bis Sie keine signifikanten Geschwindigkeitssteigerungen mehr sehen.

Wie bereits erwähnt, müssen Sie die Größe des TCP-Fensters in iperf ändern, um über Hochgeschwindigkeitsverbindungen mit niedriger Latenz einen höheren Durchsatz zu erzielen. Verschiedene Versionen von Windows (oder iPerf) haben möglicherweise unterschiedliche Standardfenstergrößen. Versuchen Sie, mit "-w 256k" sowohl auf dem Client als auch auf dem Server zu beginnen.

Können Sie die Pfeilrichtung Ihrer Diagramme bestätigen? In iPerf werden Daten vom Client auf den Server übertragen (im Gegensatz zu dem, was ich normalerweise denke).

Sie können die Festplatten als Ursache ausschließen, da iPerf die Festplatten nicht berührt.

Ich denke, Sie haben bereits überprüft, ob Sie die neuesten NIC-Treiber verwenden. Es sollte nicht nötig sein, die Geschwindigkeit / Duplex manuell einzustellen. Das Gleiche gilt für Jumbo-Rahmen - sie sind den Aufwand mit moderner Hardware nicht wert.

Stellen Sie sicher, dass auf beiden NICs Large Send Offload (LSO) und Large Receive Offload (LRO) aktiviert sind. Einige NIC-Treiber verwenden unterschiedliche Namen (oder mehrere Optionen, die dieses Verhalten steuern), sodass Sie möglicherweise herumjagen müssen. Normalerweise sind sie standardmäßig alle aktiviert.

Ich denke, du musst ein bisschen mehr darüber lesen, wie iperf funktioniert. Wenn Sie nicht die richtige TCP-Fenstergröße einstellen, variieren Ihre Ergebnisse erheblich. Ich glaube, es ist der -w-Schalter. Diese Website hilft bei der Berechnung der optimalen TCP-Fenstergröße. Sie müssen die RTT und die Bandbreite kennen, um sie berechnen zu können. http://www.kehlet.cx/docs/tcpwin.php

Probieren Sie auch andere Tools wie "LAN Speed ​​Test" lite aus, mit denen Übertragungen zwischen Freigaben an beiden Enden durchgeführt werden können. Die Ergebnisse sind in den Tests, die damit durchgeführt wurden, ziemlich ähnlich. Stellen Sie außerdem sicher, dass Sie die maximale Geschwindigkeit Ihrer Festplatten überprüfen.

Ein paar Punkte, die Ihnen helfen können. Der TCP-IP-Stack ist jetzt in Versionen nach Windows 7 anders implementiert. Ich würde mir meine TCP-Optimierungen genau ansehen. Möglicherweise liegt nicht viel zwischen Ihren beiden Boxen, aber es lohnt sich immer noch, einige Einstellungen an Ihrer Vista-Box zu ändern.

Die Verwendung von netsh int tcp set global congestionprovider = ctcp wurde abgeschrieben. Um den Überlastungsprovider festzulegen oder zu ändern, muss der folgende Befehl verwendet werden:

Lesen Sie den Artikel hier: http://forums.speedguide.net/showthread.php?280646-When-will-TCP-Optimizer-support-Windows-8-amp-Windows-Server-2012

Geben Sie dann Folgendes ein : netsh int tcp set additional custom

Für weitere Details zum obigen Befehl geben Sie einfach Folgendes ein : netsh int set additionalal

Um zu überprüfen, welchen Engpassanbieter Sie derzeit verwenden, verwenden Sie Folgendes: netsh int tcp show additionalal

Aber nur Win Server 2012 kann benutzerdefinierte Vorlagen erstellen. CTCP ist möglicherweise ein Problem.

Auch die automatische Skalierung könnte ein Faktor sein.

Vielleicht lohnt es sich, einen Blick auf Ihre Treiber zu werfen, die möglicherweise ein Upgrade / Downgrade benötigen. sehen, welche am besten funktionieren.

Ein anderer Gedanke ist, dass Paketgrößen auf die Festplatte geschrieben werden. Wie groß sind Ihre Festplattensektoren, die auf 512 bis 64 KB formatiert sind. Dies kann ein Engpass beim Zwischenspeichern sein.

Haben Sie sich die Aktivierung von Jumbo-Paketen angesehen (wenn dies auf Ihre Netzwerkkarten zutrifft)?

Tolle Ergebnisse mit Ubuntu LINUX

Das kommt mir bekannt vor ... unter iperfWindows ist die Leistung unerklärlich schlecht , aber unter Linux funktioniert dieselbe Hardware einwandfrei.

Nachdem ich diesen Kampf immer wieder geschlagen habe, bin ich zu dem Schluss gekommen, dass iperfWindows schuppig ist . Ich weiß nicht warum ... ehrlich gesagt, ich habe aufgehört mich zu kümmern, weil ich weiß, dass ich unter Linux immer vernünftige Ergebnisse erzielen kann.

Wenn Sie also wissen möchten, warum Sie eine so schlechte Leistung erzielen, schauen Sie nicht weiter als bis zur Anwendung.

Sie sollten versuchen, den MMCSS-Dienst zu beenden. Ja, Sie werden Ihr Audio vorübergehend verlieren, aber es kann sein, dass etwas es aktiviert, wodurch die Netzwerkaktivität gedrosselt wird, damit die Netzwerkaktivität andere Aktivitäten nicht übertönt.

Weitere Informationen zu MMCSS und Netzwerkeinschränkungen finden Sie hier: http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx

Es kann gemäß den folgenden Anweisungen optimiert werden: http://support.microsoft.com/kb/948066

Ich bezweifle, dass es in diesem Fall die Ursache ist, da der Durchsatz wahrscheinlich geringer sein würde, aber nachdem ich meinen Kopf für eine lange Zeit mit meinen eigenen Durchsatzproblemen unter Vista gegen die Wand geschlagen hatte, stellte ich fest, dass dies die Ursache war. Ich habe NetworkThrottlingIndex auf 70 gesetzt und endlich den erwarteten Durchsatz erreicht.

Eine Sache, die Sie nicht ausprobiert haben, ist das Entfernen von Remote Differential Compression unter Vista.

Mein Denken ist von der umfangreichen CPU-Nutzung unter Vista motiviert. Möglicherweise kann der Vista-Netzwerktreiber dies nicht auf die Netzwerkkarte übertragen, während Windows 8 dies wesentlich effizienter macht.

Ausführliche Informationen finden Sie im Artikel:
Verhindern Sie langsames Kopieren von Dateien über das Netzwerk in Vista, indem Sie die differenzielle Remotekomprimierung deaktivieren .

Kurz gesagt, deaktivieren Sie einfach Remote Differential Compressionin der Systemsteuerung -> Programme und Funktionen -> Windows-Funktionen aktivieren und deaktivieren und starten Sie den Computer neu.

Zuvor habe ich meinen Schwanz mit genau dem gleichen Problem für eine Weile gejagt! Langsame Übertragungsgeschwindigkeiten in eine Richtung, in meinem Fall ausgehend (Uplink).

Windows 7 Pro, Celeron J1800 mit integrierter Realtek Gigabit 8111C LAN-Karte. QNAP 453a und MacBook Pro am anderen Ende.

Gemessen über Iperf3 erreichte ich mit meinem Windows 7 als Client 112 MBit / s (CPU-Auslastung bei 25-30%). Und nur 39-41 Mbit / s, wenn als Server festgelegt, mit einer hohen CPU-Auslastung zwischen 50-100%. So schlimm, dass der PC beim Testen der Bandbreite einfrieren würde.

Die normale Dateiübertragung ist auf maximal 45 MBit / s begrenzt, unabhängig davon, ob ich Dateien auf meinen NAS oder meinen MAC hochgeladen oder heruntergeladen habe.

Ich bekam nicht mehr als 35-45 Megabyte pro Sekunde. Ziemlich frustrierend!

Am Ende war ich ein schlechter LAN-Kartenfahrer. Ich war besessen von der Aktualisierung von Treibern und habe meine Treiber immer aktualisiert, wenn neue verfügbar wurden. Ratet mal, nach mehreren Updates hat sich meine LAN-Karte verlangsamt.

Einige von Ihnen könnten sagen, löschen Sie einfach den alten Treiber und installieren Sie den neuen. Einfach, ah? Ich habe versucht und versucht, es hat bei mir nicht funktioniert.

Hier ist meine Lösung:

Installierte Windows von Grund auf mit OEM-Treibern von der Website des Herstellers. Ich habe auch folgendes gemacht:

Unter Geräte-Manager / LAN-Karte / Erweiterte Einstellungen / Alles außer FLOW CONTROL deaktivieren.

Deaktivieren Sie unter Windows-Funktionen die differenzielle Remotekomprimierung.

Jetzt liegt die durchschnittliche Geschwindigkeit zwischen 80 und 100 Mbit / s.

Entschuldigung für die schlechten Bilder.

Linus von Linus Tech Tips auf Youtube hatte das gleiche Problem, und ich entschuldige mich, aber ich habe vergessen, was die Lösung war. Es ist ein aktuelles Video (Stand: 20.04.2016), und ich kann mich irren, aber ich denke, dass es ein Fall war, in dem ein einzelner Thread auf einem Prozessor den begrenzenden Faktor darstellt. Wenn Sie also ältere Hardware haben und dies auch sind, Wenn Sie versuchen, 1 Gbit / s zu erreichen, ist es tatsächlich die CPU, die das Problem darstellt, wenn der Großteil der Arbeit auf die CPU verlagert wird, was die meisten integrierten Netzwerkkarten heutzutage tun. Ich könnte mich irren, es ist ein aktuelles Video von ihm. Ich rate dir dringend, seinen Stream zu überprüfen. Für das, was es wert ist, stoße ich auf das gleiche Problem auf meiner Gigabit-Internetverbindung.