10G-Netzwerk; Datentransferoptimierung Win<->Linux/BSD/OS/etc.

D

danielmayer

Enthusiast
Thread Starter
Mitglied seit
30.03.2005
Beiträge
1.010
Moin,
Für eine bereits begonnene Diskussion wird hier fortgeführt, welche Performance wie zwischen zwei PCs erreicht werden kann, die mittel 10G-Netz verbunden sind.

@ Besterino:
Also: eine sehr schlichte und aussagekräftige Methode, unter Linux die Real-Leistung von HDDs/SSDs/Raid zu ermitteln ist der Befehl "hdparm -tT [device]". Idealerweise ist das Verzeichnis nicht gemountet, damit keine Systemzugriffe das Ergebnis beeinflussen.
Bei mir z.B. auf dem Server ist eine einzelne WD FAZZ 2TB verschlüsselt und unter /dev/mapper/basis1 erreichbar:

"Ergebnis:
/dev/mapper/basis1:
Timing cached reads: 20638 MB in 2.00 seconds = 10328.85 MB/sec
Timing buffered disk reads: 462 MB in 3.01 seconds = 153.67 MB/sec
"
Die zweite Zeile zeigt eine Realleistung (lesend) von der Platte.
Auf meiner 840 Evo 1TB (ungenutzte Partition) kommt raus:
/dev/sda8:
Timing cached reads: 20042 MB in 2.00 seconds = 10030.38 MB/sec
Timing buffered disk reads: 1424 MB in 3.00 seconds = 474.31 MB/sec

Das ist letztlich das maximal erreichbare im Netz-Transfer zu einem anderen System.
Dummerweise ist die erste Zeile bei gepufferten und ggf. Multicore-Netzbereitstellungen (SMB>=2.0, NFS) zunächst auch verfügbar. Daher wahrscheinlich auch Deine 900MB/s. Ich hatte zwischen Workstation (SSD@SATA II) -> Server (Raid5@SAS12G) zunächst 800MB/s, bis die Übertragung nach ca. 8GB (RAM-Cache?) auf die "erwartete" Übertragung von ca. 260MB/s einbrach (-> Grenze SATAII meiner Workstation).

Insofern würde ich bei Deinen Rechnern erstmal die Max-Leistung "vor Ort" ermitteln, dann macht eine Fehleranalyse im Netzwerk mehr Sinn.
T20: 4x4TB im Raid5? Dann wäre die Leseleistung von 3xRed zu erwarten -> ca. 400MB/s.
Gen8: 4x1TB im Raid5? Ältere Platten eher etwas weniger, ich schätze auf ca. 350MB/s.
Workstation: Abgesehen von der SSD sollten die HDDs bei ca. 130MB/s liegen.
Testmaschine: eher 90MB/s.
(alles lesend)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also ich teste so:

schreiben, wobei hier count und bs entsprechend angepasst werden sollte, sodass die Daten größer als der RAM werden (hier 8000MB):
#dd if=/dev/zero of=tempfile bs=1M count=8K conv=fdatasync,notrunc

lesen (erst caches leeren):
#echo 3 | sudo tee /proc/sys/vm/drop_caches
#dd if=tempfile of=/dev/null bs=1M count=8K

Netzwerkgeschwindigkeit mit netcat.
Auf dem Server:
#nc -vvlnp 12345 >/some/directory/tempfile

Auf dem Client:
#dd if=/dev/zero bs=1M count=8K | nc -vvn ip.des.servers 12345
 
Ok, Danke. Das ist eine vollständige "Test-Suite" für lokal und Netz.
Ich käme mit der Evo840-SSD dann lokal auf 496M/s lesend, 413M/s schreibend. Das liegt recht nah am Lesetest per hdparm.
 
Mit den Tests von Sir Diablo komme ich auf:

1.
Auf dem T20 mit 4x4TB WedRed ZFS Pool mit ZFS on Linux in der UbuntuVM: 265MB/s schreibend und 351/MB/s lesend.

2.
Auf dem Gen8 mit 4x1TB Samsung mit OmniOS (nativ): 226MB/s schreibend und 322MB/s lesend (allerdings funktioniert der Befehl zum Cache leeren dort nicht).

Damit kenne ich nun jeweils die maximal Werte des Storage (zumindest grob), richtig?

Mit dem "Netztest" von Sir Diablo schreibt:

1. der HP auf die Ubuntu-VM nur mit 127MB/s.
2. die Ubuntu-VM auf dem HP mit 91MB/s.

iperf Gegenprobe:

OmniOS=client; Ubuntu-VM=Server:
iperf (ohne Parameter): Transfer=10,6GBytes; Bandwidth=9,11Gbits/s
iperf -P 5: Transfer=11,3Gbytes; Bandwith=9,67Gbits/s

Andere Richtung OmniOS=server; Ubuntu-VM=Client:
iperf (ohne Parameter): Transfer=2,04Gbytes; Bandwidth=1,75Gbits/s
iperf -P 5: Transfer=6,44GBytes; Bandwidth=5,43Gbits/s

Mal ne dumme Frage: limitiert evtl. der G1610T?

EDIT 1: von der Win7 Maschine auf die Ubuntu-VM sieht's "noch düsterer aus" - mit einem TCP-Stream < 1Gbit(!), ab "iperf -P 7" kommt man immerhin auf ~4-5Gbit. Vielleicht muss ich mal testweise die Ports an der x540-T2 tauschen? Oder mit 'nem anderen Client-OS testen. Witzigerweise kann ich ja große Dateien (20GB) von dem Win7 PC auf die VM mit konstant >300MB/s (also schreiben) kopieren und zurück >200MB/s (also lesen)...
 
Zuletzt bearbeitet:
Also ob die CPU limitiert kannst du ja mal schaun, was top so sagt wenn du was übers Netz kopierst. Du solltest aber schon so an die 3GBit/s kommen mit deinem Storage.

Auch mal mit iotop schaun welche Prozesse während dem kopieren die I/O Last erzeugen.

Ein G1610T macht bei mir im Büro aber locker flockig zwei Raid10 (mdadm mit ext4) und zwei GBit/s Verbindungen im Bonding mit.

Damit komm ich auf ~230 MB/s lesen und ~200 MB/s schreiben.

Vtl. macht auch FUSE Probleme.
 
Ich fürchte, wenn ich an FUSE ran muss bin ich mit meinem Wissen und Zeitkonto am Ende... =)

Was ganz anderes, gibt es einen vergleichbaren Test mit nc auch für Windows? Mein Ziel ist ja, möglichst schnell mit den Linux/Solaris-Kisten für Win-Clients zu "hosten".

Da ich ja quasi 2 Clients (1x Win10 + 1xWin7) und 2 Server habe, kann ich vielleicht heute Abend noch ein paar Dinge versuchen:

1.
Testweise Win10-PC (zurzeit über 10G am HP MS Gen8) an den T20 stöpseln und schauen. Umgekehrt auch mal den Win7-PC an den HP MS Gen8 stecken. Dann seh' ich zumindest mal einen etwaigen Unterschied am gleichen Server mit 2 unterschiedlichen Clients und umgekehrt mit dem gleichen Client an 2 unterschiedlichen Servern (bei ansonsten unveränderten Einstellungen).

Wenn z.B. die Win10-Box per se schneller ist als der Win7-PC (obwohl er viel älter ist), dann Upgrade ich die Win7-Kiste mal auf Win10 (hatte ich ja eh vor).

2.
Je nach Ergebnis von 1.: Solaris 11.3 auf dem HP MS Gen8 T20 auf einen USB-Stick (also "bare metal") zu installieren, das 10G Netz darauf einzurichten und den ZFS-pool zu importieren. Damit seh' ich ja dann einen etwaigen Unterschied SMB1 zu SMB2.1.

3.
Ein Solaris-based System wie unter 2. auch einmal testweise auf dem T20 bare metal installieren. Dann habe ich jedenfalls die komplexe/ungewöhnliche Kombination aus Hyper-V, Linux bzw. ZFS on Linux (bzw. die Kombination aus alldem) auf dem T20 als mögliche Bremsen ausgeschlossen. Vielleicht sollte ich damit anfangen, aber ich würde so ungern den Hyper-V beerdigen... ;)
 
besterino schrieb:
Je nach Ergebnis von 1.: Solaris 11.3 auf dem HP MS Gen8 T20 auf einen USB-Stick (also "bare metal") zu installieren, das 10G Netz darauf einzurichten und den ZFS-pool zu importieren. Damit seh' ich ja dann einen etwaigen Unterschied SMB1 zu SMB2.1.
Zum Vergrößern anklicken....

Oracle Solaris <-> OpenZFS geht nur mit der alten Poolversion 28/ ZFS v5.
Diese Version lässt sich manuell beim Pool-anlegen angeben.
 
Den Storage Pool hab ich ja bereits unter OmniOS angelegt. Müsste also v28 sein. Wenn ich den nun unter Solaris importiere, setzt solaris dann die Version hoch, wenn ich nicht aufpasse?
 
Also - bei mir - ist Win7 schonmal etwas schlechter als Win10: bei SMB / iSCSI ist es nicht so schlimm (bzw. z.T. vergleichbar), aber völlig INDISKUTABEL unter NFS.

Win7-Workstation CDMark --> HP Microserver Gen8 (beschrieben unter 2. hier):

SMB
Win7_HP_SMB.png

NFS
Win7_HP_NFS.png

iSCSI
Win7_HP_iSCSI.png

Zum Vergleich, die Ergebnisse mit der Win10-Maschine auf dem HP finden sich (leider) im anderen Thread hier.

Als nächstes teste ich mal die Win10-Kiste mit der Ubuntu-VM.
 
Hmmm...

Win10-Client CDMark --> T20 mit Hyper-V und ZFS-on-Linux in Ubuntu-VM:

SMB
Win10_T20VM_SMB.png

iSCSI
Win10_T20VM_iSCSI.png

Aus meiner Sicht schon ziemlich krass! Ich hätte definitiv nicht gedacht, dass die unterschiedlichen Windows-Versionen so einen Unterschied machen. Oder irgendein Caching funkt hier rein. Theoretisch könnte es natürlich auch daran liegen, dass die Win7-Installation schon "ziemlich alt" ist und Win10 frisch installiert. Aber das werde ich ja sehen, wenn ich upgegraded habe.
 
besterino schrieb:
Den Storage Pool hab ich ja bereits unter OmniOS angelegt. Müsste also v28 sein. Wenn ich den nun unter Solaris importiere, setzt solaris dann die Version hoch, wenn ich nicht aufpasse?
Zum Vergrößern anklicken....

OmniOS legt per default einen Pool v5000 an.
Solaris 11.3 legt per default einen Pool v37 an.

Beide haben ihre Vorzüge (Solaris aktuell sogar mehr wegen ZFS Encrypt, LZ4 und SMB 2.1),
sie sind aber inkompatibel.

Man kann beim Anlegen aber einen alten Pool v28/ZFS5 erzwingen (ohne Encrypt oder LZ4).
Ein Pool-Update muss man manuell anstoßen. Er findet nicht automatisch statt.
 
Zuletzt bearbeitet:
Also kann ich meinen pool gar nicht unter solaris importieren? Napp-it gibt mir die option aber an (war bisher nur zu feige).
 
Passiert nichts gefährliches.
Ein Pool v28 wird importiert. Bei einem Pool v5000 kommt lediglich eine Fehlermeldung.
 
Von Solaris/Napp-it habe ich keine Ahnung. Aber versuche doch mal die folgenden "Tweaks" im Ubuntu Target:
("sda" ist natürlich anzupassen...)
echo 16384 > /sys/block/sda/queue/max_sectors_kb
blockdev --setra 1024 /dev/sda
echo 1024 > /sys/block/sda/queue/nr_requests

Aus einem Beitrag hatte ich gelesen, dass die MTU 1500 für iSCSI suboptimal ist. SMB transkodiert die Inhalte auf IP-Blöcke, iSCSI möchte idealerweise Festplattenblöcke weiterleiten "as is". Die übliche Blockgröße ist 4096B, also 3 Pakete pro Block á 1500B. Mal die MTU auf 7200 oder 9000 setzen, natürlich auf beiden Seiten.
Ich hatte bei Jumbopakets immer ein Problem mit der Internetverbindung, da die Fritzbox wiederum nach Außen nur 1500MTUs (oder 14xx) leitet. Aber bei Deiner Direktverkabelung sollte das gehen.
 
Hatte leider schon bei allen Tests 9000er Jumbos überall.
 
Ich fürchte meine CDMark-Tests sind nicht so richtig aussagekräftig, da dort (für mich) undurchsichtig wohl das Caching zu inkonsistenten bzw. nicht klar reproduzierbaren Schwankungen führt. Meine Storage-Kapazitäten auf meinen beiden Servern habe ich ja oben bereits grds. ermittelt. Getreu dem Motto "Schritt für Schritt" kümmere ich mich um die "kombinierte Performance" wohl erst wieder, wenn die Performance auf dem Netzwerkkabel stimmt... ;)

Daher also mal so richtig back to topic: sollte mich nun zunächst auf die reine Geschwindigkeit im Netzwerk konzentrieren. Hier also eine erste Runde iperf-Ergebnisse:

1. Iperf Server: Ubuntu-VM@Hyper-V@T20; Iperf Client: OmniOS@HPMSGen8
"iperf -s" / "iperf -c IP"
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.1, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.12.2 port 46053 connected with 10.10.12.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  8.99 GBytes  7.72 Gbits/sec

"iperf-s" / "iperf -c IP -P 5"
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.1, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[  7] local 10.10.12.2 port 60390 connected with 10.10.12.1 port 5001
[  4] local 10.10.12.2 port 61691 connected with 10.10.12.1 port 5001
[  3] local 10.10.12.2 port 40660 connected with 10.10.12.1 port 5001
[  5] local 10.10.12.2 port 40130 connected with 10.10.12.1 port 5001
[  6] local 10.10.12.2 port 47017 connected with 10.10.12.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.94 GBytes  1.67 Gbits/sec
[  5]  0.0-10.0 sec  1.88 GBytes  1.62 Gbits/sec
[  6]  0.0-10.0 sec  1.85 GBytes  1.59 Gbits/sec
[  7]  0.0-10.0 sec  3.72 GBytes  3.19 Gbits/sec
[  3]  0.0-10.0 sec  1.82 GBytes  1.56 Gbits/sec
[SUM]  0.0-10.0 sec  11.2 GBytes  9.62 Gbits/sec

2. Iperf Server: OmniOS@HPMSGen8; Iperf Client: Ubuntu-VM@Hyper-V@T20 (andere Richtung)
"iperf-s" / "iperf -c IP"
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.2, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 10.10.12.1 port 42366 connected with 10.10.12.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  2.22 GBytes  1.91 Gbits/sec

"iperf-s" / "iperf -c IP -P 5"
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.2, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  7] local 10.10.12.1 port 42378 connected with 10.10.12.2 port 5001
[  4] local 10.10.12.1 port 42374 connected with 10.10.12.2 port 5001
[  6] local 10.10.12.1 port 42377 connected with 10.10.12.2 port 5001
[  5] local 10.10.12.1 port 42376 connected with 10.10.12.2 port 5001
[  3] local 10.10.12.1 port 42375 connected with 10.10.12.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  7]  0.0-10.0 sec  1.13 GBytes   971 Mbits/sec
[  4]  0.0-10.0 sec  1.18 GBytes  1.02 Gbits/sec
[  6]  0.0-10.0 sec  1.15 GBytes   985 Mbits/sec
[  5]  0.0-10.0 sec  1.11 GBytes   954 Mbits/sec
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec
[SUM]  0.0-10.0 sec  5.67 GBytes  4.87 Gbits/sec

3. Iperf Server: Hyper-V@T20; Iperf Client: OmniOS@HPMSGen8 (Probe mit Hyper-V@T20 direkt)
"iperf-s" / "iperf -c IP"
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.24, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.12.2 port 54897 connected with 10.10.12.24 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.79 GBytes  1.53 Gbits/sec

"iperf-s" / "iperf -c IP -P 5"
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.24, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.12.2 port 61116 connected with 10.10.12.24 port 5001
[  6] local 10.10.12.2 port 62255 connected with 10.10.12.24 port 5001
[  7] local 10.10.12.2 port 38434 connected with 10.10.12.24 port 5001
[  5] local 10.10.12.2 port 56904 connected with 10.10.12.24 port 5001
[  4] local 10.10.12.2 port 45587 connected with 10.10.12.24 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 GBytes  1.07 Gbits/sec
[  6]  0.0-10.0 sec  1.25 GBytes  1.07 Gbits/sec
[  7]  0.0-10.0 sec  1.26 GBytes  1.08 Gbits/sec
[  5]  0.0-10.0 sec  1.32 GBytes  1.13 Gbits/sec
[  4]  0.0-10.0 sec  1.28 GBytes  1.10 Gbits/sec
[B][SUM]  0.0-10.0 sec  6.35 GBytes  5.45 Gbits/sec[/B]

4. Iperf Server: OmniOS@HPMSGen8; Iperf Client: Hyper-V@T20 (wieder anders herum)
"iperf-s" / "iperf -c IP"
Code: 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  125 KByte (default)
------------------------------------------------------------
[  4] local 10.10.12.2 port 5001 connected with 10.10.12.24 port 49617
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec   220 MBytes   183 Mbits/sec

"iperf-s" / "iperf -c IP -P 5"
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.2, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.12.24 port 49622 connected with 10.10.12.2 port 5001
[  4] local 10.10.12.24 port 49623 connected with 10.10.12.2 port 5001
[  7] local 10.10.12.24 port 49626 connected with 10.10.12.2 port 5001
[  5] local 10.10.12.24 port 49624 connected with 10.10.12.2 port 5001
[  6] local 10.10.12.24 port 49625 connected with 10.10.12.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  7]  0.0- 7.0 sec   136 MBytes   163 Mbits/sec
[  6]  0.0- 7.0 sec   158 MBytes   188 Mbits/sec
[  5]  0.0- 7.0 sec   169 MBytes   202 Mbits/sec
[  3]  0.0-10.1 sec  27.4 MBytes  22.7 Mbits/sec
[  4]  0.0-10.1 sec  22.8 MBytes  18.8 Mbits/sec
[SUM]  0.0-10.1 sec   513 MBytes   425 Mbits/sec

5. Iperf Server: Win7-Workstation; Iperf Client: Ubuntu-VM@Hyper-V@T20 (Anderer Rechner anstatt HP)
"iperf-s" / "iperf -c IP"
Code: 
------------------------------------------------------------
Client connecting to 10.10.10.10, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.10.1 port 40124 connected with 10.10.10.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   892 MBytes   748 Mbits/sec

iperf -s / iperf -c IP -P 5
Code: 
------------------------------------------------------------
Client connecting to 10.10.10.10, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  7] local 10.10.10.1 port 40129 connected with 10.10.10.10 port 5001
[  4] local 10.10.10.1 port 40125 connected with 10.10.10.10 port 5001
[  3] local 10.10.10.1 port 40126 connected with 10.10.10.10 port 5001
[  6] local 10.10.10.1 port 40128 connected with 10.10.10.10 port 5001
[  5] local 10.10.10.1 port 40127 connected with 10.10.10.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  7]  0.0-10.0 sec   523 MBytes   439 Mbits/sec
[  3]  0.0-10.0 sec   624 MBytes   523 Mbits/sec
[  4]  0.0-10.0 sec   613 MBytes   514 Mbits/sec
[  6]  0.0-10.0 sec   671 MBytes   562 Mbits/sec
[  5]  0.0-10.0 sec   615 MBytes   516 Mbits/sec
[SUM]  0.0-10.0 sec  2.97 GBytes  2.55 Gbits/sec

6. Iperf Server: Ubuntu-VM@Hyper-V@T20; Iperf Client: Win7-Workstation (Wieder andersrum)
iperf -s / iperf -c IP
Code: 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.10.10.1 port 5001 connected with 10.10.10.10 port 55244
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.05 GBytes   901 Mbits/sec

iperf -s / iperf -c IP -P 5
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
Code: 
------------------------------------------------------------
[  4] local 10.10.10.1 port 5001 connected with 10.10.10.10 port 55246
[  5] local 10.10.10.1 port 5001 connected with 10.10.10.10 port 55249
[  6] local 10.10.10.1 port 5001 connected with 10.10.10.10 port 55245
[  7] local 10.10.10.1 port 5001 connected with 10.10.10.10 port 55247
[  8] local 10.10.10.1 port 5001 connected with 10.10.10.10 port 55248
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   677 MBytes   567 Mbits/sec
[  5]  0.0-13.0 sec   981 MBytes   632 Mbits/sec
[  6]  0.0-13.0 sec   840 MBytes   541 Mbits/sec
[  7]  0.0-13.0 sec   826 MBytes   532 Mbits/sec
[  8]  0.0-13.1 sec   851 MBytes   547 Mbits/sec
[SUM]  0.0-13.1 sec  4.08 GBytes  2.68 Gbits/sec

7. Iperf Server: Hyper-V@T20; Iperf Client: Win7-Workstation (nochmal mit'm Hyper-V direkt)
iperf -s / iperf -c IP
Code: 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  4] local 10.10.10.24 port 5001 connected with 10.10.10.10 port 55275
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.32 GBytes  1.13 Gbits/sec

iperf -s / iperf -c IP -P 5
Code: 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  4] local 10.10.10.24 port 5001 connected with 10.10.10.10 port 55275
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.32 GBytes  1.13 Gbits/sec
[  4] local 10.10.10.24 port 5001 connected with 10.10.10.10 port 55279
[  5] local 10.10.10.24 port 5001 connected with 10.10.10.10 port 55278
[  6] local 10.10.10.24 port 5001 connected with 10.10.10.10 port 55276
[  7] local 10.10.10.24 port 5001 connected with 10.10.10.10 port 55280
[  8] local 10.10.10.24 port 5001 connected with 10.10.10.10 port 55277
[  4]  0.0-10.1 sec  1.14 GBytes   973 Mbits/sec
[  5]  0.0-10.1 sec  1.08 GBytes   926 Mbits/sec
[  6]  0.0-10.1 sec  1.13 GBytes   964 Mbits/sec
[  7]  0.0-10.2 sec  1.13 GBytes   949 Mbits/sec
[  8]  0.0-10.1 sec  1.08 GBytes   923 Mbits/sec
[SUM]  0.0-10.2 sec  5.56 GBytes  4.67 Gbits/sec

8. Iperf Server: Win7-Workstation; Iperf Client: Hyper-V@T20 (weil's so schön war, nochmal andersrum)
iperf -s / iperf -C IP
Code: 
------------------------------------------------------------
Client connecting to 10.10.10.10, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.10.24 port 49666 connected with 10.10.10.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.67 GBytes  1.43 Gbits/sec

iperf -s / iperf -c IP -P 5
Code: 
------------------------------------------------------------
Client connecting to 10.10.10.10, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  7] local 10.10.10.24 port 49672 connected with 10.10.10.10 port 5001
[  5] local 10.10.10.24 port 49670 connected with 10.10.10.10 port 5001
[  3] local 10.10.10.24 port 49668 connected with 10.10.10.10 port 5001
[  4] local 10.10.10.24 port 49669 connected with 10.10.10.10 port 5001
[  6] local 10.10.10.24 port 49671 connected with 10.10.10.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  7]  0.0-10.2 sec   476 MBytes   392 Mbits/sec
[  5]  0.0-10.0 sec   685 MBytes   575 Mbits/sec
[  3]  0.0-10.0 sec   673 MBytes   565 Mbits/sec
[  4]  0.0-10.0 sec   703 MBytes   590 Mbits/sec
[  6]  0.0-10.0 sec   647 MBytes   543 Mbits/sec
[SUM]  0.0-10.2 sec  3.11 GBytes  2.62 Gbits/sec

Fazit 1: Lustig, dass der Hyper-V host mit OmniOS als Gegenstück (deutlich) lahmer ist, als seine gehostete VM am selben (virtuellen) Switch.
Fazit 2: Richtig flott ist mit nur einer TCP-Verbindung nur die Richtung OmniOS als Client und Ubuntu-VM als Server.
Fazit 3: bis auf unter 4. oben lässt sich mit -P 5 noch speed "rausholen".
Fazit 4: OmniOS als iperf Server bringt die schlechteste Performance auf's Kabel.

Nur - was sagt mir das nun für die nächsten sinnvollen Schritte?

Werde bei Gelegenheit mal die Netzwerkspeed testen mit einem anderen OS auf dem T20 bzw. auf dem Gen8.

Oder hat jemand sonst noch eine Idee, wo ich ansetzen sollte/könnte, insbesondere um sich dem Ganzen "strategisch" sinnvoll zu nähern?
 
So. Da ich ja noch'n USB-Stick mit Solaris 11.3(beta) hab, den mal bare-metal im T20 gebootet.

9. HP=Client, T20=Server wie gehabt schnell:
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.1, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.12.2 port 42214 connected with 10.10.12.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  9.42 GBytes  8.09 Gbits/sec

11. Jetzt aber auch umgekehrt flott, also HP=Server; T20=Client (!):
Code: 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  125 KByte (default)
------------------------------------------------------------
[  4] local 10.10.12.2 port 5001 connected with 10.10.12.1 port 58974
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  9.35 GBytes  8.02 Gbits/sec

Fazit: Yay... die Hardware kann's... ;)


Nachwievor etwas mau sieht's allerdings immer noch mit 12. Win7 --> T20 (jetzt mit Solaris) aus:
Transfer 2,21GBytes / Bandwidth 1,90Gbits/s

bzw. mit "-P 5":
Transfer 8,51GBytes / Bandwidth 7,30Gbits/s

Na schon besser als der olle Hyper-V...

- - - Updated - - -

So Gegenprobe mit Ubuntu 15.04 "Live CD" auf der ehemaligen "Win7-Workstation":

13. Solaris@T20=Server; Ubuntu@Workstation=Client
Code: 
------------------------------------------------------------
Client connecting to 10.10.10.1, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.10.10 port 46125 connected with 10.10.10.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  9.03 GBytes  7.76 Gbits/sec
14. Und umgekehrt: ubuntu@Workstation=Server; Solaris@T20=Client
Code: 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.10.10.10 port 5001 connected with 10.10.10.1 port 51984
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  10.9 GBytes  9.40 Gbits/sec
Yeah Baby! :banana:

Es ist also ein "Softwareproblem"... ;)

- - - Updated - - -

Und noch eine Testreihe, jetzt wieder mit dem T20+Hyper-V+UbuntuVM und immer noch Workstation+UbuntuLiveCD:

15. VM=Client; Workstation=Server
Code: 
------------------------------------------------------------
Client connecting to 10.10.10.10, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.10.1 port 55442 connected with 10.10.10.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  6.62 GBytes  5.68 Gbits/sec

16. Vice versa Workstation=Client; VM=Server
Code: 
------------------------------------------------------------
Client connecting to 10.10.10.1, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 10.10.10.10 port 46329 connected with 10.10.10.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  8.97 GBytes  7.70 Gbits/sec

Ich versteh einfach nicht, warum mit identischen Settings die eine Richtung in diesem Szenario besser ist, als die andere!

- - - Updated - - -

Also ich hab jetzt mal mit ein paar verschiedenen VMs auf dem T20 herumprobiert, aber auch die kommen ohne "-P 5" Parameter auch nur auf max 2Gbit/s "nach draussen" (also ueber's Kabel). Da ist irgendwas im argen...

Koennte natuerlich auch an der Server Technical Preview liegen... boah hab ich lust, jetzt testweise noch einen 2012R2 aufzusetzen...

- - - Updated - - -

17. jetzt auch mal Ubuntu-Live-CD auf dem HP gebootet.

Gleiches Bild. HP als Server ist langsamer als der T20@Hyper-V@UbuntuVM als Server:
Code: 
UbuntuVM$ iperf -c 10.10.12.2
------------------------------------------------------------
Client connecting to 10.10.12.2, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.12.1 port 43199 connected with 10.10.12.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  5.79 GBytes  4.97 Gbits/sec
Code: 
UbuntuVM$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.10.12.1 port 5001 connected with 10.10.12.2 port 38808
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  8.99 GBytes  7.72 Gbits/sec

Der Win10PC mit dem HP ist wie immer deutlich langsamer...

- - - Updated - - -

18. und noch die Intel AT2 Adapter unter sich, also Workstation Direktverbindung mit dem Win10-TestPC, yunaechst in einer gemischten Umgebung (Ubuntu-LIve-CD + Win10):

Code: 
ubuntu@ubuntu:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.10.13.2 port 5001 connected with 10.10.13.3 port 50767
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  3.01 GBytes  2.59 Gbits/sec
^Cubuntu@ubuntu:~$ iperf -c 10.10.13.3
------------------------------------------------------------
Client connecting to 10.10.13.3, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 10.10.13.2 port 43089 connected with 10.10.13.3 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  3.20 GBytes  2.75 Gbits/sec

- - - Updated - - -

19. Und wir schließen mit noch einmal den AT2-Adaptern, diesmal in der reinen Windows-Welt (Win10/Win7):
Code: 
c:\IPERF>iperf -c 10.10.10.10
------------------------------------------------------------
Client connecting to 10.10.10.10, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.10.3 port 50849 connected with 10.10.10.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  2.41 GBytes  2.07 Gbits/sec

c:\IPERF>iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[  4] local 10.10.10.3 port 5001 connected with 10.10.10.10 port 49853
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.85 GBytes  1.58 Gbits/sec

Windows SUXX (im Netz) :d

Jetzt könnte ich noch einmal auch auf diesen beiden Kisten ubuntu/ubuntu testen, aber nach 19+ Testläufen hab ich da jetzt keinen Bock mehr drauf...
 
Zuletzt bearbeitet:
So, ich lese jetzt erstmal den - m.E. nach erstem Teil-Lesen ziemlich informativen - 2012R2 Performance Tuning Guide von Microsoft, hat sogar einen Abschnitt zu Hyper-V (ab Seite 136, spannend insbesondere ab 155)...

Einige Augenöffner hatte ich schon, und da steckt noch ein Haufen Musik drin.
 
Windows (7) ist toll. Nur weil man im Treiber Jumbo Frames aktiviert hat, heißt das noch lange nicht, dass Jumbo Frames aktiviert sind.

Drauf gekommen bin ich, weil ein ping mit spezifischen Paketgrößen und "verbotener Fragmentierung" zu einer Fehlermeldung führte:
Code: 
C:\Users\>ping 10.10.10.1 -f -l 4000

Ping wird ausgeführt für 10.10.10.1 mit 4000 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik für 10.10.10.1:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust)

Ich hatte im Treiber natürlich unter "Erweitert" --> Jumbo Frames 9014 stehen. Doch:
Code: 
C:\Windows\system32>netsh interface ipv4 show subinterfaces

   MTU  Medienerkennungsstatus   Bytes eingehend  Bytes ausgehend  Schnittstelle

------  ---------------  ---------  ---------  -------------
4294967295                1          0      31213  Loopback Pseudo-Interface 1
  1500                1    4519506     803113  LAN-Verbindung
  1500                1          0      37701  VirtualBox Host-Only Network
  1500                5          0          0  LAN-Verbindung 2
  1400                5          0          0  LAN-Verbindung* 13
[B]  1500                1      12807      44420  LAN-Verbindung 3[/B]

...behauptete etwas anderes (LAN-3 ist die 10GBE-NIC). Also habe ich dann mal manuell mit einer cmd (als Administrator ausführen!) die MTU gesetzt:
Code: 
C:\Windows\system32>netsh interface ipv4 set subinterface "LAN-Verbindung 3" mtu
=9014 store=persistent
OK.

Erste Probe:
Code: 
C:\Windows\system32>netsh interface ipv4 show subinterfaces

   MTU  Medienerkennungsstatus   Bytes eingehend  Bytes ausgehend  Schnittstelle

------  ---------------  ---------  ---------  -------------
4294967295                1          0      49628  Loopback Pseudo-Interface 1
  1500                1    4802694     984746  LAN-Verbindung
  1500                1          0      54456  VirtualBox Host-Only Network
  1500                5          0          0  LAN-Verbindung 2
  1400                5          0          0  LAN-Verbindung* 13
[B]  9014                5          0          0  LAN-Verbindung 3[/B]

Aha!

Pingtest:
Code: 
C:\Users\Martin>ping 10.10.10.1 -f -l 8972

Ping wird ausgeführt für 10.10.10.1 mit 8972 Bytes Daten:
Antwort von 10.10.10.1: Bytes=8972 Zeit<1ms TTL=64
Antwort von 10.10.10.1: Bytes=8972 Zeit<1ms TTL=64
Antwort von 10.10.10.1: Bytes=8972 Zeit<1ms TTL=64
Antwort von 10.10.10.1: Bytes=8972 Zeit<1ms TTL=64

Ping-Statistik für 10.10.10.1:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust)

Na also. Interessiert iperf allerdings (noch) nicht wirklich...
 
Ich schnall' das einfach nicht. Ich bekomme den Hyper-V Server nicht dazu überredet, schnelle ~10GB (8 wäre ja auch ok) TCP-Sendungen auf einem TCP-Kanal aufzubauen. Ich habe jetzt mal für die physischen Adapter (zur Erinnerung: Intel x540-T2) drei von den Standards abweichende Settings angepasst (Receive Buffers=4096; Transmit Buffers=16384; Jumbo Frames=9014) und alle vSwitches neu aufgesetzt. Darin brav SR/IOV aktiviert und beide Ports exklusiv genau einer VM zugewiesen, nämlich der Ubuntu-Fileserver-VM.

Von der VM bekomme ich also zum OmniOS-HP (auch Intel x540-T2) immerhin "hin-und-zurück" mit iperf und 10 TCP-streams ganz gute Werte (alles folgende sind Anzeigen vom HP mit OmniOS):
Code: 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  125 KByte (default)
------------------------------------------------------------
[  4] local 10.10.12.2 port 5001 connected with 10.10.12.1 port 40954
[ ID] Interval       Transfer     Bandwidth
[  8]  0.0-10.0 sec   975 MBytes   816 Mbits/sec
[  6]  0.0-10.0 sec   990 MBytes   828 Mbits/sec
[  7]  0.0-10.0 sec   872 MBytes   730 Mbits/sec
[ 10]  0.0-10.0 sec   983 MBytes   822 Mbits/sec
[ 11]  0.0-10.0 sec   983 MBytes   822 Mbits/sec
[ 12]  0.0-10.1 sec   993 MBytes   828 Mbits/sec
[ 13]  0.0-10.0 sec   986 MBytes   824 Mbits/sec
[  4]  0.0-10.1 sec   875 MBytes   728 Mbits/sec
[  9]  0.0-10.1 sec   981 MBytes   816 Mbits/sec
[  5]  0.0-10.1 sec   976 MBytes   811 Mbits/sec
[SUM]  0.0-10.1 sec  9.39 GBytes  7.99 Gbits/sec

Andere Richtung:
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.1, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   598 MBytes   502 Mbits/sec
[  6]  0.0-10.0 sec   868 MBytes   728 Mbits/sec
[  9]  0.0-10.0 sec   967 MBytes   811 Mbits/sec
[ 12]  0.0-10.0 sec   571 MBytes   479 Mbits/sec
[  5]  0.0-10.0 sec   575 MBytes   482 Mbits/sec
[  7]  0.0-10.0 sec  1.04 GBytes   896 Mbits/sec
[ 11]  0.0-10.0 sec  1.46 GBytes  1.25 Gbits/sec
[  8]  0.0-10.0 sec  48.0 MBytes  40.2 Mbits/sec
[ 10]  0.0-10.1 sec  65.8 MBytes  54.6 Mbits/sec
[  4]  0.0-10.3 sec  68.8 MBytes  56.2 Mbits/sec
[SUM]  0.0-10.3 sec  6.17 GBytes  5.17 Gbits/sec

Mit einem stream halt immer noch deutlich weniger:
Code: 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  125 KByte (default)
------------------------------------------------------------
[  4] local 10.10.12.2 port 5001 connected with 10.10.12.1 port 40971
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  2.04 GBytes  1.75 Gbits/sec

Andere Richtung:
Code: 
------------------------------------------------------------
Client connecting to 10.10.12.1, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[  3] local 10.10.12.2 port 39998 connected with 10.10.12.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  4.79 GBytes  4.11 Gbits/sec

Mit einer Win10-VM sieht's übrigens ziemlich ähnlich aus: ein stream 1-2Gb/s, 10 streams 6-7Gb/s; empfangen (Win10 als iperf-server) geht noch etwas schneller als schicken (Win10 als iperf-client).

Falls hier nach meinem ganzen Gespamme überhaupt noch jemand mitliest: Hat jemand noch eine Idee, was ich ausprobieren könnte? Auf dem Hyper-V, in der VM oder auch unter OmniOS? Wenn's geht, ohne dass ich mich in die diversen Windows Performance Counter einfuxxen muss...
 
Zuletzt bearbeitet:
Eine Lösung habe ich noch nicht, aber ich komme dem Thema vielleicht näher:

Wenn ich mal mit iperf die "Netzwerkperformance" auf ein und demselben Host teste (also auch die Netzwerkkarte als Flaschenhals ausschließe), ist diese bei Windows10 (Desktop) ziemlich bescheiden. Sowohl in einer Win10-VM als auch Win10-Hardware nicht mehr als 5,8Gbit/s Bandbreite!

Linux dagegen kommt auf schlappe 65Gbits/s Bandbreite!

Dabei läuft übrigens Linux auch in einer VM, und zwar auf dem gleichen Hyper-V Server wie die Win10-VM mit ihren ~6Gbit/s... Microsoft will wohl keinen flotten TCP-Stack für Desktops/Workstations.

Selbst eine weitere VM mit einem 32Bit Linux (Gen 1 VM) kommt noch auf "nur" 35Gbit/s Bandbreite....

Der Hyper-V selbst hat witzigerweise auch gerade mal ~9Gbit/s Bandbreite "intern"...
 
Zuletzt bearbeitet:
Ich lese zwar noch mit, aber da ich weder Solaris, Win10 noch Deine Hardware habe, ... fällt mir nix ein :)
 
Och menno! Und ich hatte so große Hoffnungen in Dich gesetzt! ;-D

Ich lade gerade die Technical Preview 3 (voll und Hyper-V core) runter und werde mal sehen ob sich da was tut. Habe da aber keine große Hoffnung.

Ansonsten wird im nächsten Schritt mal ohne Virtualisierung und ggf. in reiner Windows-Welt getestet.

Ich will einfach nicht glauben, dass sich ein Windows10 Desktop-OS nicht mit annähernd 10gbit an Storage anbinden lassen soll!

Ansonsten erzähl ich mein Problem mal in den engl. Technet Foren von Microsoft, da tummeln sich ja zum Teil echte Cracks. Inzwischen fühle ich mich auch fit genug im Thema, dass ich mich nicht lächerlich mache... ;-) Wenn ich dann noch erläutere, was ich bisher schon ausgetestet habe, kann mir vielleicht doch jemand noch den ein oder anderen Tipp geben, was ich noch ausprobieren kann.
 
So Freunde der Geschwindigkeit.
Ich hab' jetzt mal in der Linux-VM eine zweite VHD als Laufwerk eingehängt, die "physisch" auf einer SSD (Samsung 830) liegt, mit ext4 formatiert und als SMB Share im Netz freigegeben.

Die maximal erreichbaren "lokalen Werte" dieses Laufwerks liegen bei etwa 370MB/s schreibend und 475MB/s lesend (ermittelt mit dem Test von Sir Diablo auf Seite 1):

Lokal Schreiben:
Code: 
#:/media/testdisk# dd if=/dev/zero of=tempfile bs=1M count=8K conv=fdatasync,notrunc
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 23.2082 s, 370 MB/s

Lokal Lesen:
Code: 
root@ZFSZoL:/media/testdisk# dd if=tempfile of=/dev/null bs=1M count=8K
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 18.0784 s, 475 MB/s

Kopiert habe ich nun jeweils eine ca. 20Gigabyte große VHD-Datei auf die SMB Freigabe mit folgenden Ergebnissen:

SMB Schreiben Win10Pro auf SSDVHD@LinuxVM:
SSD-Schreiben.jpg

SMB Lesen Win10Pro von SSDVHD@LinuxVM:
SSD-LESEN.jpg

Die Schreibgeschwindigkeit auf dieser SMB-Freigabe liegt also real bei ca. 375MB/s. Die Lesegeschwindigkeit auch, allerdings mit einer komischen Delle...

Zum Vergleich, Lesen und Schreiben auf dem ZFS-Pool in gleicher LinuxVM:

Lokal Schreiben (223MB/s):
Code: 
#:/ZFSdata/Server# dd if=/dev/zero of=tempfile bs=1M count=8K conv=fdatasync,notrunc
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 38.5309 s, 223 MB/s

Lokal Lesen (320MB/s):
Code: 
#:/ZFSdata/Server# dd if=tempfile of=/dev/null bs=1M count=8K
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 26.7261 s, 321 MB/s

SMB Schreiben Win10Pro auf ZFS-Pool@LinuxVM:
ZFS-Schreiben.jpg


SMB Lesen Win10Pro von ZFS-Pool@LinuxVM:
ZFS-Lesen.jpg

Das heißt für mich jetzt aber doch:

1. Das Netz "funktioniert" mit SMB grundsätzlich flott genug, um den ZFS-Pool mit dessen Maximalgeschwindigkeit bedienen zu können (selbst wenn iperf mit nur einer TCP-Connection bei 1-2gbit/s limitiert ist).

2. Ich muss Ursachenforschung betreiben, warum ich so einen relativ großen Verlust beim Lesen habe - sowohl auf der SSD (Lokal: 475MB/s, über SMB 380MB/s + Delle) als auch auf dem ZFS-Pool (Lokal: 320MB/s, über SMB 180MB/s). Als ersten Anlauf werde ich wohl mal die Settings von Gea ausprobieren (sync & co.)

3. 4x4TB WD Red im RaidZ sind (leider doch) langsamer als 1x Samsung SSD 830... ;)

4. Kurios: Die Kiste schreibt auf den ZFS-pool über SMB schneller als lokal... mag aber an meinen noch nicht angepassten Settings liegen...
 
Ich habe am WE mal kurz mitgespielt.
Da ich die Broadcom Base-T seit einigen Wochen nicht mehr im Betrieb habe, habe ich zwei Brocade 1020 für Server <-> Workstation eingesetzt.
Ich kann Deine Ergebnisse nachvollziehen: Zwischen Workstation (win2012R2) und Ubuntu nur 2-2,5Gbit; Server untereinander (VM->VM/Host) mit 9Gbit.
Ich komme aber erst in den nächsten Wochen zu mehr "Spielzeit".
 
Nur ins Unreine: Es soll helfen (können), das TCP Offloading abzuschalten. Idealerweise auf beiden Maschinen.
Ich probiere das heute Abend aus.
 
Super, vielen Dank für Deinen Einsatz!

Ich habe inzwischen auch den Verdacht (der auch anderer Stelle geäußert wurde), dass iperf für Netz-Performance-Messungen unter Windows nicht uneingeschränkt geeignet ist.

Ferner kommt iperf auch nur auf 6-8gbit Bandbreite lokal auf Win-Systemen, die aber locker die 10Gbit in realen Anwendungen ausschöpfen (SAN-Dateitransfers, Server-Replikation etc.) - hat ein Bekannter netterweise im RZ mal ausgetestet.

Ich denke, ich werde mal mehr mit meiner derzeitigen Fileserver-/ZFS-Installation spielen müssen, einfach um verschiedene Kombinationen auszuprobieren. Ich denke da z.B. an bare-metall Installationen von Solaris11.3+ZFS+RaidZ vs. OmniOS+ZFS+RaidZ vs. Ubuntu+ext4+Raid5 vs. Ubuntu+BTRS+Raid5 vs. 2012R2+StorageSpaces+Parity. Ggf. auch noch mit jeweils Testläufen auf der SSD und/oder in einer Ramdisk.

Am Ende zählt ja, was real nutzbar rauskommt. Ich brauche einerseits nackte Performance zu Windows-Clients (Datensicherheit zweitrangig), gerne über iSCSI, um z.B. Programme von lokalen Platten auszulagern, andererseits für die wichtigen Daten "sichere" Ablage - hier ist die Geschwindigkeit zweitrangig. Ein brauchbarer Kompromiss mit einer einheitlichen Lösung wäre schön, aber zur Not trenne ich halt entsprechend.
 
Ich habe ab nächstem WE auch andere Hardware, dann wird die Workstation auch auf Haswell-E umgestellt. Den Flaschenhals bei 10G -> 2,5G konnte ich ja nicht sehen, wenn ohnehin alles auf Sata2 in der WS läuft ;)
 
Zuletzt bearbeitet:
deleted
 
Zuletzt bearbeitet:
deleted
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh