Gathering of Tweakers

specs
Intel Q6600 @ 3,33 G
Asus P5K-e wifi (ICH9R)
4x 1G Team group @ 1120 5-5-5-15
4x 500G Samsung T-166
Vista 64 business

Ik heb 2 raid configuraties
raid 0


en raid 5


raid0

raid5


Raid 0 ziet er wel goed uit, maar bij raid 5 is de write snelheid toch wel laag (in ATTO).
Een collega van me heeft nl exact dezelfde setup/OS en haalt daar write snelheden rond de 200.000

Wat kan er anders zijn dat het bij mij zoveel trager is ?
Ik heb write enabled cache in de raid control manager aangezet, de write cache van de disken in de device manager kan ik niet aanzetten, die vinkjes worden iedere keer weer uitgezet (schijnt niet te kunnen met raid?) en ik heb diverse services disabled.

ICH9R write snelheden rond de 200MB/s? Wellicht burst maar niet sustained. Je moet weten dat je bij ICH9R niet alleen je hardeschijven test maar ook je geheugen (mits write-back is ingeschakeld). Het is dan erg makkelijk om onrealistische resultaten te krijgen. ICH9R is niet makkelijk te benchmarken.

65MB/s write lijkt mij wel oke. Wellicht dat een benchmark met cooldown periode na elke write benchmark nog een beter resultaat oplevert. Ik ben overigens wel benieuwd welke scores geom_raid5 haalt onder FreeBSD met jouw hardware. Maar je hebt er zeker al data op staan enzo?

Specs

AMD Sempron 64 3000+
MSI R482 IL
3x Samsung T166 250 GB 8 MB SATA
1x Samsung T133 400 GB 16 MB SATA
Highpoint RocketRAID 2310 PCIe 4x

Ik heb een RAID 10 configuratie van 499 GB en de resterende 149 GB heb ik als JBOD geconfigureerd.

RAID 10:


Ik ben tevreden over de resultaten

Het is niet helemaal eerlijk omdat dit een server bak is maargoed.

Specs :

Intel Core 2 Quad Q6600 2,4 Ghz
4 Gb DDR-2
Foxconn G33M-S bordje,
Areca 1220 raid controler.

Onboard RAID controler (RAID 1, 2x 160 GB)

ATTO


HDTach



Areca RAID controler (RAID 5, 8x 500 GB)

ATTO


HDtach



En owja, de areca raid was toen ik de bench uitvoerde aan het rebuilden.

Je hoort mij niet klagen.

Sinds gisteren heb ik 4 Western Digital Caviar RE WD1600YS in raid 0:

Niet verkeerd dacht ik zo.

sig69 wijzigde dit bericht 26-11-2007 09:23 (23%)

Geen slechte scores maar aan het grote verschil tussen de 128 t/m 8192KB scores te zien lijkt de RAID-driver niet erg efficient. Welke controller gebruik je?

Enlightenment wijzigde dit bericht 26-11-2007 21:13 (5%)

Het hangt aan Intel een ICH9R chipset op een Gigabyte P35. Zo groot is het verschil tiisen 128 en 8192KB toch niet?

199MB/s versus 259MB/s vind ik een groot verschil. Dat zou eigenlijk niet mogen. Maargoed ATTO is niet de beste tool om RAID implementaties mee te testen.

Een perfecte RAID driver/implementatie heb ik nog nooit gezien. Maar zelfs bij onboard RAID zou de sequentiele overdracht de max theoretische snelheid dicht moeten benaderen, zeker bij simpele levels als RAID0 en RAID1.

Zou je de 'write-back' optie tijdelijk eens aan kunnen zetten en dan opnieuw testen? Mogelijk komt de hogere score echter door caching en is het dus geen geldige score. Om goed te testen moet je meer dan 8 keer je RAM geheugen schrijven wil je een betrouwbare score hebben. Intel ICH9R gebruikt namelijk je geheugen als buffercache, voor extra snelheid.

Met de write-back optie uit komt dit er uit:

Edit: ik sliep al half, verkeerde schijf gebenched...

Edit2: dit zijn de resultaten met write-back uit dus:

sig69 wijzigde dit bericht 27-11-2007 08:45 (91%)

CPU: AMD X2 3800
Moederbord: ASUS M2NPV-MX
Geheugen: Twinmos 1GB cas 5 DDR2-6400
Softwarematige RAID0 over 5 schijven met LVM:
2x Seagate 120GB IDE (lezen: 55 MB/s ,hdparm -t)
2x Seagate 120GB SATA-I (lezen: 55 MB/s ,hdparm -t)
1x Samsung T166 320 GB SATA-II (lezen: 87 MB/s ,hdparm -t)
Chunksize: 256K
Readahead: 8192 (LVM). 5120 (RAID)
Bestandsysteem: ext3 (noatime)
Besturingsysteem: Linux 2.6.22 32-bit

Benchmarkprogramma: Bonnie++ 1.03 (dit is de single-cpu versie, dus alleen één core wordt gebruikt).

Leessnelheid: 233 MB/s
Schrijfsnelheid: 237MB/s

sudo /usr/sbin/bonnie++ -n 1024 -r 1024 -s 4096 -x 1 -u root -q | bon_csv2txt

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
thuis 4G 43813 98 237188 91 100201 37 46860 97 232695 43 346.1 2
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
thuis 1024 23681 68 22717 23 2427 12 24000 69 22648 27 1422 8

Benchmarkprogramma: hdparm -t

Leessnelheid gemiddeld: 240MB/s

Benchmarkprogramma: dd

sudo sync;time sudo bash -c "(dd if=/dev/zero of=bf bs=8k count=500000; sync)"
500000+0 records in
500000+0 records uit
4096000000 bytes (4,1 GB) gekopieerd, 17,3145 seconden, 237 MB/s

real 0m18.180s
user 0m0.124s
sys 0m14.033s

Schrijven: 237 MB/s

_toet_ wijzigde dit bericht 01-12-2007 11:20 (11%)

Ik heb altijd met HD-tach gebenchmarked en die geeft op mijn raid6 array (9-disk) netjes een avarage read van 420MB/s.

Nu heb ik ook een keer ATTO gerunt omdat dat hier veelgebruikt is en ik het al lang niet meer gebruikt had, de schrijfsnelheden die daarmee gehaald worden zijn rond de 700MB/s maar volgens ATTO haalt de array maar rond de 40MB/s read.

Nu de vraag; kan ATTO wel met raid6 omgaan? De 40MB/s die uit de benchmark komen kloppen, heel duidelijk, niet. Gewoon met bestanden verplaatsen vanaf die array naar een raid0 gaat met 200MB/s gem. wat de max is van die raid0-array.

Misschien wel handig erbij te zeggen dat ik lang geleden toen de array nog 4-disk raid5 was de read/write wel met elkaar overeen kwamen. Naderhand zijn stripe/blocksize niet meer aangepast en er enkel disks bij gekomen en een keer raid-level 'verhoogd' naar raid6.

Meer mensen die dit probleem hebben? Controller in kwestie is een areca 1280 met 2GB cache.

Een betere vraag zou zijn, kan een superoud programma als ATTO (de 32MB versie denk ik dat je hebt) wel met RAID omgaan. Het antwoord is nee, iig niet in betrouwbare zin.

Probleem is dat je een intelligente controller hebt, waarschijnlijk met write-back ingeschakeld. Het feit dat je RAID6 gebruikt maar niets uit, hetzelfde probleem zul je hebben met RAID0 en zelfs een JBOD.

Als je jouw controller wilt benchmarken met testgroottes van minimaal 8 * RAM moeten werken. Stel jouw systeem heeft 4GB en je Areca 2GB, dan is de minimale testgrootte dus 48GB voor een betrouwbaar resultaat. Wat je nu gebruikt is 32MB, en dat floept zo de write-buffer in. In feite test je dan de geheugen en verwerkingssnelheid van je Areca kaart, niet van je hardeschijven. Met dezelfde technologie kun je een ouderwetse floppydrive een write speed van 700MB/s geven.

Je Areca is ongetwijfeld snel, maar je kunt geen simpele programma's zoals ATTO, HDTune, HDTach gebruiken om dit te testen. Deze programma's zijn allemaal niet geschikt voor RAID arrays, en vooral niet voor Areca's met 2GB aan dedicated buffercache.

Gebruikte wel de 256MB versie van ATTO. Heb inderdaad 4GB ram en zou dus minimaal 48GB als testgrootte moeten hanteren. De verklaring waarom ATTO zulke write-speeds haalt is na jou uitleg inderdaad logisch.

Toch blijf ik het 'vreemd' vinden want een 3-raptor raid0 op precies diezelfde controller laat wel gelijke write/read speeds zien (ook idd van 700MB/s, beide dat had al een lampje moeten gaan laten branden). Ook verklaard het de ATTO-resultaten in de benchmark-database van 900MB/s aangezien die test niks met de HDD's te maken heeft maar alleen met de cache.

Een programma zoals HDTach laat wel duidelijk verschil zien tussen de array's en geeft ook realistischere resultaten en ik zal die dan maar 'standaard' gebruiken en de resultaten met een korreltje zout nemen (al lijken mij die resultaten wel te kloppen).

Leuk is dan wel te weten dat deze areca (met een IOP341) een 'plafond' heeft op ongeveer 750MB/s waar oudere modellen (1220/1230) met een IOP333 op 500MB/s een max hadden.

quote:

dvl-2 schreef op dinsdag 04 december 2007 @ 14:59:
Toch blijf ik het 'vreemd' vinden want een 3-raptor raid0 op precies diezelfde controller laat wel gelijke write/read speeds zien

Hoezo vreemd? Volgens mijn verhaaltje klopt dat dus inderdaad; je zou zelfs hetzelfde resultaat moeten krijgen met een oude schijf in een RAID0-array bestaande uit 1 disk. Het gaat hier in feite niet om de disks maar om je Areca controller, die met truucjes ATTO en andere software te slim af is.

quote:

Een programma zoals HDTach laat wel duidelijk verschil zien tussen de array's en geeft ook realistischere resultaten en ik zal die dan maar 'standaard' gebruiken en de resultaten met een korreltje zout nemen (al lijken mij die resultaten wel te kloppen).

Ja kan, als er gewoon sequentiëel gelezen wordt over de hele disk dan wordt de invloed van caching beperkt. Bovendien heb je dan geen last van een write-back buffer - dat is alleen van toepassing als je schrijfopdrachten hebt. Bij writes kan areca direct na het ontvangen zeggen 'deze is weggeschreven!' en dan gaat het filesystem door met de volgende opdracht. Maar met lezen gaat dit grapje niet op; Areca zal de schijven moeten gebruiken tenzij (een deel van) de data in Areca's onboard dedicated buffercache zit. Draai maar eens een aantal HDTune's achter elkaar - dan zie je dat sommige seeks (access time puntjes) helemaal onderaan zitten - die zijn cached en komen niet van de fysieke hardeschijven.

quote:

Leuk is dan wel te weten dat deze areca (met een IOP341) een 'plafond' heeft op ongeveer 750MB/s waar oudere modellen (1220/1230) met een IOP333 op 500MB/s een max hadden.

Klopt! Ik heb dus zo'n ARC-1220 met IOP333 en haal daarbij 880MB/s read en 430MB/s write max burst speed. Hoger zul je dus nooit kunnen met deze controller. Ik moet er wel bij zeggen dat je zelden meer dan 200MB/s aan doorvoersnelheid nodig hebt - hardeschijven zijn bottleneck omdat ze maar heel langzaam een random I/O stroom kunnen verwerken. En realistisch gebruik (servers/desktop) lijkt vaak sterk op random I/O. Dan kan de verwerkingssnelheid - zelfs op een Areca - terugvallen tot 2MB/s of nog lager. Sequentiële I/O is een best-case scenario, oftewel de maximum performance. Het is opzich jammer dat deze zoveel aandacht krijgt; sequentiële I/O is namelijk niet verantwoordelijk voor de traagheid van storage.

quote:

Enlightenment schreef op dinsdag 04 december 2007 @ 18:08:

Hoezo vreemd? Volgens mijn verhaaltje klopt dat dus inderdaad; je zou zelfs hetzelfde resultaat moeten krijgen met een oude schijf in een RAID0-array bestaande uit 1 disk. Het gaat hier in feite niet om de disks maar om je Areca controller, die met truucjes ATTO en andere software te slim af is.

Je begrijpt me verkeerd:

raid0 array in ATTO resulteerd in 750MB/s read en 750MB/s write
raid6 array in ATTO resutleerd in 40MB/s read en 750MB/s write

Die 40MB/s valt dus uit te toon mbt de andere resultaten en is ook met jou verhaal door mij niet te verklaren

quote:

Enlightenment schreef op dinsdag 04 december 2007 @ 18:08:

Klopt! Ik heb dus zo'n ARC-1220 met IOP333 en haal daarbij 880MB/s read en 430MB/s write max burst speed. Hoger zul je dus nooit kunnen met deze controller. Ik moet er wel bij zeggen dat je zelden meer dan 200MB/s aan doorvoersnelheid nodig hebt - hardeschijven zijn bottleneck omdat ze maar heel langzaam een random I/O stroom kunnen verwerken. En realistisch gebruik (servers/desktop) lijkt vaak sterk op random I/O. Dan kan de verwerkingssnelheid - zelfs op een Areca - terugvallen tot 2MB/s of nog lager. Sequentiële I/O is een best-case scenario, oftewel de maximum performance. Het is opzich jammer dat deze zoveel aandacht krijgt; sequentiële I/O is namelijk niet verantwoordelijk voor de traagheid van storage.

Klopt inderdaad, die MB/s uit die reviews is niet meer dan beetje een 'patsfactor', je gebruikt toch nooit meer dan 200MB/s dus alles erboven is grappig maar gebruik je toch niet. Zoals je zegt is de I/O-performance een stuk belangrijker.

quote:

Enlightenment schreef op dinsdag 04 december 2007 @ 18:08:
[...]
hardeschijven zijn bottleneck omdat ze maar heel langzaam een random I/O stroom kunnen verwerken. En realistisch gebruik (servers/desktop) lijkt vaak sterk op random I/O. Dan kan de verwerkingssnelheid - zelfs op een Areca - terugvallen tot 2MB/s of nog lager. Sequentiële I/O is een best-case scenario, oftewel de maximum performance. Het is opzich jammer dat deze zoveel aandacht krijgt; sequentiële I/O is namelijk niet verantwoordelijk voor de traagheid van storage.

De hamvraag is dus; wat is het beste wat je kan doen om de random I/O op te voeren ?

ps: Zie scores van 100MB +, met 1 harddisk. Zijn mijn twee WD 4000YS RE dan zo langzaam of lijkt dat maar zo ?
Vanaf 64kb scoren ze 93/94.000 read en write (Atto (256??)). Softwareraid XP, RAID-0, hangen aan Asus A8n SLI Premium aan de nVidia NF4 Serial ATA II poorten.

Ter vergelijk de enkele WD 3200jb 320GB scoort dan een 64-65.000.

Het is wel zo dat mijn Wd3200jb in twee partities gehakt is; c:\ 32GB D:\288.
De Raid-0 array is 1 grote van de twee WD 4000YS RE's.

update!

Als ik de test speed knop indruk bij primairy en secundairy channel (apparaatbeheer/nvidia sata controller), krijg ik verschillende sustained speed waardes, dat kan toch eigenlijk niet als ik twee identieke harddisk heb ? Het gat is nogal groot, disk 1 scoort 72.1. disk 2 maar 57.7

Madrox wijzigde dit bericht 06-12-2007 17:32 (35%)

Asus P5N-E SLI
2x Samsung Spinpoint 500GB (7200rpm Sata2 16mb)
RAID 0

Met de volgende resultaten:



Ik heb er geen verstand van dus ik durf ook niet te vertellen of het goed is in verhouding met mijn specs. Ik ben wel blij want mijn systeem is een stuk sneller dan mijn vorige, maar als het beter kan dan hoor ik het natuurlijk graag.

Overigens heb ik mijn besturingssysteem op 2x WD Raptor 74GB (SATA 10K rpm 16mb) in RAID 0. Resultaten hiervan volgen nog, ik krijg deze vooralsnog niet getest (foutmelding: 'Cannot open file benchtst.$$$.')


Zie ook: Raid Setup: Installatie vraag.

Een slechte write op ICH xR RAID 5 kan ik me goed voorstellen.

Heb zelf de ervaring dat op mijn 3 schijven Seagate 7200.10 250 GB (AAD, AAE, AAE) de write ook niet boven de 4 MB/s komt.

Ik kopierde eens een ISO van zo'n 4 GB vanaf m'n laptop via GBit LAN naar m'n desktop, naar een RAID 5 partitie.

2 uur en 20 minuten resterend zegt ie na een twee minuten transferen. Ja, zijn we nu helemaal van de ratten beschimmeld zeg

Uiteraard geannuleerd en toen naar een RAID 0 partitie gekopierd vanaf m'n laptop. Resulteerde in een nette 30 MB/s (het maximale van m'n laptop HDD).

Op LAN parties ook. GBit LAN, RAID <> RAID, en traaag, traaag, traaag.

Ik denk dat het de volgende keer voor mij RAID 10 wordt, dan maar een 50% verlies ipv 25% (bij vier schijven), maar ik ben die langzame write meer dan zat. Een losse RAID controller is nog net iets té prijzig imo.

Beetje RAID 5 controller op PCI-Express (x4 of x8, x1 win ik niks mee kwa transferrate, dan krijg je bus bottleneck op 250 MB/s theoretisch max.)

4 poorts, RAID 5, PCI-Express, eigen XOR Unit, zit je al aan de 280 euro

En om dan nog maar te zwijgen over de 8 poorts. Die goedkopere RAID kaartjes hebben ook nog eens een nep interface, PCI-X en dan chipje ertussen om er PCI-e van te maken, nee bedankt.

Je kan nou eenmaal ook niet voor een dubbeltje op de eerste rang zitten he

160-180MB/s sustained is wel de max met de ICH9R. Dit met 4 drives (met 5 loopt alles in de soep), 64kb stripe size, write back enabled. In ATTO benchen met direct I/O, neither. Als ik tijd heb zal ik zaterdag een bench posten.

TheBorg wijzigde dit bericht 12-12-2007 21:41 (12%)

quote:

dvl-2 schreef op woensdag 12 december 2007 @ 16:49:
Je kan nou eenmaal ook niet voor een dubbeltje op de eerste rang zitten he

Wat is er nou zo bijzonder aan RAID 5? Moet toch veel sneller kunnen. CPU gebruik is ook maar 2% ofzo

quote:

jcvjcvjcvjcv schreef op woensdag 12 december 2007 @ 22:20:
[...]


Wat is er nou zo bijzonder aan RAID 5? Moet toch veel sneller kunnen. CPU gebruik is ook maar 2% ofzo

RAID5 is een complex RAID level.

De meeste implementaties, zoals van onboard chipjes die RAID5 kunnen, zijn erg simplistisch gebouwd. Normaal zou je denken, als je CPU belasting maar 2% is, waar ligt dan de bottleneck? Het antwoord: door een slecht design, is de bottleneck je hardeschijven. Een simpele RAID5 implementatie doet namelijk alle writes in twee fases, zogenaamde 2-phase writes. Hierbij wordt er eerst data ingelezen, daarna de pariteit uitgerekend, en daarna alle relevante data naar disk geschreven inclusief verse parity. Nadeel van deze trage 2-phase writes is dat schijven bij het schrijven continu aan het lezen zijn, en dus hele tijd aan het seeken zijn, van sequentiëel schrijven is dan eigenlijk geen sprake meer.

Moderne implementaties daarintegen, maken gebruik van request combining. Oftewel het samenvoegen van requests. Dit is nodig om zogenaamde 1-phase writes mogelijk te maken, waarbij er niet meer gelezen hoeft te worden van de schijven maar er alleen geschreven wordt. Om dit mogelijk te maken moet de implementatie een write-buffer hebben die alle write requests opslaat, aan elkaar lijmt en zoekt naar 'full stripe blocks'.

Formule: (aantal_schijven - 1) * stripesize = full stripe blocksize.
Voorbeeld: (4 - 1) * 128KB = 384KB

Om het simpel te houden: RAID5 kan alleen snel schrijven als het precies met blokjes van die 384KB schrijft (uiteraard is dit getal anders bij een andere stripesize of hoeveelheid schijven). geom_raid5, een softwarematige RAID5 implementatie onder FreeNAS/FreeBSD, haalt zo'n 470MB/s aan raw write dankzij write-combining. Zonder write-combining is dat zo'n 20MB/s. Dat is dus de reden dat RAID5 speciaal is.

RAID3 heeft hiervan geen last, omdat "by design" alle writes automatisch 1-phase writes worden. RAID4, RAID5 en RAID6 hebben wel last van dit probleem. Interessant detail: Sun's ZFS filesystem lost dit probleem op door een variabele stripesize te gebruiken voor elke file. Zodoende kan altijd de full stripe block gebruikt worden voor optimale performance. Althans, dat is de theorie.

quote:

dvl-2 schreef op woensdag 05 december 2007 @ 09:19:
Je begrijpt me verkeerd:

raid0 array in ATTO resulteerd in 750MB/s read en 750MB/s write
raid6 array in ATTO resutleerd in 40MB/s read en 750MB/s write

Die 40MB/s valt dus uit te toon mbt de andere resultaten en is ook met jou verhaal door mij niet te verklaren

40MB/s read? Dan zit er iets fout met je array. Misschien draait je array single of double degraded? Misschien test je onjuist? ATTO 256MB is opzich wel een goede benchmark om de doorvoersnelheid mee te meten, maar er blijft één probleem bestaan: door gebrek aan een rustperiode tussen de tests is het mogelijk dat de ene benchmark de andere beïnvloed. Dit komt omdat moderne controllers waaronder Intel ICHxR met write-back een buffer hebben, die dus nog geleegd moet worden zodra de volgende benchmark nog moet beginnen.

Wat krijg je dan: 256MB schrijven gaat heel snel, maar daarna komt de read-benchmark. Tijdens dat deze benchmark nog bezig is, is die 256MB nog niet daadwerkelijk weggeschreven naar de disk. Gevolg is dat je read-benchmark lagere scores krijgt. Een mooi woord hiervoor is benchmark contamination. Voor Windows heb ik geen gemakkelijke workaround, behalve met explorer zelf wat copy-tests uit te voeren van/naar een memory disk. Probeer anders eens tests die alleen lezen, dan zou je dit probleem niet mogen hebben.

quote:

Madrox schreef op donderdag 06 december 2007 @ 02:21:
De hamvraag is dus; wat is het beste wat je kan doen om de random I/O op te voeren ?

Door geen mechanische hardeschijven te gebruiken. De lage IOps score hiervan is inherent aan de techniek. Alhoewel schijven sneller worden blijft het probleem bestaan. Pas zodra de volgende generatie SSDs zijn intrede doet kunnen we échte performance verwachten, iets wat al snel 80.000% sneller kan zijn dan met hedendaagse mechanische techniek mogelijk is.

quote:

ps: Zie scores van 100MB +, met 1 harddisk. Zijn mijn twee WD 4000YS RE dan zo langzaam of lijkt dat maar zo ?
Vanaf 64kb scoren ze 93/94.000 read en write (Atto (256??)). Softwareraid XP

Post eens wat concrete benchmarks? Bij RAID0 moet je gewoon de max sustained speed halen, punt. Zo niet dan zit er wat fout. Ik ga er wel vanuit dat je geen PCI gebruikt, want dat beïnvloed je performance aanzienlijk.

Het probleem is al boven water, 1 van de twee heeft maar een "drivefitness" (smart/speedfan) van 85%. Ook WD's quick en full diagnose klappen eruit met fouten. De WD-tool smartstatus rapporteert wel: passed. Vreemd. Iig vertrouw ik die ene disk niet meer en heb al RMA aangevraagt.
De eerste keer trouwens dat ik erachter kom voordat een harddisk de geest geeft, wel kicken

Dit is mijn nieuwe RAID(0) setup

4x Samsung SpinPoint F1 1TB 32MB (op areca 1210)



ps: ben nog niet helemaal uit hoe ik die +2TB in vista 64 voorelkaar krijg