Perché sto ottenendo 950 Mbps su ma solo 360 Mbps su Gigabit Ethernet?


46

Ho due computer desktop che parlano tra loro direttamente. Entrambi hanno adattatori di rete compatibili con Gigabit Ethernet. Sono 1 Gbps o 1000 Mbps. Li ho collegati con un nuovissimo cavo dritto Cat6 UTP lungo 10 metri e mi avvicino abbastanza a quel massimo teorico. Il Task Manager di Windows (scheda Rete) mostra 844 - 946 Mbps in una direzione. Ma nella direzione opposta, mostra solo circa 326 - 365 Mbps.

Local: 192.168.100.152
Remote: 192.168.100.151

Il computer locale esegue Windows 8.1 Pro e l'ho collegato in remoto all'altro computer che esegue Windows Vista Ultimate.

Risultati Iperf

Ho usato Iperf per fare dei test. Ho eseguito il test per 60 secondi ogni volta. Ho eseguito il test 10 volte per ciascuna direzione di comunicazione. Ho quindi messo insieme questa tabella con i risultati dei test per ottenere una media.

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)

La mia domanda è: perché è molto più lento nell'altra direzione?

Gestore dei processi di Windows

Questo è il diagramma di rete visto durante l'esecuzione dei test in Iperf.

un' B

Presta attenzione al diagramma nei seguenti due screenshot!

c d

Hai notato come è passato da "1 Gbps" a "500 Mbps" nell'angolo in alto a destra mentre passavo dall'invio dei dati alla ricezione dei dati. Perché lo ha fatto? Rileva in qualche modo l'altra porta di rete come metà di 1 Gbps quando si va in un modo, ma è piena quando si fa il contrario?

Test di trasferimento file

Ho fatto altri test con un file di dati per ottenere letture più realistiche da disco a disco. Ho creato un file da 1 GB per questo scopo. Ho usato solo le funzionalità predefinite di condivisione dei file di Windows. Dal computer locale, mi sono collegato alla condivisione C $ sul computer remoto e ho trascinato e rilasciato il file avanti e indietro (saltando la corda) tra di loro, cambiando il nome del file ogni volta. Ho cronometrato tutto al meglio delle mie capacità e questo è quello che ho ottenuto.

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

Il throughput indicato dal diagramma di copia dei file di Windows racconta una storia diversa. Qui sto scaricando due file, uno dopo l'altro in due posizioni diverse sullo stesso disco. La prima copia indicava 107 MB / s sostenuti fino al 41% e la seconda indicava 98,9 MB / s sostenuti fino all'87%.

e f

Quindi questo è in linea con i risultati ottenuti con lo strumento Iperf. Ora, ecco come appare quando carico sul computer remoto.

g h io

Supporta 103 MB / s fino al 73%, quindi passa a puzzare 27,3 MB / s all'82% e poi sale di una tacca per raggiungere 49,1 MB / s al 93%.

Ecco altri due schemi "montagne russe" dall'aspetto divertente.

j K

Aggiornamento 1 - Velocità collegamento

Ho provato a disabilitare l'adattatore Wifi sul computer remoto. (L'adattatore Wifi era già disabilitato sul computer locale.) Penso che questo sia ciò che Timtech intendeva con quel commento. Ho avuto lo stesso pensiero: che avere sia gli adattatori cablati che wireless abilitati allo stesso tempo limitasse la velocità effettiva dell'adattatore cablato al livello dell'adattatore Wifi (adattandosi all'adattatore più lento per la compatibilità). Perché l'adattatore Wifi (DWA-160 Wireless N in questo caso) viene generalmente rilevato come collegamento "52 Mbps" - "104 Mbps" dal computer Vista.

Nella schermata seguente, il computer remoto è configurato come server e il computer locale è configurato come client (192.168.100.152 <- 192.168.100.151).

l

Ma la disconnessione dell'adattatore Wifi sul computer remoto non ha aiutato il mio basso throughput sulla mia connessione cablata.

Non solo quello! In Task Manager di Windows sul computer remoto, la velocità di collegamento per l'adattatore cablato (LAN 1) viene visualizzata come "1 Gbps". Se fai riferimento alle schermate sopra puoi vedere che viene rilevato come un link "500 Gbps" sul computer locale. Quindi, per la stessa connessione cablata, Windows Vista dice che è un collegamento da 1 Gbps, mentre allo stesso tempo, Windows 8.1 Pro dice che è un collegamento da 500 Gbps ... quale è allora?

Ecco come appare sul computer remoto quando lo configuro come client e il computer locale come server (192.168.100.152 -> 192.168.100.151).

m

Come puoi vedere qui, viene utilizzato circa il 95% del link da 1 Gbps. Ciò si traduce in 950 Mbps. È esattamente quello che ho ottenuto nel test sopra. Ma fare il contrario è una storia completamente diversa.

Aggiornamento 2 - Duplex e MDI-X

Come suggerito da alcuni di voi, ho dato un'occhiata alle impostazioni duplex. Sia il computer locale che quello remoto erano impostati sulla modalità di negoziazione automatica, come puoi vedere dalle schermate seguenti.

n o

Ho provato a passare a "1.0 Gbps Full duplex" su entrambi i computer. Ho quindi fatto lo stesso tipo di test di prima, usando Iperf. Con computer locale come server e computer remoto come client ottengo circa 950 Mbps max. Con il computer locale come client e il computer remoto come server ottengo circa 360 Mbps.

Qui, dai un'occhiata a questi screenshot.

p q

Quello che vedi qui è il diagramma per quando carico e scarico tra i due computer. Il grafico più alto (utilizzo 95 - 98%) è da locale a remoto (a monte 192.168.100.152 -> 192.168.100.151). Il grafico inferiore (utilizzo ~ 33%) è remoto al locale (a valle 192.168.100.152 <- 192.168.100.151).

Per cercare di escludere eventuali problemi di Auto MDI-X, avevo uno di quegli adattatori crossover collegati a un'estremità del cavo (il computer locale).

r

Ciò renderebbe sicuramente il cavo un cavo incrociato. Cavolo, l'ho persino fatto testare con un tester di rete! Ora è davvero incrociato (pin 1/3, 2/6)!

Quindi ora ho una vera connessione via cavo crossover tra i due computer e ho impostato manualmente "1,0 Gbps Full duplex". Eppure ho ancora lo stesso problema. Altre idee? Oltre ad aggiornare il computer Vista (o reinstallare il computer 8.1)?

Aggiornamento 3 - Limitazione software o hardware?

La mia ipotesi migliore è che ho due sistemi operativi che non sono compatibili tra loro. Sono entrambi sistemi Windows, ma non tutti i sistemi Windows sono uguali. Dovrò provare a utilizzare Vista su entrambi o 8.1 Pro su entrambi e vedere che tipo di throughput ottengo. Ciò significa acquistare un aggiornamento. Accidenti a te Microsoft.

A proposito, entrambi i computer sono personalizzati. Ecco alcune specifiche.

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 ha suggerito che la macchina Vista potrebbe utilizzare un chip Realtek difettoso. Quindi ho scavato queste specifiche. Vedo ora che la macchina Vista utilizza una revisione B di 8111 mentre la macchina locale utilizza una revisione C dello stesso chip. Questo significa qualcosa? Entrambi sono chiaramente specificati per 1000 Mbit (vedi sopra) dal produttore. Potrebbe essere che 8111B sottoperformi così tanto (360 Mbps)?

Queste unità particolari raggiungono una velocità di burst di 107 MB / s. Questo è esattamente il numero che ho visto nel test sul computer locale. Ma anche la lettura / scrittura sequenziale o casuale sostenuta di forse 55 MB / s NON si traduce in 360 Mbps. Questo dovrebbe darmi circa 440 Mbps e non i 360 Mbps che sto ricevendo. Quindi non sospetto che questo sia il collo di bottiglia, soprattutto perché entrambi usano lo stesso modello di unità. Inoltre, l'operazione di copia dei file è una cosa, ma Iperf non utilizza affatto i dischi, ma utilizza solo la memoria RAM per i test.

Aggiornamento 4 - Offload checksum TCP

Come suggerito da Tonny, ho provato a disattivare l'offload del checksum TCP (per IPv4 e IPv6).

S t

Ho anche riportato "Speed ​​& Duplex" su auto per entrambi i computer. Ma questo non ha aiutato. Ho ancora il rendimento basso in una direzione e alto nell'altra direzione.

Aggiornamento 5 - Nuova versione del driver

Ho provato ad aggiornare la versione del driver sia locale che remoto all'ultima versione scaricata dal sito Web Gigabyte e dal sito Web Realtek.

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)

u v w X

Ho sempre ottenuto lo stesso rendimento scadente in una direzione.

Aggiornamento 6 - Utilizzo della CPU

Ho verificato l'utilizzo della CPU. Questo non dovrebbe essere un problema. Ecco i miei risultati.

On local...

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

On remote...

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

Locale (download, upload, inattivo) ...

y z aa

Remoto (download, upload, inattivo) ...

ab corrente alternata anno Domini

Il telecomando utilizza molta più potenza della CPU, ma questa è anche quella con il Core 2 Duo più lento. Ma durante i miei test non ha mai superato il 38%. La cosa particolarmente interessante qui è che consuma molta più potenza della CPU durante il download (locale -> remoto) rispetto al caricamento (locale <- remoto).

Quindi, con un throughput di 950 Mbps, utilizza il 38% e a 360 Mbps utilizza il 25%. Anche l'utilizzo del core non è bilanciato, utilizza un core in più rispetto all'altro. Non sono sicuro di quale conclusione trarre da questo. Il computer locale non visualizza l'utilizzo principale, quindi non posso confrontarlo. Ma l'utilizzo della CPU è anche sul computer locale (10% su download / upload).

Aggiornamento 7 - Nuova scheda di rete Intel Gigabit

Ora ho installato un nuovissimo adattatore di rete PCI-Express Gigabit di Intel in sostituzione del Realtek RTL8111B integrato sul computer remoto, che si presume sia troppo lento durante il caricamento. Il numero di prodotto dell'adattatore Intel è EXPI9301CT. Questo adattatore dovrebbe essere molto buono secondo le recensioni che ho letto. Voglio solo escluderlo come un possibile collo di bottiglia.

ae

Ho fatto alcuni test ora con Iperf per Windows e qui ci sono i risultati.

Locale (download, upload) ...

af ag

Remoto (download, upload) ...

ah ai

In media, questo adattatore è in realtà un po 'più lento dell'adattatore Realtek. Penso che abbia un overhead più piccolo rispetto a Realtek e di conseguenza un throughput continuo più stabile. Ma ottengo ancora solo circa 360 Mbps in una direzione e 950 Mbps nell'altra, anche con questo adattatore Intel.

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

Non ho idea del perché abbia raggiunto il picco a 113 MB / s nel primo test, da locale a remoto. Ha mantenuto quella velocità per tutta la durata del test, il grafico era quasi piatto a 113 MB / s. Come prima, ho usato un intervallo di 60 secondi per ogni corsa. Alla corsa successiva, tuttavia, è sceso a 104 MB / s.

Come puoi vedere da questi valori, ho ancora lo stesso throughput con questo adattatore Intel come con l'adattatore Realtek integrato. Quindi penso che sia sicuro dire che non ha nulla a che fare con l'adattatore stesso. Quindi possiamo smettere di incolpare RTL8111B come chip inferiore / inferiore rispetto a RTL8111C trovato sull'altra scheda madre. Sembra sempre più un problema di software / sistema operativo / configurazione, o tutte e tre le cose contemporaneamente.

Aggiornamento 8 - Ottimi risultati con Ubuntu LINUX

Dopo aver esaurito tutte le altre opzioni, ho finalmente deciso di eseguire alcuni test con Linux e ho ottenuto grandi risultati. Ho usato un sistema Ubuntu Linux 13.10 Live e Iperf per Linux (versione 2.0.5-3) su macchine sia locali che remote. Ecco i risultati

=======================================================
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

Locale (download, upload, inattivo) ...

aj ak al am un

Come puoi vedere, quando utilizzo Ubuntu ottengo lo stesso throughput in entrambe le direzioni. È perché uso lo stesso sistema operativo su entrambe le macchine o è qualcos'altro? Otterrei lo stesso throughput se avessi le stesse versioni di Windows impostate su entrambe le macchine? Non capisco perché importerebbe se utilizzassi una versione di Windows leggermente obsoleta, ovvero Vista, su un computer e l'ultima versione sull'altro? . Windows XP è una storia diversa.

Ma so che stanno facendo tutto il possibile per uccidere Vista. Ad esempio, l'ultima versione di Office 2013 non è intenzionalmente supportata su Windows Vista. Sono sicuro che Microsoft desidera che Vista non sia mai successo. Proprio come spereranno che Windows 8.0 non sia mai successo. Ma di solito sono persistente quanto lo sono e non aggiorno le mie installazioni di Windows fino a quando non devo assolutamente farlo.

Quindi la domanda è come ottenere lo stesso throughput in entrambe le direzioni con due diverse versioni di Windows. Windows Vista dovrebbe essere in grado di supportare la velocità Gigabit: non è un sistema operativo di 20 anni o qualcosa del genere, non è Windows 95 di cui stiamo parlando. Vista è un sistema operativo moderno. Non ho ancora testato l'esecuzione della stessa versione di Windows su entrambe le macchine. Potrebbe esserci una differenza nell'implementazione TCP o qualcosa tra le due versioni del sistema operativo. In tal caso, probabilmente sarò costretto ad aggiornare la macchina Vista. O quello o passare a Linux. Non sono disposto a pagare di più per meno. Perché dovrei aggiornare Windows solo per ottenere il throughput Gigabit in entrambe le direzioni? ...

Aggiornamento 9 ...

Cavo

Ho provato a invertire il cavo. Ho ottenuto gli stessi risultati di prima. Ho anche preso un nuovo cavo patch Cat 6 e l'ho provato. I risultati del test di throughput erano gli stessi. Quindi il cavo non è il problema qui. Ho usato solo cavi patch pre-terminati / stampati. Quindi il cablaggio dovrebbe essere corretto. Ma ho intenzione di terminare i miei cavi di installazione in seguito.

FW e AV

Per quanto riguarda firewall (FW) e antivirus (AV), non utilizzo alcun software FW o AV di terze parti. Ho solo Windows Firewall e Security Essentials. Li ho disabilitati entrambi su entrambe le macchine. I risultati del test di throughput erano gli stessi di prima.

AO ap

aq ar come

Test di velocità LAN

Ho installato LAN Speed ​​Test Lite 1.3 sul computer locale. Credo che il test venga eseguito tra la memoria locale e l'unità disco sulla macchina remota. Non ne sono sicuro. Ma richiede un percorso di condivisione sul computer remoto. Ho usato o $ share sul telecomando.

a au av

Upload: 427 Mbps
Download: 420 Mbps

Non mi fido troppo di questi risultati. Se guardi il grafico, puoi vedere che varia molto durante il test. Il test è stato un test "successivo", ovvero: scrivere (caricare) prima il test, quindi leggere (scaricare) il test. Ovviamente se si esegue un test di upload / download simultaneo, il throughput complessivo sarà inferiore. Ma non sono interessato a tali test. Finora ho fatto solo test "successivi" con entrambi i test di trasferimento file in Windows (condivisione file / smb) e in Iperf.

Non ho eseguito test di memoria in memoria con LAN Speed ​​Test perché richiede l'uso di un programma chiamato LST Server sul telecomando e questo programma richiede la registrazione per poterlo utilizzare.

Aggiornamento 10 ...

Test dell'unità disco

Ho usato Crystal Disk Mark 3.0.3 per testare le unità disco. Ecco i risultati

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

Si tratta di velocità sequenziali di lettura e scrittura basate su 5 esecuzioni e un carico di 1000 MB.

Questo è il disco locale (contrassegno del disco, lettura, scrittura) ...

aw ascia Ay

E questo è il disco remoto ...

az

Ma non capisco ... questi risultati sembrano contraddittori.

Okey, il disco locale può leggere a 118 MB / s, in modo da consentire il caricamento segnalato di circa 100 MB / s. Ma il disco remoto non sarebbe in grado di riceverlo se è in grado di scrivere solo 69 MB / s. Ma per un tocco magico ottengo in media poco più di 100 MB / s di upload.

Fare il contrario ha più senso. Se il disco remoto può leggere a 70 MB / s e il disco locale può scrivere a 113 MB / s, il download non dovrebbe essere più veloce di 70 MB / s. In media ottengo circa 40 MB / s di download. Sembrerebbe ragionevole.

Quindi non posso concludere nulla da questi risultati. Voglio dire, l'unità disco sul computer locale è a malapena utilizzata. È anche il disco che contiene il sistema operativo ed è l'unica partizione su quel sistema. Mentre il disco remoto è quasi pieno ed è anche partizionato con diverse partizioni. Tuttavia, non viene utilizzato per il sistema operativo. Ho scelto la lettera di unità O:per il test qui, perché questa è la partizione con più spazio libero.

(Si noti che ho usato la lettera di unità C:nei test precedenti che si trova su un'unità disco Seagate completamente separata che contiene il sistema operativo sul computer remoto. Quindi tali letture non sono confrontabili.)

Scrivi cache

Con la cache di scrittura su disco abilitata ho ottenuto questi risultati.

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

Ho quindi disabilitato la memorizzazione nella cache di scrittura su tutte le unità sul telecomando e sull'unità locale.

ba bb

Non ho riavviato perché non è stato richiesto il riavvio per rendere effettive le modifiche. Ho quindi ottenuto i seguenti risultati.

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

Non c'è stato praticamente alcun cambiamento. Nessun riavvio e nessun riavvio è stato richiesto.

Pacchetto QOS

Ho quindi disabilitato l'Utilità di pianificazione pacchetti QOS per l'adattatore appropriato sul computer remoto, quindi sul computer locale.

avanti Cristo bd

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

Nessun cambiamento significativo qui. Ancora una volta, non è stato richiesto alcun riavvio e nessun riavvio.

Pacchetti Jumbo

Ho quindi continuato ad abilitare i pacchetti jumbo che ho usato l'impostazione da 4 GB perché 4 KB è la dimensione MTU più grande supportata su entrambe le macchine.

essere bf

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

Ora qui, il caricamento (da locale a remoto) non è stato interessato, ma la velocità di download è stata ridotta in modo significativo. Non è stato richiesto il riavvio, ma ho deciso di riavviare comunque entrambe le macchine, solo per una buona misura. Ho quindi eseguito nuovamente gli stessi test e ho ottenuto questi risultati.

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

Quindi il caricamento è ora ancora più veloce, ma il download è ancora più lento di prima che avessi apportato queste modifiche, anche dopo il riavvio. Mi sarei aspettato che entrambi salissero un po '. Cosa significa questo?


4
Penso che le cifre della velocità effettiva visualizzate in Task Manager siano ridimensionate automaticamente in base alla velocità effettiva. È certamente così per Windows 8 e il mio è attualmente mostrato a 54 Mbps e negli ultimi minuti sono stati 100 MB e 100 KB (quando inattivo) e vari valori in mezzo.
sgmoore,

12
Hai preso in considerazione l'avvio di entrambe le macchine dai CD live di Linux (due dischi di avvio identici) per escludere i problemi del software e il trasferimento di un file dal disco RAM al disco RAM per escludere i problemi dell'HDD?
Moshe Katz,

1
Volevo mettere qui i miei 2 centesimi ... il mio primo: hai disabilitato tutti i virusscanner? il mio secondo: hai provato a invertire il cavo per vedere se anche il tuo problema si inverte (passando l'estremità del cavo all'altro computer e viceversa). Se si ottiene un download veloce ma un caricamento lento, il problema è nel cablaggio. (cioè le tue coppie non sono intrecciate insieme ma con altre coppie)
Rik

1
@MosheKatz L'ho appena fatto. Dai risultati che ho appena pubblicato (vedi aggiornamento 8) puoi vedere che ho ottenuto un throughput eccezionale in entrambe le direzioni con Ubuntu.
Samir,

2
@Sammy wow, questo argomento sta diventando grande :) Ho visto che hai provato Linux ad entrambe le estremità. Ma hai già provato Linux <--> Win8 e / o Linux <--> Win.vista? Se uno di essi ha la massima velocità in entrambe le direzioni, sai che l'altro è in errore (che mostrerebbe nell'altro test) e possiamo concentrare i nostri sforzi su quella macchina.
Rik

Risposte:


6

In base alla tua risposta:

@ewhac Le dimensioni della finestra TCP sul computer locale in genere differiscono dalle dimensioni della finestra sul computer remoto. Il valore predefinito è 0,06 MB in locale (win 8) e 0,01 MB in remoto (vista). Devono avere lo stesso valore? Come chiedo di indovinare l'MSS? Sarebbe l'opzione -m ("stampa la dimensione massima del segmento")? Di solito non ho impostato nulla di tutto ciò. Perché dovrei? - Sammy, 30 novembre alle 21:39

La dimensione della finestra TCP rappresenta la quantità massima di dati che lo stack TCP schizzerà sul blind blind prima di fermarsi e attendere di ricevere i riconoscimenti dalla macchina remota - in altre parole, la quantità massima di traffico non riconosciuto sul wire. Il fatto che la finestra TCP sulla macchina Vista sia molto più piccola rispetto alla macchina Windows Se7en supporta la teoria che non si sta riempiendo abbastanza la pipa prima di arrestare e attendere gli ACK.

Pertanto, la prima cosa che vorrei provare è aumentare la dimensione della finestra TCP sulla macchina Vista usando l' -wargomento. 0,01 MB è un'unità alquanto inutile; Immagino che sia 16 KiB. Quindi inizia con 16 KiB ed esegui un test:

iperf -c -w 16K ...

Raddoppia le dimensioni della finestra e ripeti il ​​test:

iperf -c -w 32K ...

Spero che dovresti osservare un aumento di velocità. Continua a raddoppiare le dimensioni della finestra fino a quando non vedi più aumenti significativi della velocità.


4

Come affermato in precedenza, sarà necessario modificare le dimensioni della finestra TCP in iperf per ottenere una velocità effettiva superiore su collegamenti ad alta velocità a bassa latenza. Versioni diverse di Windows (o iPerf) possono avere dimensioni della finestra predefinite diverse. Prova "-w 256k" per iniziare sia sul client che sul server.

Puoi confermare la direzione della freccia dei tuoi grafici? In iPerf, i dati vengono trasferiti dal client al server (al contrario di ciò che di solito penso).

Puoi escludere i dischi rigidi come causa poiché iPerf non tocca i dischi rigidi.

Penso che tu abbia già verificato che stai utilizzando i driver NIC più recenti. Non dovrebbe essere necessario spostarsi con l'impostazione manuale della velocità / duplex. Lo stesso vale per i frame jumbo: non valgono la seccatura con l'hardware moderno.

Verificare che Offload invio di grandi dimensioni (LSO) e Offload di ricezione di grandi dimensioni (LRO) siano abilitati su entrambe le schede NIC. Alcuni driver NIC utilizzano nomi diversi (o più opzioni che controllano questo comportamento), quindi potrebbe essere necessario cacciare. Di solito il default è di averli tutti abilitati.


3

Penso che dovresti leggere qualcosa in più su come funziona iperf. Se non imposti le dimensioni corrette della finestra TCPC, i tuoi risultati varieranno molto. Credo che sia l'opzione -w. Questo sito Web aiuterà a calcolare la dimensione ottimale della finestra TCP. È necessario conoscere RTT e banda per calcolarlo. http://www.kehlet.cx/docs/tcpwin.php

Prova anche altri strumenti come "LAN Speed ​​test" lite che eseguirà su e giù i trasferimenti tra le condivisioni alle estremità. I suoi risultati sono abbastanza vicini nei test effettuati. Assicurati anche di verificare quali sono le velocità massime di rotazione dei tuoi dischi rigidi.


Posso usare il comando ping per capire l'RTT? Se eseguo il ping del telecomando ottengo meno di 1 ms. Ma non mi dice quanto. C'è qualche altro strumento che posso usare, uno con maggiore precisione? So che non posso usare 0 ms nella formula.
Samir,

Ho usato un programma ping chiamato hrping . Per quanto riguarda LAN Speed ​​Test Lite, non era buono come Iperf. Forse migliora dopo aver installato il server LST sull'altra estremità. Ma non avevo voglia di registrarmi per usarlo o pagare una licenza.
Samir,

3

Un paio di punti che potrebbero aiutarti. Lo stack IP TCP è ora implementato in modo diverso nelle versioni successive a Windows 7. Esaminerei attentamente le mie ottimizzazioni TCP, potrebbe non esserci molto tra le tue due caselle, ma vale comunque la pena modificare alcune impostazioni sul tuo Vista Box.

L'uso di netsh int tcp set global congestionprovider = ctcp è stato deprezzato. Per impostare o modificare il congestionprovider è necessario utilizzare il comando seguente:

leggi l'articolo qui: http://forums.speedguide.net/showthread.php?280646-When-will-TCP-Optimizer-support-Windows-8-amp-Windows-Server-2012

netsh int tcp set custom aggiuntivo 300 10 ctcp disabilitato 50 Quindi digitare: netsh int tcp set custom aggiuntivo

Per ulteriori dettagli sul comando sopra digita semplicemente: netsh int set supplemental

Per verificare quale congestione fornisce attualmente il seguente utilizzo: netsh int tcp show supplemental

Ma solo Win Server 2012 può creare modelli personalizzati CTCP forse un problema.

Anche il ridimensionamento automatico potrebbe essere un fattore.

Forse vale la pena dare un'occhiata ai driver che necessitano di upgrade / downgrade. vedere quali funzionano meglio.

Un altro pensiero è che le dimensioni dei pacchetti vengono scritte su HDD. Quali dimensioni sono i tuoi settori HDD formattati a 512b ~ 64K potrebbe essere il collo di bottiglia nella cache .. Vale la pena prendere in considerazione quando si utilizzano velocità GBit o testare invece con disco SSD!

Hai esaminato l'abilitazione dei pacchetti jumbo (se questo vale per le tue schede di rete)


È possibile disabilitare il ridimensionamento delle dimensioni della finestra e impostare il valore RWIN manualmente su 64 KB?
Samir,

Ho appena letto che il valore RWIN viene modificato in modo dinamico sui moderni sistemi Windows. È vero? Che RWIN non può essere un valore fisso?
Samir,

2

Ottimi risultati con Ubuntu LINUX

Sembra abbastanza familiare ... ottieni iperfprestazioni inspiegabilmente scadenti in Windows, ma lo stesso hardware funziona bene con Linux.

Dopo aver combattuto questa battaglia ancora e ancora, sono giunto alla conclusione che iperfin Windows è traballante . Non so perché ... onestamente, ho smesso di preoccuparmi perché so che posso sempre ottenere risultati sani da Linux.

Quindi, se vuoi sapere perché stai ottenendo prestazioni così scarse, non guardare oltre l'applicazione.


2

Qualcosa da provare è arrestare il servizio MMCSS. Sì, perderai temporaneamente l'audio, ma è possibile che qualcosa lo stia attivando, facendo rallentare l'attività di rete in modo che l'attività di rete non annulli altre attività.

Vedi qui per alcune informazioni su MMCSS e limitazione della rete: http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx

Può essere modificato secondo queste istruzioni: http://support.microsoft.com/kb/948066

Dubito che sia la causa in questo caso, poiché il rendimento sarebbe probabilmente inferiore, ma dopo aver sbattuto la testa contro il muro a lungo con i miei problemi di throughput su Vista, ho scoperto che questa era la causa. Ho impostato NetworkThrottlingIndex su 70 e ho finalmente ottenuto il throughput che mi aspettavo.


2

Una cosa che non hai provato è la rimozione della compressione differenziale remota su Vista.

Il mio pensiero è motivato dall'ampio uso della CPU su Vista. È possibile che il driver di rete Vista non sappia come scaricare questo sulla scheda di rete, mentre Windows 8 lo fa in modo molto più efficiente.

Per i dettagli completi, consultare l'articolo:
Impedire la copia lenta dei file sulla rete in Vista disabilitando la compressione differenziale remota .

Ma in poche parole, deseleziona Remote Differential Compressionnel Pannello di controllo -> Programmi e funzionalità -> Attiva e disattiva le funzionalità di Windows, quindi riavvia.

Immagine


0

In precedenza ho inseguito la coda con esattamente lo stesso problema per un po '! Velocità di trasferimento lente in una direzione, nel mio caso in uscita (uplink).

Windows 7 Pro, Celeron J1800 con scheda LAN integrata Realtek Gigabit 8111C. QNAP 453a e MacBook Pro all'altra estremità.

Quando misurato tramite Iperf3 ottenevo 112 mbps con il mio Windows 7 impostato come client (utilizzo della CPU al 25-30%). E solo 39-41 Mbps se impostato come server, con un utilizzo intenso della CPU tra il 50-100%. Così male che il PC si bloccherebbe durante i test della larghezza di banda.

Il trasferimento regolare dei file ha un limite massimo di 45 Mbps, indipendentemente dal fatto che stia caricando o scaricando file sul NAS o sul MAC.

Non ottenevo niente di più di 35-45 megabyte al secondo. Abbastanza frustrante!

Finì per essere un cattivo driver della scheda lan. Ero ossessionato dall'aggiornamento dei driver e ho sempre aggiornato i miei driver quando ne è diventato disponibile uno nuovo. Indovina cosa, dopo diversi aggiornamenti la mia scheda lan ha rallentato.

Alcuni di voi potrebbero dire, basta cancellare il vecchio driver e installare quello nuovo. Semplice ah? Ho provato e provato, non ha funzionato per me.

Ecco la mia soluzione:

Finestre installate da zero con driver OEM dal sito Web del produttore. Inoltre ho fatto quanto segue:

In Gestione dispositivi / Scheda Lan / Impostazioni avanzate / Disattiva tutto tranne CONTROLLO FLUSSO.

In Funzionalità Windows, disabilita la compressione differenziale remota.

Ora la velocità media è tra 80-100 Mbps.

Ci scusiamo per le immagini di scarsa qualità.

inserisci qui la descrizione dell'immagine


-2

Linus di Linus Tech Tips su Youtube ha avuto lo stesso problema, e mi scuso ma ho dimenticato quale fosse la soluzione. È un video recente (al 20/04/2016), e potrei sbagliarmi, ma penso che sia finito in un caso in cui un singolo thread su un processore è il fattore limitante, quindi se hai hardware vecchio e lo sei cercando di raggiungere 1 Gbps, in realtà è la CPU il problema, se scarica gran parte del lavoro sulla CPU, cosa che la maggior parte delle schede di rete di bordo fanno in questi giorni. Potrei sbagliarmi, è un suo video recente, ti incoraggio vivamente a controllare il suo stream. Per quello che vale, sto riscontrando lo stesso problema sulla mia connessione Internet Gigabit.


"Ho dimenticato quale fosse la soluzione" - non c'è molta risposta, vero?
DavidPostill

1
Quindi prenditi il ​​tempo per determinare quale fosse la soluzione. Questa risposta non è utile, puoi comunque essere esclusa dalla risposta, per aver inviato risposte errate anche se sono contrassegnate come wiki della comunità
Ramhound
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.