10GbE LAN, Win10 blijft plakken bij 3Gbps

[McKaamos]

Lieve tweakersvriendjes en vriendinnetjes,
Ik zit met een klein probleempje waar ik niet uit kom. Het zit namelijk zo, ik heb een toffe nieuwe NAS gebouwd met een 10Gbps LAN kaartje. Desktopje ge-upgrade met een zelfde modelletje 10Gbps kaart, switchje er tussen die twee 10Gbps poorten heeft en de rest 1Gbps.
Zodoende kan de desktop met volle snelheid tegen een leuk 6x6TB RAID5 arraytje babbelen, zo was de gedachte.
Helaas blijkt de werkelijkheid iets weerbarstiger.

Situatieschets:

Desktop:
- Skylake i5-6500
- 16GB DDR4 RAM (2*8G)
- Samsung 950 Pro 512GB
- Intel X540-T2 dualport 10GbE LAN adapter (PCIe x8)
- OS: Windows 10 Home

NAS:
- Coffeelake i3-8100T
- 8GB DDR4 RAM (2*4G)
- 6x6TB WD Red in MDADM RAID5
- Sandisk Ultra USB3 stickje als boot drive
- Intel X540-T2 dualport 10GbE LAN adapter (PCIe x8)
- OS: OpenMediaVault 4 (laatste versie, Debian 9 based)

Deze twee machines zijn met elkaar verbonden via een Netgear GS110MX switch. Deze heeft twee 10GbE poorten en 8x 1Gbps poorten. De bekabeling is 2meter Cat7 SSTP (stranded CU) met shielded connectoren naar de PC en 10meter naar de NAS.
Link indicatie geeft netjes 10Gbps Full Duplex aan voor beide machines. Ook de indicatie in software bevestigt dit.
De rest van het LAN (o.a. een Cisco kabelmodem van Ziggo en diverse client devices (printers, twee QNAP NASsen, etc) hangt er via de 1Gbps poorten bij aan met Cat5E bekabeling.

Echter is nu het issue dat zowel Samba (Windows shares) als iPerf tests blijven steken rond de 3Gbps tussen de PC en NAS.

Wat ik al gevonden of geprobeerd heb
Op de Windows bak zijn de laatste drivers van Intel geïnstalleerd. De ProSet utility gebruikt om de recieve en transmit buffers op te schroeven naar maximaal. Jumboframes geactiveerd en de MTU op 9014 gezet.

Op de NAS eveneens de MTU naar 9014 gezet en daarbij wat tweaks toegepast met sysctl.
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"
sysctl -w net.ipv4.tcp_window_scaling=1

Dit levert als resultaat een vrij stabiele +/- 3Gbps. Zowel via SMB als met iPerf3 (vanilla settings).
Zonder de tweaks aan de NAS kant blijft het bij 2,7Gbps steken.

Echter, als ik met iPerf3 aan de client kant de TCP Window Size vast prik op een hoge waarde (iperf3 -w 4M) zit de snelheid zo rond de 9,5-9,8Gbps.
Dus als de TCP window maar voldoende groeit, kan ik de hele 10Gbps zo ongeveer vol rammen.
Zonder tweaks op de NAS maar met vast geprikte window size van 4MB blijft de snelheid bij de 4Gbps steken.

Dus kortgezegd verwacht ik dat Windows 10 niet zo lekker aan TCP Window Scaling doet en ik lijk nergens te kunnen vinden hoe je dat in Windows 10 aanpast. Iemand een idee?

Wat ik onder Windows al wel geprobeerd heb is dit:
netsh interface tcp set global autotuninglevel=experimental
Dit zou tot resultaat moeten hebben dat Windows aggressiever de TCP Window opschaalt en tot hogere waarden gaat dan normaal. Echter haalt dit niks uit.

[ Voor 4% gewijzigd door McKaamos op 28-08-2019 15:34 ]

[MewBie]

Soort gelijke snelheidslimiet en er worden wat settings genoemd:

[McKaamos]

MewBie schreef op woensdag 28 augustus 2019 @ 01:03:
Soort gelijke snelheidslimiet en er worden wat settings genoemd:
[YouTube: 10 Gigabit Networking - I wanna go fast. Really, really fast.]

Wat daar genoemd wordt, is exact wat ik heb gedaan. Helaas maakt het geen verschil.

[Will_M]

Wat meet je als je een crosscable tussen je Windows machine en het NAS zet?

[PcDealer]

Staat autonegotiation aan of vast op 10 GbE?

[ Voor 8% gewijzigd door PcDealer op 28-08-2019 01:53 ]

[Operations]

Is het niet je RAID array die je beperkt? Ik ben niet bekend met OpenVault, dus ik weet niet hoe snel of hoe langzaam het is qua raid). Maar het is en blijft software raid toch? Wel met raid arrays (dan wel gewoon via Windows + Areca kaarten) en 10Gbps netwerken (dan wel via SFP+). Heeft het niet met iets van cache te maken? Als ik een controller met weinig cache gebruik zie ik ook de snelheid fluctueren. Alhoewel jij spreekt over constant, dus zal dan niet iets met cache te maken hebben denk ik.

Je spreekt over 3Gbps, dus je snelheid zal dan max 300MB/s zijn ongeveer? Ik zelf haal 700/800MB/s van machines die met 10Gbps zijn verbonden (allemaal Server2019). En wanneer ik iets pak van een SSD raid10 array dan trek ik de 10Gbps helemaal vol zeg maar.

Heb je die 10Gbps kaart uit de NAS toevallig al eens in een andere pc geprobeerd? Haalde je toen wel de volle snelheid?

Welke iperf commando's gebruik je?

[ Voor 61% gewijzigd door Operations op 28-08-2019 05:58 ]

[Verwijderd]

Samenvatting van je verhaal:

(1) Windows 10 |-— cat7 —-| (2) switch (GS110MX) |—- cat7 —-| (3) Linux NAS

Na tweaken Windows10 TCP is 10Gbps wel mogelijk (iperf, NAS server, Windows Client)

Hardware is dus goed. NAS server is goed. Volgens mij kun je nu volledig richten op een Windows probleem, zoals je zelf al aan geeft.

Dit om suggesties over RAID, kabels, switch etc. te voorkomen.

[rens-br]

Dit lijkt vooralsnog weinig met het netwerk zelf te maken, maar lijkt meer op een Windows / Nas probleem. Ik verhuis het topic dus even van NT naar WOS.

[McKaamos]

wimmel_1 schreef op woensdag 28 augustus 2019 @ 01:42:
Wat meet je als je een crosscable tussen je Windows machine en het NAS zet?

Niet getest. Lijkt me ook niet echt relevant, gezien ik de 10Gbps haal als ik de windowsize vast pin in iperf.
Crosscables zijn overbodig tegenwoordig trouwens, elke netwerkkaart doet tegenwoordig aan Auto MDI-X

PcDealer schreef op woensdag 28 augustus 2019 @ 01:52:
Staat autonegotiation aan of vast op 10 GbE?

Auto Negotiate. In de ProSet util van Intel kan ik 'm niet vastzetten op 10GbE.

Operations schreef op woensdag 28 augustus 2019 @ 05:51:
Is het niet je RAID array die je beperkt? Ik ben niet bekend met OpenVault, dus ik weet niet hoe snel of hoe langzaam het is qua raid). Maar het is en blijft software raid toch? Wel met raid arrays (dan wel gewoon via Windows + Areca kaarten) en 10Gbps netwerken (dan wel via SFP+). Heeft het niet met iets van cache te maken? Als ik een controller met weinig cache gebruik zie ik ook de snelheid fluctueren. Alhoewel jij spreekt over constant, dus zal dan niet iets met cache te maken hebben denk ik.

Je spreekt over 3Gbps, dus je snelheid zal dan max 300MB/s zijn ongeveer? Ik zelf haal 700/800MB/s van machines die met 10Gbps zijn verbonden (allemaal Server2019). En wanneer ik iets pak van een SSD raid10 array dan trek ik de 10Gbps helemaal vol zeg maar.

Heb je die 10Gbps kaart uit de NAS toevallig al eens in een andere pc geprobeerd? Haalde je toen wel de volle snelheid?

Welke iperf commando's gebruik je?

RAID Array haalt volgens Bonnie++ (benchmarking tool) 600M write en 1,1G Read sequential. Dus nee, ik denk niet dat de RAID array het issue is.

OpenMediaVault (OMV) is onder de motorkap gewoon Debian 9 met MDADM. Technisch gezien is het gewoon een NAS-look schilletje om een standaard Debian install. Dus als je daar wat van weet, hoef je geen OMV kenner te zijn
En idd, constant, geen cache gejengel. Ik test nu ook primair in iPerf, gezien de Windows client uberhaupt niet boven de 3Gbps uit wil komen. Eerst even zorgen dat het netwerktechnisch goed is en dan zien we wel weer hoe ver we komen met transfers vanaf de storage.

Swappen van de kaarten heb ik niet geprobeerd.

Aan de NAS kant: iperf3 -s
Aan de desktop kant:
iperf3 -c xxx.xxx.xxx.xxx -t 60 -> 3Gbps
iperf3 -c xxx.xxx.xxx.xxx -t 60 -w 4M -> 10Gbps

Verwijderd schreef op woensdag 28 augustus 2019 @ 08:02:
Samenvatting van je verhaal:

(1) Windows 10 |-— cat7 —-| (2) switch (GS110MX) |—- cat7 —-| (3) Linux NAS

Na tweaken Windows10 TCP is 10Gbps wel mogelijk (iperf, NAS server, Windows Client)

Hardware is dus goed. NAS server is goed. Volgens mij kun je nu volledig richten op een Windows probleem, zoals je zelf al aan geeft.

Dit om suggesties over RAID, kabels, switch etc. te voorkomen.

Spijker op z'n kop,
Hardware is goed, NAS is goed, met forceren van de TCP Window Size haal ik netjes de 10Gbps.
Zodra de Windows client zélf zijn TCP Window Size mag gaan bepalen, gaat het mis.

[Blasterxp]

En cpu load? Aan welke kant is die het hoogst?

[McKaamos]

Blasterxp schreef op woensdag 28 augustus 2019 @ 10:00:
En cpu load? Aan welke kant is die het hoogst?

Op de desktop 6% en de NAS 11%.
Kortom, die zitten uit hun neuzen te eten

[Blasterxp]

das echt niets idd.. dan lijkt dat niet het probleem te zijn!

[Ravefiend]

McKaamos schreef op woensdag 28 augustus 2019 @ 10:04:
[...]

Op de desktop 6% en de NAS 11%.
Kortom, die zitten uit hun neuzen te eten

Behalve wanneer je door het gekozen transfer protocol maar gebruik kan maken van 1 CPU core die dan wel tegen de 100% aan zit, en je andere cores dus geen werk krijgen.

[menonv]

Ik vermoed dat je tegen de limits aanloopt van RAID5 wat betreft de snelheden.
Just for the fun, probeer het ook eens te testen met een RAID10 setup?
Ik heb een QNAP TS-832x een keertje geconfigureerd met 8 x 2TB en dat bleef ook "hangen" rond de 400 a 450mb/sec met RAID5. Was overigens met nette WD20EFRX's.

[McKaamos]

Ravefiend schreef op woensdag 28 augustus 2019 @ 10:11:
[...]


Behalve wanneer je door het gekozen transfer protocol maar gebruik kan maken van 1 CPU core die dan wel tegen de 100% aan zit, en je andere cores dus geen werk krijgen.

T zijn twee quadcores, dus ook als je op die manier rekent zou je minstens 25% moeten zien om 1 core pinned op 100% te hebben.

menonv schreef op woensdag 28 augustus 2019 @ 10:13:
Ik vermoed dat je tegen de limits aanloopt van RAID5 wat betreft de snelheden.
Just for the fun, probeer het ook eens te testen met een RAID10 setup?
Ik heb een QNAP TS-832x een keertje geconfigureerd met 8 x 2TB en dat bleef ook "hangen" rond de 400 a 450mb/sec met RAID5. Was overigens met nette WD20EFRX's.

Nee, ik loop niet tegen de limits van de RAID set aan. Die test ik niet eens, ik test puur network performance. De array wordt niet geraakt.

Wat betreft Qnap: deze NAS is gebouwd om die trage Qnap rommel te vervangen. Er staat nu al een TS419 met 4x2TB WD Red in RAID5 en dat haalt net 300-350Mbps (30MB/s).
Maargoed, dat valt te verwachten van een CPU die bijna direct uit een mobieltje is getrokken en gecombineerd met 512MB RAM.

[ Voor 50% gewijzigd door McKaamos op 28-08-2019 10:16 ]

[fietser1997]

Zou je kunnen proberen om in windows een ram disk aan te maken en dan over te kopieren naar je nas en ook terug en dan de informatie plaatsen? inclusief de screenshots van je snelheid? En dit ook een keer proberen met terracopy? Ik heb het gevoel dat het probleem ergens in windows caching zit ik heb er ook last van gehad. Terracopy gebruikt de linux manier van bestandsverplaatsing.

[KillerAce_NL]

Heb je al eens getest met nic offloading uit ? Server 2016 heeft daar bij high speed networks ook wel eens problemen mee.

Open Start > Run, type regedit, and then click OK.

Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
In the right pane, ensure that the DisableTaskOffload registry entry exists. If this entry does not exist, use the following steps to add the entry:

On the Edit menu, go to New and then click DWORD Value.

Type DisableTaskOffload and then press Enter.

Click DisableTaskOffload.

On the Edit menu, click Modify.
Type 1 in the Value field and then press Enter.

Close Registry Editor.

[ Voor 70% gewijzigd door KillerAce_NL op 28-08-2019 10:16 ]

[McKaamos]

fietser1997 schreef op woensdag 28 augustus 2019 @ 10:13:
Zou je kunnen proberen om in windows een ram disk aan te maken en dan over te kopieren naar je nas en ook terug en dan de informatie plaatsen? inclusief de screenshots van je snelheid? En dit ook een keer proberen met terracopy? Ik heb het gevoel dat het probleem ergens in windows caching zit ik heb er ook last van gehad. Terracopy gebruikt de linux manier van bestandsverplaatsing.

Ik test niet tegen storage. Ik test pure LAN performance.
De RAID set en/of storage van de desktop is van later zorg, mocht die langzaam blijken te zijn. (wat ik niet verwacht, maargoed)

KillerAce_NL schreef op woensdag 28 augustus 2019 @ 10:16:
Heb je al eens getest met nic offloading uit ? Server 2016 heeft daar bij high speed networks ook wel eens problemen mee.


[...]

Dat ga ik eens uitproberen. Dankje
Server2016 staat vziw wel op een soortgelijke kernel aan Windows10, dus dat zou dezelfde issues kunnen hebben met high-speed LAN.

Momenteel ben ik niet in de gelegenheid (setup staat elders, gebouwd voor vrienden), maar zodra ik weer aan het testen kan, lijkt me dit een goeie

[ Voor 28% gewijzigd door McKaamos op 28-08-2019 10:23 ]

[menonv]

McKaamos schreef op woensdag 28 augustus 2019 @ 10:13:
[...]

T zijn twee quadcores, dus ook als je op die manier rekent zou je minstens 25% moeten zien om 1 core pinned op 100% te hebben.


[...]

Nee, ik loop niet tegen de limits van de RAID set aan. Die test ik niet eens, ik test puur network performance. De array wordt niet geraakt.

Wat betreft Qnap: deze NAS is gebouwd om die trage Qnap rommel te vervangen. Er staat nu al een TS419 met 4x2TB WD Red in RAID5 en dat haalt net 300-350Mbps (30MB/s).
Maargoed, dat valt te verwachten van een CPU die bijna direct uit een mobieltje is getrokken en gecombineerd met 512MB RAM.

Lol, ik bedoelde de "echte" 300 - 350 MB/sec met die QNAP 832X, geen mbits meuk.
Maargoed. Denk eraan dat RAID5 gewoon een write penalty heeft vanwege de parity.
Gewoon langzaam dingetjes proberen uit te sluiten. Eventueel zelfs nog point to point met de kabel ertussen en static ip's.

[McKaamos]

menonv schreef op woensdag 28 augustus 2019 @ 11:20:
[...]


Lol, ik bedoelde de "echte" 300 - 350 MB/sec met die QNAP 832X, geen mbits meuk.
Maargoed. Denk eraan dat RAID5 gewoon een write penalty heeft vanwege de parity.
Gewoon langzaam dingetjes proberen uit te sluiten. Eventueel zelfs nog point to point met de kabel ertussen en static ip's.

Haha, nou, die TS419 is niet zo snel als de Qnap van jou Die blijft toch echt hangen bij 300Mbps (30MB/s).
Jouwe zal absoluut krachtiger zijn. Zag ze al met een quadcore en 8GB RAM.
Dit is is een singlecore ARM based dingetje met 512MB RAM.
Prijstechnisch is het interressanter om zelf te bouwen, dus zodoende dat er voor deze route is gekozen. (plus dat ik t gewoon leuk vind om dit soort projectjes te doen )

Maargoed, de storage raak ik momenteel niet met testen. Het is pure LAN performance en ik weet al dat 10Gbps gehaald kan worden als de TCP Window Size groot genoeg is.
Echter lijkt Windows10 deze niet op te schalen naar een voldoende grote waarde.

Dus gepiel met directe connecties, vaste IP adressen, e.d. is wat dat betreft al een gepasseerd station. Het is bekend dat de setup zoals beschreven 10Gbps kan halen onder de juiste condities.
De vraag is meer hoe de juiste condities gecreeerd kunnen worden, gezien Windows het niet vanzelf lijkt te doen middels zijn auto-tuning features.

edit:
Dit alles gezegd hebbende, ik heb de RAID array al wel gebenchmarked met Bonnie++ en haal 600MB/s sequentiele write en 1,1GB/s sequentiele read. Het is niet alsof overdracht van array naar LAN de readspeed vierendeelt, mits voldoende bandbreedte en rekenkracht in de NAS zelf (en ja, een quadcore i3 met 8GB RAM en PCIe 3.0 zou toch écht genoeg moeten zijn )

[ Voor 13% gewijzigd door McKaamos op 28-08-2019 11:34 ]

[ehtweak]

Aangezien ik zelf ook nog al aan het stoeien ben geweest met Static Link Aggregation en ANS i.c.m. Intel NICs en Windows 10.
Win10 + Intel NIC --> geen VLAN/Teaming/ANS*

Zeker weten dat je de meest recente driver gebruikt?
Want in de laatste driver releases (vanaf 24.x en verder) zijn er weer een hoop zaken aangepast i.c.m. de meest recente Windows versies.
https://downloadcenter.intel.com/download/22283

[Brahiewahiewa]

McKaamos schreef op woensdag 28 augustus 2019 @ 08:50:
[...]

RAID Array haalt volgens Bonnie++ (benchmarking tool) 600M write en 1,1G Read sequential. Dus nee, ik denk niet dat de RAID array het issue is.

Zegt Bonnie++ ook iets over random reads en writes? Network I/O is van nature niet sequential

[McKaamos]

ehtweak schreef op woensdag 28 augustus 2019 @ 21:26:
Aangezien ik zelf ook nog al aan het stoeien ben geweest met Static Link Aggregation en ANS i.c.m. Intel NICs en Windows 10.
Win10 + Intel NIC --> geen VLAN/Teaming/ANS*

Zeker weten dat je de meest recente driver gebruikt?
Want in de laatste driver releases (vanaf 24.x en verder) zijn er weer een hoop zaken aangepast i.c.m. de meest recente Windows versies.
https://downloadcenter.intel.com/download/22283

Yep, absoluut zeker de laatste driver, namelijk deze: https://downloadcenter.in...Windows-10?product=192957

Wat betreft aanpassingen/releasenotes zie ik geen dingen die ogenschijnlijk te maken hebben met het issue.

Brahiewahiewa schreef op donderdag 29 augustus 2019 @ 02:11:
[...]

Zegt Bonnie++ ook iets over random reads en writes? Network I/O is van nature niet sequential

Even kort door de bocht: Da's niet interessant op dit moment. Ik zit met het issue dat Windows 10 geen 10Gbps wil halen als hij zelf de window size en scaling regelt.
Bonnie++ geeft wel resultaten voor allerlei scenario's, dus die data heb ik.

Om er toch even op in te gaan
Netwerk I/O met TCP/IP is inderdaad niet persé sequentieel.
Je aangevraagde download wordt echter weldegelijk sequentieel van disk gelezen en gaat op volgorde de netwerkinterface uit. Of het, wegens routering of packetloss/hertransmissie, op dezelfde volgorde aankomt? sja dat is de vraag.
Echter hebben we hier niet te maken met routering, dus volgorde wijziging door het gebruik van meerdere paden is niet van toepassing. Packetloss (en de noodzaak tot hertransmissie en daar door dus ook even een onderbreking in je sequentiele read) is ook niet plausibel, getuige het feit dat de 10Gbps prima gehaald kán worden met de juiste windowsize.
Een grote windowsize die niet terugschaalt, heeft flinke impact op de gehaalde snelheid omdat de packets in de gehele window overnieuw gestuurd moeten worden. Dus dan had ik dat effect moeten zien.
Daarbij is packetloss niet uniform, dus dan zou ik ook ontzettende dips en peaks moeten zien, en ook dat is niet het geval.

Kortom: op een LAN met voldoende snelle en stabiele apparatuur is een download van een NAS theoretisch niet sequentieel, maar in de praktijk wel voor 99%. Dan zal er allicht nog wat overhead bij zijn, maar reken dat 80-90% van de array snelheid over LAN echt wel normaal is.

[ Voor 3% gewijzigd door McKaamos op 29-08-2019 10:25 ]

[Brahiewahiewa]

https://www.smallnetbuild...ewbie-part-4-smb3?start=1

[McKaamos]

Brahiewahiewa schreef op donderdag 29 augustus 2019 @ 13:28:
https://www.smallnetbuild...ewbie-part-4-smb3?start=1

Yep, al gedaan. Komt rechtstreeks uit de handleiding van Intel's netwerkkaarten
Afgezien van het SMB3 stukje, maar dat is sowieso buiten scope momenteel.

[Brahiewahiewa]

McKaamos schreef op donderdag 29 augustus 2019 @ 14:24:
[...]

Yep, al gedaan. Komt rechtstreeks uit de handleiding van Intel's netwerkkaarten
Afgezien van het SMB3 stukje, maar dat is sowieso buiten scope momenteel.

En als je linux op je desktop draait, haalt-ie dan wel 10Gb/s?

[McKaamos]

Brahiewahiewa schreef op donderdag 29 augustus 2019 @ 14:27:
[...]

En als je linux op je desktop draait, haalt-ie dan wel 10GB/s?

Da's inderdaad nog een leuke om te testen, die had ik al op het todo lijstje gezet.

[Hipska]

Mogelijks een domme opmerking, maar waarom ben je er zeker van dat Windows niet wil opschalen? Heb je iperf server en client eens gewisseld?

[McKaamos]

Hipska schreef op donderdag 29 augustus 2019 @ 14:50:
Mogelijks een domme opmerking, maar waarom ben je er zeker van dat Windows niet wil opschalen? Heb je iperf server en client eens gewisseld?

Dat heb ik inderdaad nog niet gedaan, zal ik gaan doen.
En idd, ik kan er niet 100% zeker van zijn. Er zijn echter wel meer meldingen van een dergelijk scenario, waarbij het probleem niet optreed als Windows wordt vervangen door Linux. Dus ik heb wat dat betreft misschien iets te veel een aanname gedaan.

Eitherway, dat gaat ook getest worden.

[Raven]

ehtweak schreef op woensdag 28 augustus 2019 @ 21:26:
Aangezien ik zelf ook nog al aan het stoeien ben geweest met Static Link Aggregation en ANS i.c.m. Intel NICs en Windows 10.
Win10 + Intel NIC --> geen VLAN/Teaming/ANS*

offtopic:
Daarover gesproken, dat gaat tegenwoordig via PowerShell, geen GUI voor dergelijke instellingen meer Kwam ik laatst achter toen ik onder W10 met VLAN aan de gang ging. Zie https://manpage.ru/node/26 voor alle commando's, onlangs heb ik https://www.ramblingman.i...pport-broken-post-update/ gebruikt om VLAN aan de gang te krijgen.

[McKaamos]

Update tijd!
iPerf test in de omgekeerde richting (desktop met 'iperf3 -s'): 9+ Gbps
Linux Mint 19.2 op Live DVD: 9+ Gbps in beide richtingen

In Windows wat lopen tweaken:
Receive Side Scaling (RSS, verdelen over alle CPU cores) uit gezet: 5Gbps
RSS aan, Interupt Moderation Low of Off: 5Gbps
RSS en IM beide uit: 7,5Gbps

Ik vind t mooi zo, da's sneller dan de write-speed van de array.

Volgende stap: SMB/CIFS speed-tunen

[alt-92]

McKaamos schreef op dinsdag 3 september 2019 @ 22:21:
Volgende stap: SMB/CIFS speed-tunen

SMB3 is je vriendje.
Nog mooier is SMBDirect, maar dan moet die 10G kaart wel RDMA leveren...en standaard W10 pro is nee.

[McKaamos]

alt-92 schreef op zaterdag 7 september 2019 @ 21:32:
[...]

SMB3 is je vriendje.
Nog mooier is SMBDirect, maar dan moet die 10G kaart wel RDMA leveren...en standaard W10 pro is nee.

Sowieso, maar dat zit standaard in Windows 10 (SMB3 that is) en op alle enigzinds recente Linux distro's heb je een versie van Samba die dat ook kan en by-default ingeschakeld heeft staan.

Eitherway, gisteren weer even aan het testen geweest.
Ik had in een eerder stadium al wat settings extra mee gegeven aan samba. Op t OMV forum stond een guide met effectief de melding "plak deze settings in de conf en dan gaat samba sneller'.
Als je 10GbE LAN draait, is dat dus *niet* het geval.
De meest notoire van die settings is het gebruik van de 'socket options = ...' parameter. Die wil je bij 10GbE niet handmatig instellen, gezien die settings niet hoog genoeg gaan om goed gebruik te maken van 10GbE en de TCP settings van je NAS puur voor het SMB protocol overriden.
Weghalen van die hele regel geeft bij 10GbE (mits snel genoege array) al gauw een speedboost van meer dan 50% voor SMB.

Met "socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536" zoals aangegeven haalde ik 250MB/s read, zonder 650MB/s read. Toegegeven, de test liep niet lang genoeg voor écht goede meting (grootste beschikbare bestand was 1,5GB, had even een Linux iso ergens vandaan moeten plukken oid) en de snelheid zat nog in de ramp-up, maar het is een redelijke indicatie.

Dus, ook SMB snelheid is aardig goed getackled


Edit, samenvatting voor de geinteresseerden:
Als je Intel X5xx 10GbE NIC's gebruikt zet je onder Windows 10 je Receive Side Scaling uit, Interupt Moderation op Low of Off, Jumbo MTU op 9014, Receive en Transmit Buffers opschroeven naar whatever maximaal is (ik geloof 4096 en 16384 resp.)
Eventueel zet je de AutoTuningLevel naar Experimental.
in een CMD prompt met admin rechten: netsh interface tcp set global autotuninglevel=experimental

Op je Linux based NAS:
MTU naar 9000. (equivalent aan 9014 onder Windows, berekeningsverschil met/zonder headers)
Dump het volgende in een startup script of sysctl.conf:
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"
sysctl -w net.ipv4.tcp_window_scaling=1

in de Samba conf file zet je géén socket options parameters. Eventueel kan je wat tuning toepassen door filesystem access gebaseerde parameters te tweaken. (zie ook: https://forum.openmediava...g-Samba-for-more-speed-2/)
B.v. de volgende set:
read raw = yes 1
write raw = yes
max xmit = 65535
dead time = 15
getwd cache = yes

Et Voila: vrij acceptabele snelheid in Windows shares over 10GbE.

[ Voor 29% gewijzigd door McKaamos op 11-09-2019 12:46 ]