[XP&SMB] Studie: Lage filesharing performance

[Verwijderd]

Dag tweakers,

Ik constateer het volgende probleem:

• 1. Als ik een file (omvang: 1.5Gbyte) copy/paste binnen dezelfde netwerkschijf, dan kopieer ik effectief 12Mbyte/s full duplex (12Mbyte/s lezen en gelijktijdig 12Mbyte/s schrijven, beiden op het netwerk). Als ik kleine bestanden in bulk kopieer zakt de performance onder de 1Mbyte/s.

Dat snap ik niet (en wil ik oplossen) want:

• 2. Als ik op de server aanlog en daar de file copy/paste dan haal ik effectief 40Mbyte/s 'full duplex' (40Mbyte/s lezen en 40Mbyte/s schrijven, beiden van de locale schijf)
• 3. Als ik diezelfde file via http beschikbaar stel en naar de harde schijf van de client download, dan haal ik 35Mbyte/s over het netwerk. Dat is toch 3,5x zo snel als het genoemde onder punt 1.
• 4. Als ik diezelfde file copy vanaf de netwerkschijf en paste naar de lokale harde schijf van de client, dan haal ik effectief 30Mbytes/s over het netwerk. Iets langzamer, maar toch nog steeds 3x zo snel als het genoemde onder punt 1. Hier bestaat overigens een serieus risico dat de harde schijf van de client de bron van het performance plafond is.
• 5. Als ik iPerf draai op server en client en deze in dual mode draai dan haalt iPerf in beide richtingen simultaan 35Mbyte/s sustained. iPerf registreert een beschikbare bandbreedte van 250-270 Mbit/s.
• 6. Als ik NetCPS draai vanaf de client naar de server, dan haalt NetCPS pieken tot 40 Mbyte/s, al wisselt hij erg in doorvoer/s. iPerf geeft een constanter beeld aan.

Mijn configuratie is als volgt:

• 7. De server heeft een Supermicro PDSME moederbord, 3.2Ghz Intel CPU, 1Gb geheugen, Areca 1120 raid controller en 4 x SATA Seagate Barracuda 7200.8 250Gb in RAID 5. Wanneer ik aanlog op de server behaal ik een effectieve throughput van 40Mbyte/s 'full duplex' (40 lezen, 40 schrijven), Windows 2003 Server Enterprise Edition. De netwerkkaart is een gigabit Intel(R) PRO/1000 PM op de PCI-e (x1) bus. Geen firewall, antivirus, etc. Het is een schone installatie.
• 8. De client is, wat magerder, een Medion PC voorzien van 512Mb, 2.8Ghz Intel CPU, SIS chipset. Seagate Barracuda 7200.7 120Gb, Windows 2003 Server Enterprise Edition. De netwerkkaart is een gigabit Intel(R) PRO/1000 GT in een 32bits PCI slot. Geen firewall, antivirus, etc. Het is een schone installatie.
• 9. De machines zijn gekoppeld door middel van een cross-cable en zitten beiden in een workgroup. De gebruikte crosscable is zojuist nieuw gekocht, type Cat5e, gewired conform de gigabit specificaties (zie ook de FAQ van tweakers), heeft geen beschadigingen en is 15m lang. Optioneel gebruik ik een CAT5e straight kabel van 1 meter. In beide gevallen auto-negotiaten de kaarten zichzelf succesvol op 1Gbit full duplex (bij gebruik van de straight kabel kruist een van de kaarten zichzelf). Op dit moment hebben de machines verder geen netwerkverbindingen. De machines hebben elk een fixed IP adres, zonder default gateway of DNS. Alle verbindingen worden gemaakt binnen het subnet op basis van IP adres en niet op basis van naam.

Wat ik al geprobeerd heb is:

• 10. Controleren wat cpu belastingen e.d. doen. Aan de serverzijde is de cpu voor 10% bezig, aan de client zijde voor 35%. Gelijksoortig kan ik nergens bottlenecks vinden. Wat ik wel gezien heb is dat de client +/- 250 Memory/Page Reads/s heeft en 0 Memory/Page Writes/s heeft bij de aktie uit punt 1. Ze treden niet op bij de akties uit punt 3, 4 en 5.
• 11. TcpWindowSize aanpassen op de interfaces aan beide zijden. Dit had wel impact op iPerf (indien meegegeven op de command prompt). Met een window van 2Mbyte haalde ik de performance zoals onder punt 5 genoemd. Verdere ophoging had geen effect. Maar, welke waarde ik ook in de registry invoerde (en daarna reboote), het had geen enkele invloed op de performance van Windows. Het was net alsof de waarde niet gelezen werd.
• 12. Naast punt 11 ook de Tcp1323Opts voor de zekerheid gecontroleerd op stand 0 en stand 3. Ook dit had geen enkel effect.
• 13. dagen lang veel googlen en forums lezen. Alles wat ik ben tegengekomen wijst op betere a) netwerkkabels en b) tcpwindows. Maar, file sharing gebruikt nu minder bandbreedte dan mijn huidige kabel biedt dus a) valt in mijn ogen af en b) heeft nog helemaal geef effect. Daarnaast richten de meeste kwesties zich op performance als totaal en niet op verschillen in performance, zoals ik die nu tegen kom.
• 14. In enkele posts heb ik ook gelezen dat 100Mbit full duplex in de praktijk soms langzamer is dan 100Mbit half duplex. De reden is niet gegeven, maar wel de moeite waard. Helaas ondersteunen de gigabit kaarten geen half duplex, dus heb ik dit niet geprobeerd. (als je een tip hebt hoe het toch kan?) Ik heb wel, zonder resultaat, de kaarten op 1000Mbit geforceerd en de master/slave rol geforceerd over de kaarten.
• 15. De server als DC geconfigureerd, de client als member server om zo eventuele credential problemen te addresseren. Dit had geen effect.
• 16. Netbeui geinstalleerd en op basis daarvan de file transfers gedaan. De onder 1 genoemde operatie gaat dan met +/- 16Mbyte/s. Iets sneller dus, maar niet wezenlijk.

Wat ik wel snap is:

• 17. De bandbreedte limiet ligt momenteel nog op 35Mbyte/s. Mijn netwerkkaarten geven in diagnosics 75% kwaliteit van de verbinding aan. Een betere (bijvoorbeeld geshielde of beter geknepen) kabel kan deze limiet omhoog schroeven, hoewel deze altijd beperkt zal blijven tot de maximale doovoersnelheid aan de server zijde minus de vereiste overheads en daarna, als ik snellere schijven aan de controller zou hangen, door de gigabit beperking die op 125 Mbyte/s ligt en de 32Bit PCI bus aan de client zijde. Maar, als het tijd is om te upgraden is die ook vanzelf weer een keer aan de beurt.

Wat ik te weten hoop te komen is:

• 17. Waarom is de throughput met file sharing zoveel lager dan met andere protocollen? Verschil moet er zijn, maar een factor 3 - 3,5 kan ik niet verklaren.
• 19. Kan ik op een makkelijke manier controleren wat de tcpwindowsize is die van toepassing is op de smb tcp verbinding tussen client/server? Kan het zijn dat Windows, ondanks waarden in de registry, op deze specifieke sessie toch een lagere windowsize heeft?
• 20. Kan het zijn dat de 250 Page Reads/s gerelateerd zijn aan het performance verlies en, als het OS Page Reads gebruikt om bij reguliere disk reads de pages in het geheugen te laden (zie punt 9) waarom genereert het dan niet evenzoveel Page Writes?
• 21. Zijn er, breed gedacht, manieren om dit op te lossen? Gebruikt de file sharing client soms een aanpasbare cache? Zijn er naast tcp tuning opties soms ook tuning opties voor file sharing? Zou het helpen als ik als linux/samba als server gebruik?

Dank voor het meedenken.

[ Voor 5% gewijzigd door Verwijderd op 16-10-2005 00:30 ]

[alt-92]

SMB signing, kijk goed naar client <> server instelling.
Met name request <> require verschil, als je server SMB signing request en je client zegt "dat kan ik" dan gaat SMB signing inderdaad tegenwerken.

2) kabel.
Ik was in de veronderstelling dat je geen crosslink kabel nodig had omdat Gbit nics volledig autosensing + auto-mdix zijn?
Bovendien is fixed speed opgeven niet prettig met Gbit, beter niet doen.

[ Voor 24% gewijzigd door alt-92 op 16-10-2005 14:22 ]

[Verwijderd]

BackSlash32 schreef op zondag 16 oktober 2005 @ 14:20:
SMB signing, kijk goed naar client <> server instelling.

Hey, thanks. Dat klinkt interessant. Het onderwerp is me nog onbekend en ik zal me de komende dagen suf-googlen om erover te weten te komen wat ik moet. Kan je me een hint geven, zoals een verwijzing naar een website waarop hierover meer te lezen is, of de benaming van enkele registry keys? Googlen op de exacte naam van registry keys geeft vaak al heel snel hits namelijk.

BackSlash32 schreef op zondag 16 oktober 2005 @ 14:20:
Ik was in de veronderstelling dat je geen crosslink kabel nodig had omdat Gbit nics volledig autosensing + auto-mdix zijn?

Ik weet niet of dit per specificatie zo is, maar mijn kaarten doen het inderdaad. Ik gebruik dan weliswaar een crosscable, maar optioneel gebruik ik een straight (niet-crossed) cat 5e kabel en die functioneert ook omdat de kaarten inderdaad automatisch mdix 'doen'.

Heeft iemand nog andere suggesties waar het performance verlies aan zou kunnen liggen, c.q. hoe ik het kan verbeteren?

[ Voor 7% gewijzigd door Verwijderd op 16-10-2005 14:38 ]

[alt-92]

Verwijderd schreef op zondag 16 oktober 2005 @ 14:37:
Hey, thanks. Dat klinkt interessant. Het onderwerp is me nog onbekend en ik zal me de komende dagen suf-googlen om erover te weten te komen wat ik moet. Kan je me een hint geven?

Group Policies.
Als je een AD gebruikt zou ik GPMC aanraden, bij workgroup modus gewoon gpedit.msc runnen.

Ik weet niet of dit per specificatie zo is, maar mijn kaarten doen het inderdaad.

Dat is inderdaad per de specificatie.
Gbit gebruikt alle 8 de aders, de gemiddelde cat5e kabel in de winkel ook.
Een standaard crosscable (die meestal zwart met rooie stekkertje in de winkels liggen) doet dat niet.

[Verwijderd]

Backslash32: als je een vrouw was zou ik je zoenen. Ik heb er zojuist 6Mbyte/s bijgekregen. Ik haal nu, werkelijk, inclusief pieken en dalen 18Mbyte/s. Als ik vele kleine files kopieer (bijvoorbeeld 1420 commodore 64 sid tunes t.w.v. 8,7Mbyte) duurde dat voorheen 153 minuten volgens de voorspelling. Nu ben ik binnen een minuut klaar. Als ik nu naar de doorvoer kijk heb ik het gevoel echt een gigabit verbinding te gebruiken.

Nog even op een rijtje dus:
De vertraging kan onder andere veroorzaakt worden door SMB signing. File sharing onder windows gebeurt op basis van het SMB protocol en met behulp van SMB signing wordt in de communicatie tussen server en client de identiteit van beiden gewaarborgd. Volgens microsoft zorgt SMB signing niet voor een verhoging van de gebruikte bandbreedte, maar wel voor een verhoging van de CPU load. Bij een hogere CPU load is daardoor de uitnutting van de beschikbare bandbreedte lager.

Als je lokaal, thuis bijvoorbeeld, een veilig netwerk hebt kan je ervoor kiezen SMB signing uit te zetten. Onder win2003 doe je dit door middel van de Group Policy Object Editor.

(even klikken)
Je start de policy editor via start, run, gpedit.msc. Expand dan 'security options' zoals hierboven aangegeven. Je treft er vier policies aan die relevant zijn:

• Microsoft network client: Digitally sign communications (always)
• Microsoft network client: Digitally sign communications (if server agrees)
• Microsoft network server: Digitally sign communications (always)
• Microsoft network server: Digitally sign communications (if client agrees)

Voor de server gelden de onderste twee policies. Voor de client de bovenste. Indien je ze aan beide zijden op disabled zet zal de verbinding een stuk sneller gaan. In geval van een domain controller kan het zijn dat de policies zijn overruled vanuit de active directory. Je kunt ze dan niet met de policy editor bewerken. Gebruik dan, vanuit de administrative tools, de domain controller security policy.

Meer suggesties?
Als iemand in de tussentijd verder nog suggesties heeft, dan hoor ik ze graag (ik zit nog steeds en nog lang niet op 40Mbyte/s ) We zijn er nog niet, er is nog meer uit te halen volgens mij, maar dat lijkt me next steps.

Hoe nu verder?
Wat ik nu zie is dat de performance gemiddeld op 18Mbyte/s ligt, maar sterk fluctueert tussen 24 en 10. Het is net een stop-and-wait protocol geworden met bursts van 2 metingen in performance monitor op 24 en dan een pause van 1 meting op 10 Mbyte. Wat ik daarom nu ga doen is kijken of de eerder geprobeerde methoden nu wel effect hebben. Het lijkt me dat dit typisch iets is dat verbeterd kan worden met een betere tcpwindowsizing?

Wat mij betreft, gezien de vele postings die ik heb gezien en de gelijksoortige vragen (hoe snel gaat mijn gigabit, hoe wordt mijn browsing sneller, etc.) maken we hier een 'het grote snelle file server topic' van waar ik dan wel een paar centen in wil bijdragen.

Dit is een issue waar veel mensen tegen aan lopen, dus ik denk dat het goed is om het topic te gebruiken om alles wat kan bijdragen tot een betere performance goed op een rijtje te zetten. Handig, voor wie later een keer de search gebruikt

Reacties?

[Zwelgje]

als je toch cross gebruikt en dus geen switch dan kan je ook jumbo frames aanzetten op die nics, normaliter werkt dit alleen als je switch het ook ondersteund, maar aangezien je crosscable hebt zou je dat aan kunnen zetten. kan behoorlijk schelen

* Zwelgje moet toegeven dat hij nog nooit jumboframes op een crossverbinding heeft gebruikt, dus dit is onder voorbehoud

[Verwijderd]

Het volgende zou je eens kunnen proberen, ik heb het nog nooit getest en ben dus erg benieuwd naar je bevindingen. Dit heeft ook niet direct betrekking op SMB, maar algemene netwerk performance.

1.Log in als administrator
2. start - run - gpedit.msc
3. local computer policy of in de NL versie: Computerconfiguratie
4. administrative templates of in NL: Beheersjablonen
5. network branch of NL: Netwerk
6. Klik op QoS Packet Scheduler: QOS pakketplanner
7. in het rechter venster staat nu "limit reservable bandwidth": De reserveerbare bandbreedte beperken, deze optie moet (indien nodig) gewijzigd worden
8. Deze functie moet je inschakelen
9. En de "Bandwidth limit %" ofwel "bandbreedte limiet (%)" zet je op 0
Standaard waarde hiervoor is 20% als de functie niet is ingeschakeld. Door dit op 0 te zetten gaat de reservering eraf en zou je dus meer bandbreedte over moeten houden.

Het volgende vond ik nog op internet, wellicht ook interessant:
may or may not work, depends on your configuration. add the Dword values shown below increases the number of buffers that the redirector reserves for network performance it may increase your network throughput. the range is 0-255. It is set at 100 here. make MaxCmds & MaxThreads have same value. The default is 15

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"MaxCmds"=dword:00000064
"MaxThreads"=dword:00000064

[alt-92]

Verwijderd schreef op dinsdag 25 oktober 2005 @ 21:16:
Het volgende zou je eens kunnen proberen
<snip QoS geneuzel>

Heeft alleen nut als je ook QoS-aware hardware gebruikt. Nics, Switches en routers..

Anders wordt het namelijk niet ondersteund en ook niet gebruikt