RAID 0 geen significant snelheidsverschil

[Anoniem: 388209]

Hallo Allemaal,

Allereerst zal ik mezelf even voorstellen. Mijn naam is N4vy en ik ben 27 jaar. Na een lange tijd van meelezen wil ik nu actief posten, mede omdat ik zelf een aantal vragen heb m.b.t. mijn RAID 0 setup.

Eerst wat informatie over mijn pc:

AsRock TurboTwins2000
Intel core 2 duo 3,0GHz (3,6GHz geklokt)
Geil 2 x 4GB DDR3 1366MHz
Nvidia EVGA GTX460 768MB DDR5

2 x WD10EARS 1000GB;

-Transferrate: tot 111 MB/s (lezen)
-Snelheid: 7200 rpm
-Toegangstijd: 8,9 ms (lezen)
-Cache: 64 MB

Controler: DawiControl DC-300e RAID, het is geen dure kaart, maar hier moet toch een snelheidswinst mee behaald worden? Kaart werd netjes herkend door de BIOS en dus kon ik een RAID 0 setup configureren.

Als hardware wordt deze kaart door mijn computer herkend als SiImage SCSI disk device?

Met HD Tune Pro heb ik enkele tests gedaan, echter heb ik geen tests van voor de RAID setup en omdat ik geen noemenswaard verschil merk zou ik graag willen weten welke conclusies wij kunnen trekken uit onderstaande grafieken:










Alvast bedankt!

Groeten,
N4vy

[ Voor 12% gewijzigd door Anoniem: 388209 op 21-12-2010 11:40 ]

[beany]

Raid 0 is van meerdere fysieke schijven 1 logische schijf maken. Opzich logisch dat er geen snelheidswinst is.

Overigens doen je plaatjes het niet. En wij groeten hier elkaar permanent, dus het groeten hoef je niet expliciet te melden

[Slurpgeit]

beany schreef op dinsdag 21 december 2010 @ 11:36:
Raid 0 is van meerdere fysieke schijven 1 logische schijf maken. Opzich logisch dat er geen snelheidswinst is.

Overigens doen je plaatjes het niet. En wij groeten hier elkaar permanent, dus het groeten hoef je niet expliciet te melden

Logisch? RAID0 gebruik je juist voor snelheidswinst. Als je simpelweg 1 grote schijf wil maken gebruik je JBOD.

[Nism0]

beany schreef op dinsdag 21 december 2010 @ 11:36:
Raid 0 is van meerdere fysieke schijven 1 logische schijf maken. Opzich logisch dat er geen snelheidswinst is.

Overigens doen je plaatjes het niet. En wij groeten hier elkaar permanent, dus het groeten hoef je niet expliciet te melden

dit is echt klinkklare onzin!

Raid 0 moet zeker snelheidswinst opleveren.

Gebruik je de laatste drivers?

[ Voor 3% gewijzigd door Nism0 op 21-12-2010 12:50 ]

[Ventieldopje]

Als ik goed kijk staat de CPU usage op 31%, lijkt me dat deze kaart aardig leunt op je CPU. Heb zelf een HighPoint RocketRaid 2640x4 met 2 schijven in RAID0 en dan is de CPU belasting maar 3% 1.9%, ook liggen de lees en schrijf snelheden veel dichter bij elkaar bij mij. Vreemd ...

Mijn setup:


Misschien toch even checken of je de juiste drivers hebt en of je wat in kan stellen voor die kaart

[manzonderdas]

heb je al de laatste nieuwe drivers van Silicon image gedownloaded?

Kan je de controller in een ander pci-e slot plaatsen?

[Anoniem: 388209]

Ik heb net de Silicon image drivers verwijderd, computer opnieuw gestart, nu wordt hij herkend als dc-300e stripe set 0 2000gb. Maar helaas geen verschil in prestaties.

Tijdens het configureren van de RAID setup kon ik een bronblock grootte instellen. 32 - 64 - 128, hier heb ik gekozen voor 128. Eigenlijk geen idee wat voor een functie dat heeft?

[ Voor 7% gewijzigd door Anoniem: 388209 op 21-12-2010 13:38 ]

[Anoniem: 388209]

manzonderdas schreef op dinsdag 21 december 2010 @ 13:16:
heb je al de laatste nieuwe drivers van Silicon image gedownloaded?

Kan je de controller in een ander pci-e slot plaatsen?

Nee ik hem maar 1 x PCI x1

[Anoniem: 388209]

Phas0r schreef op dinsdag 21 december 2010 @ 13:10:
Als ik goed kijk staat de CPU usage op 31%, lijkt me dat deze kaart aardig leunt op je CPU. Heb zelf een HighPoint RocketRaid 2640x4 met 2 schijven in RAID0 en dan is de CPU belasting maar 3% 1.9%, ook liggen de lees en schrijf snelheden veel dichter bij elkaar bij mij. Vreemd ...

Mijn setup:
[afbeelding]

Misschien toch even checken of je de juiste drivers hebt en of je wat in kan stellen voor die kaart

Kijk dat zijn mooie cijfers. Dat is zeker een kaart met eigen processor en geheugen?

[Ventieldopje]

Je kunt ook een PCI-e 1x kaart in een PCI-e x4 of x16 slot stoppen

En ja deze heeft wel een eigen processor en geheugen en is x4 maar heeft dan ook 4 poorten, voor 2 poorten is x1 voldoende, maar voor hardware raid controllers redelijk goedkoop model, aangezien TS ook aan geeft dat hij met een redelijk goedkope raid controller gebruikt heb ik die vergelijking gemaakt.

[ Voor 68% gewijzigd door Ventieldopje op 21-12-2010 13:40 ]

[analog_]

Phas0r schreef op dinsdag 21 december 2010 @ 13:38:
Je kunt ook een PCI-e 1x kaart in een PCI-e x4 of x16 slot stoppen

Wat zinloos is. Het probleem moet je denk ik in de controller zoeken, het zou mij ook niet verbazen dat je met echte software raid betere cijfers kan neerzetten (dit is fake raid). De disks en connecties zijn in principe in orde, een pci-e laan geeft 250MB, dat is 120MB meer dan een gewone PCI bus waarop dergelijke cijfers wel te verwachten zijn.

In Windows kan je software raid instellen, ik zou dat eens proberen om te vergelijken. Als je hier kijkt zie je dat ze er zelf ook maar 110MB uit halen max.

[ Voor 11% gewijzigd door analog_ op 21-12-2010 13:47 ]

[Anoniem: 388209]

Dat meen je niet? Die connectoren zijn toch veel kleiner, of maakt dat niet uit?

[Ventieldopje]

Die connectoren zijn kleiner maar het past gewoon en werkt ook gewoon Zeker een poging waard.

@analog_ ... Onzin, software raid zal niks sneller zijn omdat dan echt alles op de CPU terecht komt, het zou juist sneller moeten zijn via het kaartje (wat dus wel hardware raid is).

[ChojinZ]

Phas0r schreef op dinsdag 21 december 2010 @ 13:47:
Die connectoren zijn kleiner maar het past gewoon en werkt ook gewoon Zeker een poging waard.

@analog_ ... Onzin, software raid zal niks sneller zijn omdat dan echt alles op de CPU terecht komt, het zou juist sneller moeten zijn via het kaartje (wat dus wel hardware raid is).

Goedkope raid kaartjes zijn bijna altijd software raid (ook al wordt er een losse insteekkaart gebruikt). Op de goedkope kaartjes zitten namelijk geen processor die het werk doet. Dit wordt dan nog steeds gedaan door de CPU. Daarom zijn de prijzen van de kaartjes vaak ook zo goedkoop. Het verschil in performance tussen software raid via je MObo of een goedkoop kaartje is vaak niet heel groot....


RAID FAQ

[ Voor 3% gewijzigd door ChojinZ op 21-12-2010 13:56 ]

[analog_]

Phas0r schreef op dinsdag 21 december 2010 @ 13:47:
Die connectoren zijn kleiner maar het past gewoon en werkt ook gewoon Zeker een poging waard.

@analog_ ... Onzin, software raid zal niks sneller zijn omdat dan echt alles op de CPU terecht komt, het zou juist sneller moeten zijn via het kaartje (wat dus wel hardware raid is).

Dit is een sil3132 wat neerkomt op de meeste cheape s-ata controller evah (ok,ok de sil3112 is dat). Geloof me, dit is fake raid en bijzonder crap. Die 3% extra CPU verbruik zou ik niet van wakker liggen en daarbij gebruikt fakeraid ook de CPU enkel valt het dan onder een driver die bij je kernel draait dus valt het simpelweg niet op. Ik ben vrij zeker dat het kaartje de beperkende factor is, ik twijfel of het ook in 'normale' mode die 110MB limiet heeft of dat dit door de raid berekeningen komt.

@Phasor, jij hebt een echte hardware kaart dat is het verschil en waarom jouw situatie niet transponeert op deze.

ps. goedkoop is <12euro per poort, dat is ongeveer de grens tussen hardware en fake raid.

[ Voor 11% gewijzigd door analog_ op 21-12-2010 14:03 ]

[DukeBox]

En geheel offtopic maar handig voor de volgende keer.. maak je plaatjes aub in png of gif..

[Ventieldopje]

Uit reviews:

Het kaartje kost eigenlijk ook niet zoveel. Ik haal toch een acceptabele 145-150MB/s met m'n raptors! Dat vind ik voor dit installatie gemak en de spotprijs heel mooi.

Hah, acceptabel Maargoed, toch vreemd dat er wel een processor op zit die RAID0 mogelijk maakt, vraag me af wat die dan doet aangezien dit ook weer niet een gewone niet RAID controller (paar poortjes op een plankje) is

[analog_]

Phas0r schreef op dinsdag 21 december 2010 @ 13:59:
Uit reviews:
[...]

Hah, acceptabel Maargoed, toch vreemd dat er wel een processor op zit die RAID0 mogelijk maakt, vraag me af wat die dan doet aangezien dit ook weer niet een gewone niet RAID controller (paar poortjes op een plankje) is

Er zit een processor op, echter die offload het deels naar de CPU/driver. Zie het als volgt voor raid 5: de effectieve xor gebeurt op de CPU en de data-in en data-uit loopt over je pci-e laan dus je verliest met meer disks ook performance als je lane te small is voor alle ruwe data van die disks (dit zie je snel met PCI fake raid controllers door 133MB/PCI controller, niet slot). Echte controllers voeren de XOR op een dedicated circuit uit en zijn dus meestal minder beperkt. Bijvoorbeeld hebben alle IOP331 gebaseerde kaarten zoals de areca11x0 reeks een max troughput van als ik mij goed herinner een 330MB/sec.

[Anoniem: 388209]

Ik denk inderdaad dat het kaartje de zwakke schakel is, wel vreemd die in die review wel hogere snelheden behaald worden. Maarja een review zonder grafieken is ook niets waard.

Bedankt allemaal, ik ga maar eens voor een beter kaartje kijken.

[analog_]

Probeer software raid in windows eens uit aub en als dat niet werkt gewoon software raid op je moederbord.

[Anoniem: 388209]

Dat zal ik proberen. Weet jij ergens een goede howto te vinden?

[heuveltje]

Daarnaast merk je een lagere accestime veel meer in het dagelijks gebruik dan een hogere doorvoersnelheid.
En die is met raid0 altijd al wat hoger, en op jouw systeem zelfs behoorlijk hoog (19ms)

[Ventieldopje]

Is het niet zo dat je RAID volumes gemaakt in Windows 7 alleen op andere schijven kan toepassen en niet op de OS schijf? In dat geval is een RAID0 array aanmaken via je moederbord de makkelijkste en snelste optie

Verschil tussen software RAID en fake raid: http://kmwoley.com/blog/?p=429

[ Voor 17% gewijzigd door Ventieldopje op 21-12-2010 14:46 ]

[Anoniem: 151407]

zitten er op je schijven nog een jumper?
zo ja dan zijn je schijven nu locked op sata 1 mode en traag.
haal de jumpert eraf en ze gaan naar sata 2 mode.
draai zelf 4x 500 gb 7200 in raid 0 en zelfs via onboard controller en haal ik 450 mb/s read en 390 write..

[M2M]

Anoniem: 388209 schreef op dinsdag 21 december 2010 @ 14:24:
Dat zal ik proberen. Weet jij ergens een goede howto te vinden?

software raid via de bios is het gemakkelijkst. Zie het boekje van je moederbord. Vrij eenvoudig, waarschijnlijk gewoon in de bios "raid" selecteren. Vervolgens heb je een extra menuutje na de post, waar je dingen in kunt stellen en een raid0 array kunt aanmaken. Vervolgens in windows booten en de boel zou moeten werken. Eventueel nog via de schijfmanager een volume aanmaken.

Toch vind ik wel wat vreemde dingen aan je raid array zitten. De accesstimes lijken wel verdubbeld, en het cpu-verbruik, zoals eerder aangegeven, is nogal gigantisch.

Verder vind ik dat je snelheid nogal heel erg varieert. Ik neem aan dat je geen gekke dingen op het array aan het doen bent, zoals bestanden copieren, of een windows installatie er op hebben staan die je momenteel gebruikt. Dat zou het onregelmatige patroon verklaren.

Mij lijkt het, met de info die je nu hebt vergaard, een stel brakke drivers.

Overigens kun je misschien je harde schijven ook nog even los testen, op de controller en op je moederbord. (een schijf op de controller, en eentje op het mobo, vervolgens resultaten vergelijken en eventueel de config omdraaien om brakke schijven uit te sluiten)

Anoniem: 151407 schreef op dinsdag 21 december 2010 @ 14:48:
zitten er op je schijven nog een jumper?
zo ja dan zijn je schijven nu locked op sata 1 mode en traag.
haal de jumpert eraf en ze gaan naar sata 2 mode.
draai zelf 4x 500 gb 7200 in raid 0 en zelfs via onboard controller en haal ik 450 mb/s read en 390 write..

SATA 1 is niet traag. anderhalve gigabit/s is ruim voldoende voor traditionele harde schijven. Minus overhead houdt je nog 150MB/s over. Enkel in burst mode zul je performance verlies hebben.

[ Voor 17% gewijzigd door M2M op 21-12-2010 14:50 ]

[Axewi]

heey,

mischien een domme vraag hoor..
heb je een onboard raid controller? zo ja gebruik die eens en kijk eens of het beter gaat.
en heb je die hd tune wel op een block sise van 128KB staan met testen? anders dan moet je pc eerst alle 32kb bestanden omzetten in 128kb en daarna nog eens gaan verdelen (kan de hoge cpu load zijn)

het verschil tussen je 32kb 64kb en 128kb is dat hij bij het verdelen tussen de schijven alle bestanden naar die grote deelt dus heb je veel bestanden kleiner dan 32kb is 32kb verstandig doe je daar 128kb instellen dan maakt hij van elk klein bestand eerst 128kb en daarna splitst hij het. (correct me if i am wrong)

plaats hier je result even met het verschil als je hdtune op 128 kb zet

[Ventieldopje]

Je kunt het vergelijken met een honingraad, als je een bestand hebt dat kleiner is dan je blocksize vult hij 1 heel blok dus heb je aardig wat verlies maar is wel sneller met uitlezen aangezien hij in een keer een heel blok kan lezen dus in principe is het sneller alleen kost het meer ruimte als je veel kleine bestanden hebt

@m2m, jij draait je schijven zeker in SATA1

[Anoniem: 388209]

M2M schreef op dinsdag 21 december 2010 @ 14:49:
[...]

software raid via de bios is het gemakkelijkst. Zie het boekje van je moederbord. Vrij eenvoudig, waarschijnlijk gewoon in de bios "raid" selecteren. Vervolgens heb je een extra menuutje na de post, waar je dingen in kunt stellen en een raid0 array kunt aanmaken. Vervolgens in windows booten en de boel zou moeten werken. Eventueel nog via de schijfmanager een volume aanmaken.

Toch vind ik wel wat vreemde dingen aan je raid array zitten. De accesstimes lijken wel verdubbeld, en het cpu-verbruik, zoals eerder aangegeven, is nogal gigantisch.

Verder vind ik dat je snelheid nogal heel erg varieert. Ik neem aan dat je geen gekke dingen op het array aan het doen bent, zoals bestanden copieren, of een windows installatie er op hebben staan die je momenteel gebruikt. Dat zou het onregelmatige patroon verklaren.

Mij lijkt het, met de info die je nu hebt vergaard, een stel brakke drivers.

Overigens kun je misschien je harde schijven ook nog even los testen, op de controller en op je moederbord. (een schijf op de controller, en eentje op het mobo, vervolgens resultaten vergelijken en eventueel de config omdraaien om brakke schijven uit te sluiten)

[...]


SATA 1 is niet traag. anderhalve gigabit/s is ruim voldoende voor traditionele harde schijven. Minus overhead houdt je nog 150MB/s over. Enkel in burst mode zul je performance verlies hebben.

Jep windows 7 staat op deze raid setup.

[Alfa Novanta]

M2M schreef op dinsdag 21 december 2010 @ 14:49:
[...]

software raid via de bios is het gemakkelijkst. Zie het boekje van je moederbord. Vrij eenvoudig, waarschijnlijk gewoon in de bios "raid" selecteren. Vervolgens heb je een extra menuutje na de post, waar je dingen in kunt stellen en een raid0 array kunt aanmaken. Vervolgens in windows booten en de boel zou moeten werken. Eventueel nog via de schijfmanager een volume aanmaken.

Toch vind ik wel wat vreemde dingen aan je raid array zitten. De accesstimes lijken wel verdubbeld, en het cpu-verbruik, zoals eerder aangegeven, is nogal gigantisch.

Verder vind ik dat je snelheid nogal heel erg varieert. Ik neem aan dat je geen gekke dingen op het array aan het doen bent, zoals bestanden copieren, of een windows installatie er op hebben staan die je momenteel gebruikt. Dat zou het onregelmatige patroon verklaren.

Mij lijkt het, met de info die je nu hebt vergaard, een stel brakke drivers.

Overigens kun je misschien je harde schijven ook nog even los testen, op de controller en op je moederbord. (een schijf op de controller, en eentje op het mobo, vervolgens resultaten vergelijken en eventueel de config omdraaien om brakke schijven uit te sluiten)

[...]


SATA 1 is niet traag. anderhalve gigabit/s is ruim voldoende voor traditionele harde schijven. Minus overhead houdt je nog 150MB/s over. Enkel in burst mode zul je performance verlies hebben.

^ hier wil ik me graag bij aansluiten.

• PCI-e 1x = 250MB/s dus heeft nog wel ruimte over. Zal niet de beperkende factor zijn.
• Check inderdaad de jumper op je schijven, of ze wel optimaal werken.
• Test eerst eens met 1 disk.
• Test met ATTO en een bestandsgrootte van 256 MB.
  (http://www.techpowerup.co...Disk_Benchmark_v2.34.html)
• het kaartje is niet erg bijzonder, maar sneller als dit moet hij zeker kunnen
• controleer je CPU gebruik voor de test, sluit overige programma's af. CPU ca. 5% houden
• update firmware van je hardeschijven en naar dezelfde versie
• probeer diverse drivers voor dit kaartje en zet de nieuwste firmware erop !

[ Voor 7% gewijzigd door Alfa Novanta op 21-12-2010 15:31 ]

[Anoniem: 388209]

Axewi schreef op dinsdag 21 december 2010 @ 14:52:
heey,

mischien een domme vraag hoor..
heb je een onboard raid controller? zo ja gebruik die eens en kijk eens of het beter gaat.
en heb je die hd tune wel op een block sise van 128KB staan met testen? anders dan moet je pc eerst alle 32kb bestanden omzetten in 128kb en daarna nog eens gaan verdelen (kan de hoge cpu load zijn)

het verschil tussen je 32kb 64kb en 128kb is dat hij bij het verdelen tussen de schijven alle bestanden naar die grote deelt dus heb je veel bestanden kleiner dan 32kb is 32kb verstandig doe je daar 128kb instellen dan maakt hij van elk klein bestand eerst 128kb en daarna splitst hij het. (correct me if i am wrong)

plaats hier je result even met het verschil als je hdtune op 128 kb zet

Nee ik heb geen onboard controller helaas. 128kb geeft ook geen betere resultaat..

[Kosty]

Dit zijn EARS schijven, kijk eens na of je 100% zeker een clustergrootte van 4KB hebt ingesteld ?
Trouwens: "Dit zijn EARS schijven", dat zijn niet echt betrouwbare schijven om te gebruiken in RAID

Leesvoer :
http://www.tomshardware.com/reviews/wd-4k-sector,2554-2.html
http://community.wdc.com/...-issues-in-RAID/m-p/11559

[M2M]

Phas0r schreef op dinsdag 21 december 2010 @ 15:01:
Je kunt het vergelijken met een honingraad, als je een bestand hebt dat kleiner is dan je blocksize vult hij 1 heel blok dus heb je aardig wat verlies maar is wel sneller met uitlezen aangezien hij in een keer een heel blok kan lezen dus in principe is het sneller alleen kost het meer ruimte als je veel kleine bestanden hebt

@m2m, jij draait je schijven zeker in SATA1

uiteraard... niet

Desalniettemin is en blijft SATA1 ruim voldoende bandbreedte hebben voor traditionele harde schijven. Enkel 15k SAS schijven zullen niet voldoende ruimte hebben op een sata1 interface. Dus zelfs als die jumper op de schijf op SATA1 staat heb je voldoende bandbreedte over.
Overiges zal de TS inderdaad tegen het limiet van 250MB/s aanlopen. De PCI-E x1 bus snelheid

Maargoed, het zou kunnen zijn dat windows heel hard bezig is met indexeren of een andere stomme taak (updates binnenhengelen / installen). Als je een betrouwbaardere grafiek wil zien, is het verstandig windows op een andere schijf te zetten. En uiteraard te zorgen dat er geen lees / schrijfacties op de schijf plaatsvinden. (lege schijf!)

Anoniem: 388209 schreef op dinsdag 21 december 2010 @ 15:10:
[...]
Nee ik heb geen onboard controller helaas. 128kb geeft ook geen betere resultaat..

een ICH10 zonder raid support? (ook al is het softwareraid)?

toch wel: link

ICH10... geen ICH10R

[ Voor 12% gewijzigd door M2M op 21-12-2010 15:43 ]

[Anoniem: 388209]

Hhmm...vreemd. In mijn BIOS kan ik alleen kiezen uit IDE en AHCI daarom heb ik deze PCI controller gekocht. Vreemd dat er dan wel een RAID handleiding is voor mijn moederbord

[Anoniem: 388209]

In de BIOS van die RAID controller kon ik tijdens het configureren van RAID kiezen uit 4 - 8 - 16 - 32 - 64 - 128kb blocksize. Nu lees ik dat 128kb de beste resultaat geeft, echter ik heb 64kb ingesteld.

[Anoniem: 388209]

Zie net in mijn apparaatbeheer dat de DC-300e virtual RAID processor geen drivers had. Deze heb ik nu geinstalleerd. CPU load tot 3-5 % in laatste test. Dat is nu dus verbeterd, schrijf / lees blijft bedroevend.

[Anoniem: 388209]

Laatste test. HD Tune ingesteld op 64kb, accestime en cpu usage zijn beduidend beter nu.

[Femme]

heuveltje schreef op dinsdag 21 december 2010 @ 14:39:
Daarnaast merk je een lagere accestime veel meer in het dagelijks gebruik dan een hogere doorvoersnelheid.
En die is met raid0 altijd al wat hoger, en op jouw systeem zelfs behoorlijk hoog (19ms)

Een goede raidcontroller zorgt voor een minimale toename van de latency (of presteert zelfs beter dan een crappy sata-controller). In de praktijk is het zinvoller om te kijken naar de gemiddelde sequentiële transferrate of de gemiddelde responstijd van een bepaalde workload (komt eigenlijk op hetzelfde neer). Raid 0 zorgt wel degelijk voor een afname van de gemiddelde responstijd omdat sequentiële I/O sneller uitgevoerd kan worden en I/O's met een kleine transfergrootte die gericht zijn op stripes die zich op verschillende disks bevinden gelijktijdig uitgevoerd kunnen worden. Die flauwekul over een hogere toegangstijd kun je dus vergeten.

De raid-stack bevindt zich eigenlijk bij alle controllers in de software. Of deze software op de cpu draait (via de driver) of op een dedicated processor op de raidcontroller maakt voor de prestaties niet zo heel veel uit. Zogenaamde hardware raidcontrollers halen hun prestatievoordeel vooral uit een grote cache (met een battery backup), waarmee zij trucjes mogen uithalen die niet veilig zijn voor een hostbased raidcontroller.

[Anoniem: 388209]

Is het mogelijk deze RAID setup te verwijderen, een nieuwe configureren, zonder windows opnieuw te hoeven installeren? Want dan kan ik gewoon even de blocksize op 128kb zetten zonder al teveel moeite.

[Anoniem: 15758]

Je moet geen RAID-volumes testen met HDTune; dat is geen juiste benchmark. Alleen benchmarks gebruiken die op je filesystem testen; zoals ATTO, AS SSD en CrystalDiskMark; vrijwel alle andere benchmarks kunnen incorrecte scores geven.

Paar opmerkingen:
- je test je systeemschijf; dus de vele drops naar 0MB/s zijn normaal en betekent dat je eigenlijk je schijf niet goed kunt testen
- RAID0 werkt ook voor random IOps; maar elke HDD is supertraag als systeemschijf dus je zou iets van duizend hardeschijven nodig hebben om de IOps van een SSD te kunnen evenaren, en dan zit je nog steeds met te hoge latencies; dus een SSD als systeemdisk is een must als je iets om performance geeft; pas dan kun je verder kijken naar mass storage IMO.
- je hebt nog geen échte benchmark uitgevoerd; post een CDM plaatje dat zou veel meer info moeten geven
- is je partitie aligned? kun je testen met AS SSD
- Heb je de stripesize op 128KiB staan? Dat is dus wat anders dan je in HDtune invoert; dat heb je gekozen toen je de RAID volume aanmaakte in de RAID setup utility.
- Silicon Image is de laagst/slechts mogelijke RAID drivers; misschien dat alleen JMicron nog slechter is; dus tja heb niet teveel verwachtingen; de software RAID0 van Windows zelf werkt veel beter.

[ Voor 16% gewijzigd door Anoniem: 15758 op 21-12-2010 16:41 ]

[Anoniem: 388209]

Heey dat is duidelijk.

Ik wil de stripesize veranderen naar 128kb, deze staat nu ingesteld op 64kb. Echter dan moet in de huidige configuratie verwijderen en een nieuwe configureren. Blijft de OS dan nog wel bootable?

[Anoniem: 388209]

AS SSD gedownload, Silicon driver reeds vervangen door, DC-300e driver.

[Anoniem: 15758]

Stripesize veranderen kan helaas niet zonder gegevensverlies; dat betekent dus dat alles op je volume weg is. Misschien kun je beter eerst andere benchmarks doen en later de 64KiB stripesize naar 128KiB omzetten. Let op dat dit in sommige (onjuiste) benchmarks waaronder HDTune juist een snelheidsverlaging kan betekenen; dit is echter alleen bij foutieve benchmarks die alle optimalisaties van je filesystem omzeilt en vervolgens niet voldoende queueing toepast; zodat in je striping RAID volume maar één disk aan het werk is. Dit zou niet mogen gebeuren in échte omstandigheden waarbij je filesystem betrokken is; door read-ahead en write buffering zouden alle schijven bij sequential I/O gebruikt moeten worden en je snelheid dus vrijwel lineair zal stijgen.

Wat bedoel je precies met driver vervangen? DC-300e is?
* edit: oh dat je dawicontrol driver gebruikt; dat is ook gewoon Silicon Image driver maar misschien een iets oudere versie dan Silicon Image op haar website heeft staan.

[ Voor 9% gewijzigd door Anoniem: 15758 op 21-12-2010 17:10 ]

[Anoniem: 269504]

Is de bios van de kaart wel up to date ,versie 3.61 is zo te zien de laatste bios.


http://www.dawicontrol.com/index.php?cmd=raid

[Anoniem: 15758]

De BIOS heeft alleen een functie om de RAIDset aan te maken en ervan te booten; na het booten functioneert de Silicon Image 'RAID' controller gewoon als een SATA/AHCI controller met drivers die RAID implementeren. Dit wordt ook wel Onboard RAID / Hybrid RAID / FakeRAID / FirmwareRAID genoemd. Die laatste is overigens incorrect; omdat de firmware alleen een functie vormt bij het booten en er dus 0,0 'acceleratie' is van de hardware voor alle RAID-functionaliteit.

Het is dus software RAID; alleen echte software RAID is niet bootable; althans Windows heeft daar geen support voor.

Wat betreft je controller; het is geen dure controller dus dit is wat je ervan mag verwachten; niet echt iets waardoor je nog veel meer performance eruit kunt slepen. Intel onboard RAID0 heeft wel die mogelijkheid, omdat het RAM write-back ondersteunt wat in de praktijk best leuke winsten kan opleveren.

[Anoniem: 388209]

Ja klopt op goede hoop heb ik gertracht kosten te besparen. Heb nu heel het zooitje omgezet naar 128kb wederom zonder resultaat. (met andere benchmark app.)

Er zit niets anders op dan Windows te booten vanaf een ssd en dit setje ernaast laten lopen voor opslag. Wellicht dat deze setup iets beter uit de verf komt zonder boot.

[Ventieldopje]

Die dingen zijn nou eenmaal niet goedkoop helaas, kosten er op besparen zal dan ook dit soort resultaten hebben

[raymondw]

Kosty schreef op dinsdag 21 december 2010 @ 15:11:
Dit zijn EARS schijven, kijk eens na of je 100% zeker een clustergrootte van 4KB hebt ingesteld ?
Trouwens: "Dit zijn EARS schijven", dat zijn niet echt betrouwbare schijven om te gebruiken in RAID

Leesvoer :
http://www.tomshardware.com/reviews/wd-4k-sector,2554-2.html
http://community.wdc.com/...-issues-in-RAID/m-p/11559

Dit is zeker een probleem met EARS disken.
Heb zelf twee disken die ik met meerdere controllers en settings getest heb, werd alleen maar slechter
Nu 2 AAKX er in en ik word er nog steeds heel blij van
Mis-alignement was er bij niet uit te krijgen, onder CentOS 5.5 was het zelfs zo erg dat een simpele mysql query de hele boel zo verstopte dat er een error kwam op inode niveau
(Hardware RAID ctrl met 1GB cache en BBU)

EARS
load onder Linux 2.+ en tijdens Mysql load 4.+ en een crash
Windows7 59MB/s in R1 op 3Gbps controller

AAKX
load onder Linux <1.1
Windows7 doorvoer 120-130MB in R1 op 3Gbps controller

Raid0 zou dus nog veel hoger moeten kunnen komen, maar dat vind ik net ff te riskant.
Dan maar ietsje geld uitgeven en wat sneller ijzer de kast in.

[DataGhost]

Ik weet niet of iemand naar dat screenshot heeft gekeken maar dat heeft dus echt geen zak met block/stripesizes en weet ik veel wat te maken. Bij een gezonde schijf/controller (bijvoorbeeld Phas0r in "RAID 0 geen significant snelheidsverschil") zie je een duidelijke kromme in de snelheidsgrafiek, vanwege het simpele feit dat de schijf minder snel gelezen kan worden tegen het einde aan. In het grafiekje van de TS zie je daar helemaal niks van terug, wat op een bottleneck duidt. De schijven zelf staan volgens mij gewoon keihard te blazen maar de controller lijkt me hier duidelijk het probleem. De piek blijft net onder 133 MB/s zitten, gemiddeld ietsjes lager... dan denk ik aan een PCI-chip die toevallig aan een PCIe-bus gehangen wordt. Ik denk dan ook dat het gewoon een kutcontroller is en je er beter eentje kan kopen die wel native PCIe is.

Google ook even op "dc-300e", ik krijg dan direct de volgende twee hits:

Anoniem: 15758 schreef op dinsdag 21 december 2010 @ 16:40:
Je moet geen RAID-volumes testen met HDTune; dat is geen juiste benchmark. Alleen benchmarks gebruiken die op je filesystem testen; zoals ATTO, AS SSD en CrystalDiskMark; vrijwel alle andere benchmarks kunnen incorrecte scores geven.

Sorry maar dit is echt dikke onzin. Het filesystem is niet eens van belang bij deze benchmark. Je moet de benchmark kiezen die aansluit bij wat je wilt weten. Als je de doorvoersnelheid van je RAID0 wilt testen kan je dus perfect HD Tune gebruiken. Daarnaast doet bijv. ATTO nog steeds geen zak met je filesystem maar simuleert het gewoon bepaalde loads. Voor een benchmark wil je natuurlijk zoveel mogelijk externe invloeden, zoals bijvoorbeeld de performance (en staat!) van je filesystem, uitsluiten.

[ Voor 27% gewijzigd door DataGhost op 22-12-2010 13:28 ]

[Ventieldopje]

Lol met 2 schijven nog niet voorbij sata 150 komen Lijkt ook wel in de grafiek van hem of de schijven er ondertussen ook steeds ff uit klappen http://gathering.tweakers.net/forum/view_message/35241753

[_H_G_]

Anoniem: 388209 schreef op dinsdag 21 december 2010 @ 19:16:
Er zit niets anders op dan Windows te booten vanaf een ssd en dit setje ernaast laten lopen voor opslag. Wellicht dat deze setup iets beter uit de verf komt zonder boot.

Je kan die kaart toch nog wel terugsturen? Dat "setje" werkt gewoon niet. Hang ze los op je ich10, ahci aan en rapid storage driver. Desnoods software raid 0, maar los zijn ze nog beter dan dat setje.

[Anoniem: 15758]

DataGhost schreef op woensdag 22 december 2010 @ 13:19:
Ik weet niet of iemand naar dat screenshot heeft gekeken maar dat heeft dus echt geen zak met block/stripesizes en weet ik veel wat te maken. Bij een gezonde schijf/controller (bijvoorbeeld Phas0r in "RAID 0 geen significant snelheidsverschil") zie je een duidelijke kromme in de snelheidsgrafiek, vanwege het simpele feit dat de schijf minder snel gelezen kan worden tegen het einde aan. In het grafiekje van de TS zie je daar helemaal niks van terug, wat op een bottleneck duidt.

Eens. De vraag is natuurlijk waar de bottleneck door komt.

Een platte grafiek in HDTune op RAID arrays betekent meestal dat de RAID driver geen read ahead toepast, zoals de controller van Phas0r wel doet.

De schijven zelf staan volgens mij gewoon keihard te blazen maar de controller lijkt me hier duidelijk het probleem. De piek blijft net onder 133 MB/s zitten, gemiddeld ietsjes lager... dan denk ik aan een PCI-chip die toevallig aan een PCIe-bus gehangen wordt. Ik denk dan ook dat het gewoon een kutcontroller is en je er beter eentje kan kopen die wel native PCIe is.

De Silicon Image SiI-3132 is een native PCI-express controller. Het enige wat 'kut' is aan deze controller zijn de Silicon Image FakeRAID drivers onder Windows. Onder andere OSen is dit een prima controllertje, ook met RAID zolang je iets anders gebruikt dan de Silicon Image Windows-only drivers.

Sorry maar dit is echt dikke onzin. Het filesystem is niet eens van belang bij deze benchmark. Je moet de benchmark kiezen die aansluit bij wat je wilt weten. Als je de doorvoersnelheid van je RAID0 wilt testen kan je dus perfect HD Tune gebruiken. Daarnaast doet bijv. ATTO nog steeds geen zak met je filesystem maar simuleert het gewoon bepaalde loads. Voor een benchmark wil je natuurlijk zoveel mogelijk externe invloeden, zoals bijvoorbeeld de performance (en staat!) van je filesystem, uitsluiten.

Filesystem is niet van belang? Juist héél erg van belang en exact de issue van de TS.

CrystalDiskMark/AS SSD/ATTO/Sisoft Sandra testen allemaal op je filesystem. Je filesystem past technieken als read-ahead en write buffering toe, dat houdt in dat wanneer ATTO de eerste block vraagt, de storage device (RAID array) gelijk 8 of meer blokken opgevraagd krijgen die gecached worden. Op deze manier kunnen er meerdere members in een RAID0 (of andere striping RAID) aan het werk gaan tegelijkertijd. Dit is niet altijd mogelijk als je één blok per keer vraagt; oftewel queue depth = 1.

Dus als filesystems een groot bestand inlezen of wegschrijven, sequential I/O, doen ze dat altijd met een hoge queue depth. Maar als je het filesystem omzeilt en je gaat raw I/O doen met queue depth = 1, zoals HDTune doet, dan kun je potentiëel lagere performance krijgen dan je echte applicaties dat krijgen. Het is dus een ongeschikte benchmark voor het doel: weten hoe echte applicaties grote bestanden kunnen inlezen en wegschrijven.

Je kan in HDTune wel de Files benchmark gebruiken, die gebeurt wel op het filesystem. De normale raw benchmark kun je ook nog tunen door een grotere block size te gebruiken; merk wel op dat dit niet nodig is met een grotere queue depth zoals normaliter het geval is. Een blocksize van 1 megabyte zorgt ervoor dat een RAID0 met 128KiB stripes tot 8 disks aan het werk kan zetten bij één I/O. Maar dat blijft een kunstmatige vorm van I/O die in de praktijk simpelweg niet voorkomt. HDTune dient zijn benchmark multi-queue te maken om geschikt te worden voor alle storage. Nu werkt de benchmark goed als de controller eigen technieken toepast, zoals vrijwel alle hardware RAID doen.

Wat je wilt weten is niet hoe je storage op kunstmatige I/O reageert die nooit voorkomt, maar wel hoe het op daadwerkelijke I/O reageert in het dagelijks gebruik. Dus voor dit doel is HDTune weinig zinvol voor de TS met Silicon Image RAID drivers.

[Anoniem: 388209]

Ja ik heb het "setje" he-he, weer terug in de verpakking gedaan. Heb ze nu weer ahci staan op de ich10.

1 schijf is windows boot en de andere voor opslag nu. Heb gelijk nieuwe tests gedaan, welke ik voor de geïnteresseerde zo zal posten.

[Anoniem: 388209]

_H_G_ schreef op woensdag 22 december 2010 @ 14:46:
[...]

Je kan die kaart toch nog wel terugsturen? Dat "setje" werkt gewoon niet. Hang ze los op je ich10, ahci aan en rapid storage driver. Desnoods software raid 0, maar los zijn ze nog beter dan dat setje.

Ja ik heb het "setje" he-he, weer terug in de verpakking gedaan. Heb ze nu weer ahci staan op de ich10.

1 schijf is windows boot en de andere voor opslag nu. Heb gelijk nieuwe tests gedaan, welke ik voor de geïnteresseerde zo zal posten.

[Anoniem: 388209]

Schijf 1 (opslag)



Schijf 2 (Windows 7)



Beide hoge cpu load

[Anoniem: 388209]

Dus met dat kaartje werd de setup wel 20-25 MB/s sneller. (met windows installatie).
Met RAID 0 heb ik max 127MB/s gehaald, zal dit hoger worden wanneer de opstelling geen boot device is?

[Ro-Maniak2]

Nou dat deugt toch echt ook niet, zoals hiervoor al is opgemerkt. Bij een magnetische draaiende HDD moet het altijd een kromme lijn omlaag zijn. "Vooraan" de schijf worden de hoogste transfers behaald, daarna neemt het af.

Dit bewijst dat er ergens een bottleneck zit. Je schijven zijn sneller dan dit maar er komt niet meer door de bottleneck heen. De schijven pompen de bottleneck continu helemaal vol.

Wel vaag, het is dus niet die RAID controller... moet bijna wel iets met de chipset zelf zijn dan (want daar moet de data doorheen of die nou van de interne chipsetcontroller komt of via de PCIe bus).

Windows opnieuw installeren? Eens testen onder een (Ubuntu?) Linux live CD?

Overigens ben ik het oneens met de opmerkingen dat je schijven op SATA 150 laten staan (jumper) niet boeit: heeft in ieder geval invloed op de snelheid waarmee de data uit de onboard cache van de schijven kan worden doorgepompt. Dat is gewoon RAM dus veel sneller dan de schijf zelf. Moderne schijven hebben niet voor niets >32MB geheugen: ze lezen flink slim vooruit en stoppen dat vast in de onboard cache. Je wilt de snelheid waarmee dat over kan komen niet beperken.

[_H_G_]

Vaag. Vergeet sequentiele verschillen even. Die benchmark geeft gewoon aan dat er iets mis is. Ik snap er even niks van. Een ich10 met RST driver mag toch geen bottleneck vormen, maar toch heb je een rechte lijn..

Rotte kabels?

[Alfa Novanta]

DataGhost schreef op woensdag 22 december 2010 @ 13:19:
Ik weet niet of iemand naar dat screenshot heeft gekeken maar dat heeft dus echt geen zak met block/stripesizes en weet ik veel wat te maken. Bij een gezonde schijf/controller (bijvoorbeeld Phas0r in "RAID 0 geen significant snelheidsverschil") zie je een duidelijke kromme in de snelheidsgrafiek, vanwege het simpele feit dat de schijf minder snel gelezen kan worden tegen het einde aan. In het grafiekje van de TS zie je daar helemaal niks van terug, wat op een bottleneck duidt.

Klopt. Maargoed, onder het mom van alles uitsluiten kom je toch op aardig wat mogelijkheden die je zou kúnnen proberen. E.g. chipsetdriver, raidcard driver, raidcard firmware updaten e.d. Dat kan er weldegelijk invloed op hebben.

De schijven zelf staan volgens mij gewoon keihard te blazen maar de controller lijkt me hier duidelijk het probleem. De piek blijft net onder 133 MB/s zitten, gemiddeld ietsjes lager... dan denk ik aan een PCI-chip die toevallig aan een PCIe-bus gehangen wordt.

net andersom denk ik, maar idd

Limiet PCI is idd 133 MB/s maar dan wat minder door de overhead.

Ik denk dan ook dat het gewoon een kutcontroller is en je er beter eentje kan kopen die wel native PCIe is.

Mjah, voor RAID 0 is dat van minder belang denk ik. Ik gebruik zelf ook wel een Sweex kaartje voor mirror op mijn vriendin haar pc, maar uiteindelijk zijn mirror en stripe niet erg inspannend omdat je geen XOR hoeft te doen. RAID 5 daarentegen ....

Sorry maar dit is echt dikke onzin. Het filesystem is niet eens van belang bij deze benchmark. Je moet de benchmark kiezen die aansluit bij wat je wilt weten. Als je de doorvoersnelheid van je RAID0 wilt testen kan je dus perfect HD Tune gebruiken. Daarnaast doet bijv. ATTO nog steeds geen zak met je filesystem maar simuleert het gewoon bepaalde loads. Voor een benchmark wil je natuurlijk zoveel mogelijk externe invloeden, zoals bijvoorbeeld de performance (en staat!) van je filesystem, uitsluiten.

Als je een betere controller test met veel geheugen loop je vaak tegen de lamp omdat hij de acties dan vanuit het geheugen doet en je debiel hoge waardes krijgt van 1032MB/s o.i.d. en ATTO gebruikt bijvoorbeeld 256MB en dan zit je vaak toch echt naar disk te schrijven. Blijkt doorgaans beter te werken.

Zie dit als aanvulling, niet als negatief commentaar. We zijn het weldegelijk eens

[Ventieldopje]

één van je schijven heeft het er moeilijk mee zo te zien, die dalen in de grafiek zijn niet normaal aangezien de ander het wel "goed' doet. Kun je in het bios ook niks in stellen wat voor SATA snelheid je gebruikt, of in de RAID configuratie en anders een jumpertje op je hdd's? Wat als je die schijven nou probeert in een andere pc los van elkaar en test met HDtune?

[Ro-Maniak2]

Overigens zie ik nu dat je short stroke aan hebt staan.

Dat verklaart het rare resultaat waar ik net op in ging: er wordt maar een heel klein stukje van je HDD getest. Niet de hele HDD.

Dan is alleen nog maar de vraag of deze transfer rate (~100mb/s) normaal is voor deze schijf. Zo ja dan is er niets mis met de schijven, mobo chipset of OS.

Dat de OS schijf rare dips vertoont vind ik niet vreemd OMDAT het de OS schijf is, tijdens de test loopt Windows nog lekker ermee te klooien.

[Anoniem: 388209]

Ro-Maniak2 schreef op woensdag 22 december 2010 @ 15:58:
Overigens zie ik nu dat je short stroke aan hebt staan.

Dat verklaart het rare resultaat waar ik net op in ging: er wordt maar een heel klein stukje van je HDD getest. Niet de hele HDD.

Dan is alleen nog maar de vraag of deze transfer rate (~100mb/s) normaal is voor deze schijf. Zo ja dan is er niets mis met de schijven, mobo chipset of OS.

Dat de OS schijf rare dips vertoont vind ik niet vreemd OMDAT het de OS schijf is, tijdens de test loopt Windows nog lekker ermee te klooien.

Klopt beetje dom van me. Hieronder full:

[Anoniem: 388209]

Dit is ook vreemd. Toch een onboard RAID controller?

[psy]

Anoniem: 15758 schreef op dinsdag 21 december 2010 @ 16:40:
Je moet geen RAID-volumes testen met HDTune; dat is geen juiste benchmark.

Kan wel zijn, maar als andere users wel goede scores geven met HDTune zou ik me toch zeker wel zorgen maken. Puur als vergelijking heeft het toch wel enige waarde.

[Ventieldopje]

@psy, daar moet ik bij voegen dat mijn HDtune ook is gedaan als OS schijf. Slechte resultaten, waar?

100MB/s is normaal voor die schijven lijkt me, ICH10R zie ik staan ja die zou dus RAID moeten ondersteunen. Misschien een BIOS update een mogelijkheid of staat het op een aparte plek?

[ Voor 47% gewijzigd door Ventieldopje op 22-12-2010 17:02 ]

[Anoniem: 388209]

Nee het zou in het keuze menu moeten staan bij "IDE" en "AHCI" maar dat is niet het geval. In het boekje van dit moederbord staat wel een handleiding voor RAID configuraties, maar daar staat dan weer bij dat het alleen voor de p45r2000 is omdat die wel een ich10r south bridge chipset zou hebben en turbotwins2000 niet.

[DataGhost]

Anoniem: 15758 schreef op woensdag 22 december 2010 @ 14:51:
[...]
Een platte grafiek in HDTune op RAID arrays betekent meestal dat de RAID driver geen read ahead toepast, zoals de controller van Phas0r wel doet.

Kan je dat toelichten? Ik ga hier uit van de fysieke en mechanische eigenschappen van een harde schijf om tot een conclusie te komen, namelijk de conclusie dat er een bottleneck is die niet de schijf is. Read-ahead heeft hier niks mee te maken. Toegegeven, de schijf wordt niet in zijn geheel gelezen maar er wordt op bepaalde punten op de schijf een meting over een klein gebied gedaan. Read-ahead zou dus een verschil *kunnen* maken maar dat zou betekenen dat je pauzes tussen het lezen van blokken moet gaan inlassen, anders is er geen tijd om vooruit te lezen. Dan nog, controller of wat dan ook heeft echter compleet geen vermoeden van *waar precies* het volgende blok gelezen moet worden. Er kan dus simpelweg niet vooruit gelezen worden. Tenslotte gaat het alsnog niet helpen, na het lezen van het eerste blok wachten tot de rest is 'ge-readahead' en dan de rest lezen of in een keer alle blokken lezen gaat, hoe je het ook wendt of keert, nimmer verschil uitmaken in de resulterende snelheid (data gedeeld door tijd).

Zou je dan trouwens niet *juist* een kromme grafiek verwachten, gezien een schijf tegen het einde langzamer is dan tegen het begin? Er kan immers in dezelfde tijd (want die is elke meting constant) minder data gelezen worden en er wordt niet alvast vooruitgelezen...

Filesystem is niet van belang? Juist héél erg van belang en exact de issue van de TS.

Aangezien 'iedereen' NTFS gebruikt zie ik niet waarom niet iedereen dan grote problemen zou hebben hiermee en waarom andere mensen andere resultaten krijgen met HD Tune.

CrystalDiskMark/AS SSD/ATTO/Sisoft Sandra testen allemaal op je filesystem. Je filesystem past technieken als read-ahead en write buffering toe, dat houdt in dat wanneer ATTO de eerste block vraagt, de storage device (RAID array) gelijk 8 of meer blokken opgevraagd krijgen die gecached worden. Op deze manier kunnen er meerdere members in een RAID0 (of andere striping RAID) aan het werk gaan tegelijkertijd. Dit is niet altijd mogelijk als je één blok per keer vraagt; oftewel queue depth = 1.

Hee, ik heb wel globaal een idee van hoe het werkt hoor. Je filesystem doet helemaal niks, je OS past iets toe. Je kan perfect een implementatie van een NTFS-driver en/of kernel maken die geen read-ahead en ook geen write buffering toepassen. Dan nog, zie bovenstaand, vraag ik me serieus af waar jij dan een performancewinst verwacht. De bedoeling is dat de manier van opvragen transparant wordt afgehandeld en dat de applicatie daar niks mee te maken krijgt (tot op zekere hoogte maar dan ben je moedwillig aan het klieren hoor).

Dus als filesystems een groot bestand inlezen of wegschrijven, sequential I/O, doen ze dat altijd met een hoge queue depth. Maar als je het filesystem omzeilt en je gaat raw I/O doen met queue depth = 1, zoals HDTune doet, dan kun je potentiëel lagere performance krijgen dan je echte applicaties dat krijgen. Het is dus een ongeschikte benchmark voor het doel: weten hoe echte applicaties grote bestanden kunnen inlezen en wegschrijven.

Wederom, readahead gebeurt op een ander niveau dan je filesystem. Daarnaast is het doel van *deze* benchmark vrij duidelijk: kijken wat de sequentiele leessnelheid van je volume is. Dat jij vindt dat dat 'nooit voorkomt' moet je zelf weten. Kijk naar films, images, etc., die zijn meerdere gigabytes groot. In hoeverre valt dat niet onder zowel 'real-world' als 'sequential read'?

HDTune dient zijn benchmark multi-queue te maken om geschikt te worden voor alle storage. Nu werkt de benchmark goed als de controller eigen technieken toepast, zoals vrijwel alle hardware RAID doen.

Dit hoort transparant voor de applicatie te zijn dus. Zonder eigen drivers ga je niet zó low-level komen dat je daar een verschil in kan maken. Het OS regelt dat allemaal voor je en dat is maar goed ook.

Wat je wilt weten is niet hoe je storage op kunstmatige I/O reageert die nooit voorkomt, maar wel hoe het op daadwerkelijke I/O reageert in het dagelijks gebruik. Dus voor dit doel is HDTune weinig zinvol voor de TS met Silicon Image RAID drivers.

Nee, dat is wat JIJ wilt weten. TS (en ik doorgaans ook) wil weten wat de rauwe doorvoersnelheid is en wat de seektime ongeveer is. Hiermee heb je al een ontzettend goed idee van de performance die je uit je schijven gaat krijgen. Daarna kan je nog eens gaan kijken wat voor load je denkt toe te gaan passen en daar nog eens op benchmarken maar ik denk dat we dan allang voorbij het punt van goedkope raidcontrollertjes zijn gekomen.

[Ventieldopje]

Probleem is de x1 bus, net mijn controller in een 2.0 x1 bus gedrukt en kom nu ook niet boven de 150MB/s uit

[Anoniem: 388209]

Zal ik nu een ssd aanschaffen of een goede controller?

[_H_G_]

Anoniem: 388209 schreef op woensdag 22 december 2010 @ 19:25:
Zal ik nu een ssd aanschaffen of een goede controller?

Ah, zie nu ook dat het een short-stroke test was. Ik vind de 30% cpu tijd (en de 2e schijf) nog wel vreemd, al gebruik ik geen HDTune.

Over je vraag, zou ik zeggen een SSD (op korte of lange termijn). Het is dan wel van belang wat je wil bereiken. Als je snel wil booten en een soepel OS wil dan gaat een RAID niet veel helpen: een verdubbeling van je IOPS komt nog lang niet in de buurt van een goede SSD. Een goede raid-kaart komt wat meer in de buurt, maar da's naar mijn mening een slechte investering t.o.v. een SSD.

Verder raad ik het SSD aanschaf topic aan. Het is wel reusachtig, daar het nog niet zo gemakkelijk is: de algemene verwachting is dat er nog een flinke prijsdaling aan komt. Mede door nieuwe modellen van Intel en de inhaalslag van de concurrentie.

[Anoniem: 388209]

Die cpu load is inderdaad vreemd er lopen verder geen processen op die schijf.

Het is inderdaad mijn bedoeling een snelle boot device te hebben, daarna kan ik altijd nog de twee schijven die ik nu heb alsnog RAID zetten, weliswaar met een betere controller.

Toch nog even terugkomend op die DC-300e controller, hij haalde met die setup wel 127MB/s en dat met windows 7 draaiende. Mag ik aannemen wanneer ik diezelfde configuratie gebruik voor alleen opslag, er mogelijk hogere waarde worden behaald? Of is die 127MB/s de max voor die configuratie en heeft een al dan niet installatie van Windows daar geen positieve invloed op?

Met inachtneming van enkele topics hier ga ik me oriënteren wat betreft ssd.

[Anoniem: 388209]

Nog een benchmark ich10 SATA AHCI:



Volgens mij geen slechte prestatie. Schijven zullen dus wel goed zijn. Controller is gewoon ruk, maar dat wisten we eigenlijk al.

[Anoniem: 15758]

DataGhost schreef op woensdag 22 december 2010 @ 18:07:
[...]

Kan je dat toelichten? Ik ga hier uit van de fysieke en mechanische eigenschappen van een harde schijf om tot een conclusie te komen, namelijk de conclusie dat er een bottleneck is die niet de schijf is. Read-ahead heeft hier niks mee te maken. Toegegeven, de schijf wordt niet in zijn geheel gelezen maar er wordt op bepaalde punten op de schijf een meting over een klein gebied gedaan. Read-ahead zou dus een verschil *kunnen* maken maar dat zou betekenen dat je pauzes tussen het lezen van blokken moet gaan inlassen, anders is er geen tijd om vooruit te lezen. Dan nog, controller of wat dan ook heeft echter compleet geen vermoeden van *waar precies* het volgende blok gelezen moet worden. Er kan dus simpelweg niet vooruit gelezen worden.

Read-ahead is al zo'n oud begrip; het wordt overal in gebruikt:
- Hardware RAID en sommige software RAID implementaties
- alle filesystems inclusief FAT12/16/32
- HDDs zo oud als ik me kan herinneren (1GB+)

Zonder read-ahead kunnen je hardeschijven niet meer dan één sector per rotatie (rpm) lezen; dus 5400rpm komt neer op 2.6MB/s. Voor schrijven is een soortgelijk mechanisme aanwezig: write buffering; zonder de write buffer schrijf je tegen bizar lage snelheden. Dit kun je handmatig uitzetten maar read-ahead valt niet uit te schakelen.

Dus HDDs en SSDs en eigenlijk alles gebruikt al read-ahead, afzonderlijk van het filesystem. Dat werkt zo: als twee I/O's aaneensluitend zijn, oftewel contiguous, dan kan de firmware van de HDD al vermoeden dat de volgende block misschien ook wel opgevraagd zal worden; dat gebeurt continu voor alle sequentiële I/O. Technisch gezegd: I/O is sequentiëel wanneer de LBA contiguous is.

Nu heb je dus read-ahead in je filesystem, in je HDD/SSD en mogelijk ook je RAID engine, als je hardware RAID gebruikt met name. Als je je filesystem omzeilt en ruwe I/O met queue depth 1 gaat doen, ga je dus verschil zien tussen een normale losse disk, een hardware RAID engine met firmware-eigen read-ahead en silicon image fakeRAID zonder read-ahead.

Wanneer je met queue depth =1 leest of schrijft van silicon image, zullen niet beide schijven tegelijkertijd kunnen werken. Daarvoor heb je minimaal queue depth = 2 nodig, en liefst nog hoger. Dit effect kun je ook zien bij het benchmarken van SSDs; de random read qd=1 is zo'n 10 keer lager dan de qd=32 score, omdat een SSDs tot 10 kanalen heeft en dus als een 10-disk RAID0 gedraagt; dat betekent ook minimaal een queue depth van 10 (en liefst nog hoger; ze worden immers niet ideaal verspreid) om de max performance te halen. Elke moderne SSD is dus een RAID0 array met identieke eigenschappen als een normale RAID0 met single-channel SSDs (nu zeldzaam; Transcend en dat soort meuk)

Zou je dan trouwens niet *juist* een kromme grafiek verwachten, gezien een schijf tegen het einde langzamer is dan tegen het begin? Er kan immers in dezelfde tijd (want die is elke meting constant) minder data gelezen worden en er wordt niet alvast vooruitgelezen...

Het zaagtand patroon ('sawtooth pattern') is een teken dat er striping wordt toegepast met onvoldoende queue depth; het web staat bol met voorbeelden hiervan.

Aangezien 'iedereen' NTFS gebruikt zie ik niet waarom niet iedereen dan grote problemen zou hebben hiermee en waarom andere mensen andere resultaten krijgen met HD Tune.

Hoezo 'grote problemen hebben'? Als je NTFS filesystem je de juiste RAID0 performance geeft, maar alleen een primitieve hobby-benchmark je incorrecte resultaten geeft, hoe verhoudt zich dat tot grote problemen?

Zoals uitgelegd hangt het af van je RAID engine of je in HDTune dezelfde/identieke resultaten haalt als met andere benchmarks, dan implementeert de RAID zelf read-ahead en/of write-back buffering. Als je RAID engine dat niet doet, zoals deze silicon image, dan krijg je dus lagere resultaten dan je échte programma's halen, en zijn je resultaten bovendien niet te vergelijken met andere HDTune resultaten.

Wat is de weerstand tegen échte benchmarks die op je filesystem testen net zoals alle echte programma's dat doen? Dat is uiteindelijk wat je wilt meten, toch?

Hee, ik heb wel globaal een idee van hoe het werkt hoor. Je filesystem doet helemaal niks, je OS past iets toe. Je kan perfect een implementatie van een NTFS-driver en/of kernel maken die geen read-ahead en ook geen write buffering toepassen.

Ik denk dat je geen flauw benul hebt van read-ahead en I/O performance in het algemeen. Misschien kun je eens beginnen door de HDD write buffer uit te schakelen, en genieten van single digit doorvoersnelheden. Probeer dat zelf eens te verklaren waarom een HDD maar zo langzaam kan schrijven als het niet aan buffering kan doen. Voor caching (reads) geldt natuurlijk precies hetzelfde. Als je voor elke I/O een rotatie moet maken ipv de leeskop continu aan het werk houden, gaat dat enorm schelen in de I/O performance.

Ik kan nog wel vier pagina's schrijven over dit onderwerp, maar laat dan eerst maar eens zien dat je echt geïnteresseerd bent en je huiswerk gedaan hebt.

[DataGhost]

Maar je kan met 1 commando tot 32MB (nouja, 64Ki sectors dus met deze schijven 256MB als de controller het ondersteunt) ophalen... waar blijft die queue van je dan precies? Denk je serieus dat voor elke sector een apart commando wordt gegeven? Behalve TFTP ken ik eigenlijk geen dataoverdrachtsprotocol dat nog zo werkt.

Anoniem: 15758 schreef op woensdag 22 december 2010 @ 21:28:
[...]
Read-ahead is al zo'n oud begrip;

Zonder read-ahead kunnen je hardeschijven niet meer dan één sector per rotatie (rpm) lezen; dus 5400rpm komt neer op 2.6MB/s. Voor schrijven is een soortgelijk mechanisme aanwezig: write buffering; zonder de write buffer schrijf je tegen bizar lage snelheden. Dit kun je handmatig uitzetten maar read-ahead valt niet uit te schakelen.

Dat bedoelde ik dus niet zo. Anyway, hoe verklaar je dan met 7200rpm * 512B4096B (vooruit dan) * 2schijven = 28.8 MB/min = 492 KiB/s een leessnelheid van ruim 100 MB/s?

Hoezo 'grote problemen hebben'? Als je NTFS filesystem je de juiste RAID0 performance geeft, maar alleen een primitieve hobby-benchmark je incorrecte resultaten geeft, hoe verhoudt zich dat tot grote problemen?

Aangezien jij stelt dat het filesystem juist de issue is? Dat zou, lijkt me, dan betekenen dat meer mensen er last van zouden hebben?

Zoals uitgelegd hangt het af van je RAID engine of je in HDTune dezelfde/identieke resultaten haalt als met andere benchmarks, dan implementeert de RAID zelf read-ahead en/of write-back buffering. Als je RAID engine dat niet doet, zoals deze silicon image, dan krijg je dus lagere resultaten dan je échte programma's halen, en zijn je resultaten bovendien niet te vergelijken met andere HDTune resultaten.

Dus échte programma's hebben zelfgeschreven RAID-drivers aan boord? Of waar praten ze dan precies tegen?

Wat is de weerstand tegen échte benchmarks die op je filesystem testen net zoals alle echte programma's dat doen? Dat is uiteindelijk wat je wilt meten, toch?

Omdat ik een vergelijking wil kunnen maken, onafhankelijk van factoren die weer kunnen veranderen, zoals bijvoorbeeld filesystems ja.

Ik denk dat je geen flauw benul hebt van read-ahead en I/O performance in het algemeen.
[...]
Ik kan nog wel vier pagina's schrijven over dit onderwerp, maar laat dan eerst maar eens zien dat je echt geïnteresseerd bent en je huiswerk gedaan hebt.

Okee.

[Anoniem: 15758]

DataGhost schreef op woensdag 22 december 2010 @ 22:06:
Maar je kan met 1 commando tot 32MB (nouja, 64Ki sectors dus met deze schijven 256MB als de controller het ondersteunt) ophalen... waar blijft die queue van je dan precies? Denk je serieus dat voor elke sector een apart commando wordt gegeven? Behalve TFTP ken ik eigenlijk geen dataoverdrachtsprotocol dat nog zo werkt.

Nee dat klopt, maar om het simpel te houden; het is al ingewikkeld genoeg.

Request sizes zijn doorgaans gelimiteerd tot 128KiB. Dus als je een 32 kilobyte bestand inleest is de request size ook 32KiB; één I/O request voor de hele file. Als een file heel groot is (zeg 1GB; maar eigenlijk alles boven de 128KiB) zullen er meerdere requests worden gestuurd; meestal zijn die 128KiB groot. Echter Windows 7 net als sommige OSen heeft nu de mogelijkheid grotere requests te gebruiken; echt nuttig is dit niet 128KiB werkt al vrij efficient.

Oke dus als je 1GB bestand inleest, dan gebruikt je filesystem blokken van 128KiB om dat in te lezen. Waar blijft de queue depth dan precies? Nou simpelweg door meerdere requests tegelijkertijd te sturen. Dus 8 requests van elk 128KiB betekent dus 1 megabyte read-ahead, terwijl je requests 128KiB groot zijn.

Terug naar HDtune: die doet tot 1 megabyte requests, maar altijd met queue depth =1, je zult dus heel grote request size moeten gebruiken om een 'normale' queue depth te simuleren: 1 megabyte blocksize komt overeen met 128KiB request size met queue depth = 8.

Wat Queue Depth doet met I/O performance, doet TCP Receive Window met netwerk performance; die twee technieken zijn vrijwel identiek. Als je TCP Receive Window begrijpt, dan begrijp je Queue Depth veel makkelijker. Hier is een prachtig voorbeeld wat laat zien hoe hardware zonder werk komt te zitten en hoe queueing dit verhelpt, een animated GIF dus zeker kijken:
http://cable-dsl.navasgroup.com/rwinanim.htm

Dat bedoelde ik dus niet zo. Anyway, hoe verklaar je dan met 7200rpm * 512B4096B (vooruit dan) * 2schijven = 28.8 MB/min = 492 KiB/s een leessnelheid van ruim 100 MB/s?

Je hebt gelijk ik maak een fout met mn berekening.

7200rpm = 7200/60 = 120 toeren per seconde = 120 IOps als er voor elke I/O één rotatie nodig is, waar we voor het gemak even vanuit gaan. Als je 128KiB request size gebruikt kom je dan op snelheden van 128 * 120 = 15MiB/s. Ga je kleine bestanden lezen en houd je het op 4KiB request size, kom je nog niet verder dan 0.5MB/s en met 512-byte requests slechts een achtste daarvan.

Het hele idee van queue depth, read-ahead en write buffering is dat het mechanische gedeelte van de HDD bezig blijft: een hardeschijf is heel snel in het overpompen van data (sequential I/O) maar heel langzaam in het zoeken van data (access time). Dus ideaal gezien wil je alleen maar sequential I/O doen en de leeskop nooit op laten houden: dan lees/schrijf je tegen de hoogst mogelijke snelheid en dan zijn HDDs vrijwel even snel als SSDs.

Queue depth is ook cruciaal om RAID0 te laten schalen. Voor een 2-disk RAID0 heb je minimaal twee I/O's op hetzelfde moment nodig om beide schijven aan een aparte I/O te laten werken, om aldus een 100% performance scaling te behalen. Met queue depth = 1 kun je maximaal 1 schijf tegelijkertijd aan het werk zetten in een striping RAID. Merk op dat hier veel uitzonderingen op zijn, maar geen van allen zijn echt belangrijk om te onthouden.

Aangezien jij stelt dat het filesystem juist de issue is? Dat zou, lijkt me, dan betekenen dat meer mensen er last van zouden hebben?

Het is jammer dat we elkaar nog niet begrijpen. Ik stel juist dat er helemaal geen probleem is: het filesystem levert hogere performance op RAID0 dan HDtune kan meten afhankelijk van de gebruikte RAID controller. Dus de enige 'issue' is dat HDtune te lage scores aangeeft en de daadwerkelijke performance hoger ligt. De Silicon Image FakeRAID drivers zijn nog steeds niet echt goed, maar de 'issue' hier is vooral dat TS vooral denkt dat zijn performance heel laag is, omdat HDtune zijn type RAID engine niet goed kan testen. Goed in de zin van: het nabootsen van realistisch gebruik.

Dus even stel andere benchmarks geven 200MB/s aan en HDTune maar 100MB/s; wat is dan het probleem? Als je echt bestanden gaat inlezen/schrijven gaat dat met 200MB/s omdat ALLES via het filesystem gaat; behalve kunstmatige benchmarks zoals IOmeter, HDTune en HDTach. Als je ruwe I/O doet moet je goed weten wat je doet anders weet je niet meer wat de score die je krijgt precies inhoudt; wát ben je precies aan het testen als je HDTune draait op silicon image RAID? Welke vraag beantwoord die scores? Geen naar mijn mening.

Dus échte programma's hebben zelfgeschreven RAID-drivers aan boord? Of waar praten ze dan precies tegen?

Programma's weten natuurlijk niets van RAID; enige wat ze 'weten' zijn API-calls om het NTFS filesystem te gebruiken om bestanden te lezen/schrijven; en hebben daarbij de keuze tussen blocking I/O en non-blocking I/O; cruciaal voor schalen van RAID0 en houdt ook groot verband met queue depth; allemaal voor een andere dag.

Dus een programma vraagt aan meneer NTFS "ik wil die file lezen". NTFS kijkt naar de file, ziet dat hij lekker groot is en stuurt gelijk 8 requests van 128KiB naar de RAID driver, die vervolgens de requests verdeelt onder de RAID members. Doordat de RAID driver meerdere requests krijgt, komen de schijven niet zonder werk te zitten en kunnen ze tegelijkertijd werken en heeft RAID0 dus een snelheidsvoordeel.

De RAID members passen elk intern read-ahead toe, waardoor er dus dubbel read-ahead toegepast wordt: door het filesystem en de HDD/SSD zelf; dat is prima niks mis mee. In geval van een hardware RAID controller komt daar nóg een read-ahead mechanisme bij: de controller zelf. Dan krijg je dus wel hoge HDtune resultaten, maar de echte resultaten via het filesystem zullen vrijwel onveranderd blijven.

Omdat ik een vergelijking wil kunnen maken, onafhankelijk van factoren die weer kunnen veranderen, zoals bijvoorbeeld filesystems ja.

Oke dat is een geldig punt; je wilt zo 'low-level' mogelijk zitten zodat je elke keer consistente resultaten krijgt ongeacht fragmentatie en locatie van vrije ruimte op je filesystem. Als je een volume test dat 40% vol zit, test je niet meer de snelste gedeeltes van je hardeschijf; terwijl je met HDtune wel het begin en eind kan zien van je HDD en dus meer informatie hebt; oke als dat je punt is heb je hier wel een argument.

Maar als je dan HDtune gebruikt, zet dan de blocksize zo hoog mogelijk; dan simuleer je gewoon een hogere queue depth en krijg je wel een redelijk resultaat.

Okee.

Sorry als ik niet zo aardig klonk. Het punt is meer: deze materie is redelijk ingewikkeld en ik merkte dat je op sommige punten nog niet voldoende basiskennis hebt over hoe I/O werkt. Dat maakt het ietwat frustrerend om deze zeer theoretische zaken uit te leggen; sommige dingen leer je het beste door het zelf te doen, zelf te zien, zelf te ervaren.

Pas als je RAID0 door en door begrijpt, heb je een redelijk idee van I/O performance. Dan kun je meer verborgen dingen proberen te begrijpen, bijvoorbeeld waarom SSDs hetzelfde principe als RAID0 gebruiken en krijg je veel meer beoordelingsvermogen om een bepaalde benchmark op zijn waarde te schatten. Maar al te vaak worden er benchmarks gedraaid waarbij onduidelijk is wat de getallen voorstellen; ook bij reputabele reviewsites.

Als je dit nou interessant vindt: waarom ga je niet eens wat kloten met software RAID0 onder Linux of BSD? Uitstekend om dit allemaal te leren; zet een I/O monitor aan en kijk wat er gebeurt, waar gaat je I/O naartoe en hoe gedraagt een filesystem zich. Hoe verhoudt ruwe I/O zich tot buffered I/O (met hogere queue depth), etc.

Ik wil er best meer over schrijven; ik snap dat je nog veel vragen hebt. Maar misschien is het beter dat in een apart topic te doen? Dat laat ik aan jou over; mocht je daartoe besluiten dan zal ik ook de moeite nemen mijn vergaarde kennis met je te delen.

[Anoniem: 388209]

Als ik even tussen beide mag komen , ik ga morgen deze ssd aanschaffen: OCZ OCZSSD3-2VTX120G. Ik zou graag wat feedback willen krijgen omtrent deze ssd?

[Anoniem: 15758]

Anoniem: 388209 schreef op donderdag 23 december 2010 @ 00:25:
Als ik even tussen beide mag komen

Nou vooruit dan.

Standaard Sandforce 2 model; 120GB van de 128GiB totaal. Niet zo heel veel spare space, maar een heel goede allround keuze op dit moment. Erg populair, goed verkrijgbaar en scherp geprijst.

Zelf zou ik nog een paar maandjes wachten; over een aantal weken komt de nieuwe lading SSDs van de derde generatie. Sandforce SF1500/2000, Marvell C400, Intel G3; zijn allemaal een redelijk grote verbetering ten opzichte van oudere generatie SSDs op tal van punten, voornamelijk betrouwbaarheid (UBER) en performance. Ook de prijs van de nieuwe SSDs zal relatief laag liggen, en de bestaande 2e generatie SSDs verder in prijs doen dalen.

Als je nog even geduld hebt, is het beste advies misschien nog even de kat uit de boom te kijken. 2011 Q1 zou een mooi kwartaal moeten worden voor de potentiële SSD koper.

[ Voor 9% gewijzigd door Anoniem: 15758 op 23-12-2010 01:13 ]

[Alfa Novanta]

@N4vy: hint: pricewatch: Dawicontrol DC-300e RAID (2x SATA300 RAID, PCI-e x1)

[Anoniem: 388209]

Been there, done that..

Vanmiddag een ssd halen, zit alleen te twijfelen of ik die dc-300e nu terug breng of deze alsnog daarnaast ga gebruiken.

[Anoniem: 388209]

Een van de onderstaande gaat het worden, echter kan ik niet achterhalen wat, op grootte na, de verschillen zijn en wat de dus de beste keuze is.

Solid State Drive 2,5 inch SATA
(Art.-Nr.: IMGMNT)
OCZSSD2-2VTXE60G (60 GB)

Solid State Drive 2,5 inch SATA
(Art.-Nr.: IMHMNB06)
OCZSSD2-2VTXE90G (90 GB)

Solid State Drive 2,5 inch SATA
(Art.-Nr.: IMHMNT)
OCZSSD2-2VTXE120G (120 GB)

Solid State Drive 2,5 inch SATA
(Art.-Nr.: IMHMNS)
OCZSSD2-2AGTE120G (120 GB)

[dvl-2]

De eerste 3 zijn uit de Vertex 2 serie en de laatste is uit de Agility serie die over het algemeen iets trager is. Ik zou dus sowieso voor 1 van de eerste 3 gaan. Deze disks zijn nagenoeg identiek op de grootte na. Doordat de kleinere versies minder geheugenchips hebben zijn de schrijfprestaties van kleinere ssd's over het algemeen ook iets minder. Dat wil niet zeggen dat een 120GB 2x zo snel is als een 60GB maar sneller is hij wel. Leesperformance is eigenlijk altijd gelijk. Aangezien SSD's vrij prijzig zijn zou ik eerst kijken van 'hoeveel GB heb ik nodig als OS-schijf' en daarop een keuze maken. Zelf heb ik de 100Gb vertex 2 (ben zo lui geweest hm nog niet te flashen naar 120GB) en ervaar dat als 'precies genoeg'. 90GB zou opzich ook kunnen maar 60GB is wel weer wat klein imo. Optie is natuurlijk 2x60GB in raid0 te zetten maar tov een 120GB is dat niet merkbaar sneller (in benchmarks wel).. opstarttijd is dan mss ipv 0,05sec 0,04sec.. Niet merkbaar voor jou maar in praktijk wel 20% sneller ;-)

Lang verhaal kort te maken, kies de 90 of 120GB afhankelijk van wat je nodig hebt.

[Anoniem: 388209]

Bedankt voor de input. 60GB zal niet voldoende zijn inderdaad, snelle drive is leuk, maar als ik steeds moet oppassen met hetgeen ik wil installeren, is de lol daar snel van af. Tussen de 90GB en 120GB variant is het prijsverschil eigenlijk ook niet noemenswaardig en kan ik beter voor de 120GB variant gaan.

Even terugkomend op mijn voormalige RAID 0 configuratie, schijf-indexering was actief met als logisch gevolg een enorme dip in de grafiek alsmede een zeer hoge cpu load. Schijf-indexering heb ik op alle schijven uitgeschakeld en nu behalen beide schijven dezelfde performance.

Wanneer vanmiddag de ssd is geïnstalleerd zal ik nogmaals de WD's in RAID 0 configureren met de dc-300e controller en dan uiteraard niet als boot device en geen actieve schijf-indexering. Kijken wat dat doet. Mocht die setup geen 140MB/s sequentiële schrijf/lees snelheden halen dan gaat die controller terug. De hogere schrijf/lees snelheden wegen dan niet op tegen de fors toegenomen toegangstijd, wel? Of is de toegangstijd niet essentieel voor opslag van relatief grote bestanden?

[ Voor 7% gewijzigd door Anoniem: 388209 op 23-12-2010 13:53 ]

[Anoniem: 388209]

Anoniem: 15758 schreef op donderdag 23 december 2010 @ 01:12:
[...]

Nou vooruit dan.

Standaard Sandforce 2 model; 120GB van de 128GiB totaal. Niet zo heel veel spare space, maar een heel goede allround keuze op dit moment. Erg populair, goed verkrijgbaar en scherp geprijst.

Zelf zou ik nog een paar maandjes wachten; over een aantal weken komt de nieuwe lading SSDs van de derde generatie. Sandforce SF1500/2000, Marvell C400, Intel G3; zijn allemaal een redelijk grote verbetering ten opzichte van oudere generatie SSDs op tal van punten, voornamelijk betrouwbaarheid (UBER) en performance. Ook de prijs van de nieuwe SSDs zal relatief laag liggen, en de bestaande 2e generatie SSDs verder in prijs doen dalen.

Als je nog even geduld hebt, is het beste advies misschien nog even de kat uit de boom te kijken. 2011 Q1 zou een mooi kwartaal moeten worden voor de potentiële SSD koper.

Geduld is waar het aan ontbreekt..

[Ventieldopje]

N4vy, een kleine tip om het leesbaar te houden hier, zou je misschien als je als laatste reageert en je wil nog een keer reageren misschien gewoon je laatste post aan willen passen? Zie nu heel vaak 2 posts van je achter elkaar.

[Anoniem: 388209]

Ja klopt excuus, zal er op letten.

[Anoniem: 388209]

Zo weer even een update.

Vanmiddag een OCZ Vertex 2 120GB aangeschaft en geïnstalleerd. Daarnaast heb ik de WD schijven RAID 0 geconfigureerd middels de 'welbesproken' DC-300e controller.

Installeren van de ssd is een fluitje van een cent, de ssd wordt direct herkend door BIOS. Tijdens de Windows 7 installatie merkte ik al een significante snelheidswinst. Het opstarten van Windows 7 gaat een stuk rapper en alles staat direct geladen op het bureaublad. Nu kan ik me verder verdiepen in het tweaken van deze ssd, om tot nog betere prestaties te komen.

Gelijk een benchmark uitgevoerd en ik kan u zeggen dat ik daar vrolijk van word:




Ik kon het toch niet laten om de DC-300e nog even te proberen in een niet boot device configuratie. De prestaties zijn niet enorm dat had ik ook niet verwacht. Toch loopt het nu een stuk beter. Na 3 verschillende configuratie te hebben onderworpen aan benchmark, kan ik stellen dat dit toch de meest effectieve configuratie is, als het gaat om opslag van relatief grote bestanden.

Hieronder de cijfers van 2x WD10EARS / DC-300e RAID 0:

[Ventieldopje]

Anoniem: 388209 schreef op donderdag 23 december 2010 @ 15:42:
Ja klopt excuus, zal er op letten.

Anoniem: 388209 schreef op donderdag 23 december 2010 @ 23:52:

...

Nu doe je het weer

[Anoniem: 388209]

Modbreak:

Inmiddels ook een opmerking van mijn kant per PM verzonden, met betrekking tot de edit knop.

[ Voor 109% gewijzigd door _Dune_ op 24-12-2010 13:48 ]

[Anoniem: 356920]

WD10EARS wordt door WD afgeraden om in RAID opstelling te gebruiken, en de ervaringen zijn inderdaad nefast te noemen.

http://community.wdc.com/...-0-stripe-Array/td-p/8605

Ik heb daarom deze in RAID 0 draaien, http://tweakers.net/price...1fals-1tb.html#tab:prices en dat loopt al vele maanden als trein.

Transfer Rate Minimum : 99.9 MB/sec
Transfer Rate Maximum : 214.6 MB/sec
Transfer Rate Average : 172.6 MB/sec
Access Time : 10.6 ms
Burst Rate : 635.2 MB/sec
CPU Usage : -1.0%

[Alfa Novanta]

Anoniem: 388209 schreef op donderdag 23 december 2010 @ 23:52:
Zo weer even een update.

Vanmiddag een OCZ Vertex 2 120GB aangeschaft en geïnstalleerd. Daarnaast heb ik de WD schijven RAID 0 geconfigureerd middels de 'welbesproken' DC-300e controller.

[...]

Gelijk een benchmark uitgevoerd en ik kan u zeggen dat ik daar vrolijk van word:

[afbeelding]


Ik kon het toch niet laten om de DC-300e nog even te proberen in een niet boot device configuratie. De prestaties zijn niet enorm dat had ik ook niet verwacht. Toch loopt het nu een stuk beter. Na 3 verschillende configuratie te hebben onderworpen aan benchmark, kan ik stellen dat dit toch de meest effectieve configuratie is, als het gaat om opslag van relatief grote bestanden.

Hieronder de cijfers van 2x WD10EARS / DC-300e RAID 0:

[afbeelding]

Feli ! Ziet er goed en zeer werkbaar uit!
Die schrijfsnelheden zijn niet verkeerd heej

/me zelf een Intel Postville 80GB X25-M heeftvoor OS

[Madrox]

Anoniem: 388209 schreef op dinsdag 21 december 2010 @ 13:36:
Ik heb net de Silicon image drivers verwijderd, computer opnieuw gestart, nu wordt hij herkend als dc-300e stripe set 0 2000gb. Maar helaas geen verschil in prestaties.

Tijdens het configureren van de RAID setup kon ik een bronblock grootte instellen. 32 - 64 - 128, hier heb ik gekozen voor 128. Eigenlijk geen idee wat voor een functie dat heeft?

Ja, dat zijn Kb's. Als je dus 32 kiest, gaat je controller je bestanden on blokjes hakken van 32kb, en zet die om en om op je twee harddisks , hence RAID-0
bij 128, je raad het al, worden dat blokjes van 128Kb
Voordeel van grote blokken merk je vooral als je met veel grote bestanden werkt op zo'n array; denk aan videobestanden etc. Kleine blokken doen het juist weer goed bij kleine bestanden, denk aan je OS files, IE cache etc.etc.

64Kb is doorgaans "de standaard" , die doet alles een beetje goed. Wil je juist performance voor grote of kleine bestanden, kan je daar je controller op afstellen. Zo doe ik 512Kb blokken (ivm met veel film materiaal) met 6 harddisks. Iig maakt de stripesize niet zo'n groot verschil, je slechte scores hebben dan ook zeer waarschijnlijk niets met de stripesize van doen maar helaas alles met de matige controller.

Heb in het verleden ook een Dawi controller gehad en die viel ook al tegen. De Highpoint RR2680 die ik nu heb, voldoet behoorlijk. De beste controllers hebben naast een eigen cpu ook cache, die cache geeft nog eens een flinke boost; helaas zijn die controllers beboorlijk aan de prijs; ondanks de lage prijs van geheugen tegenwoordig.


Let wel, dit is RAID-5. Vandaar de wat lagere scores bij schrijven
Zoals je ziet, ben ik met grote bestanden net zo snel, zoniet sneller als een goede SSD. Dan heb je wel een veelvoud aan opslag capaciteit.

[ Voor 24% gewijzigd door Madrox op 24-12-2010 18:18 ]

[Anoniem: 388209]

Dat zijn inderdaad mooie resultaten. Lezen gaat zo te zien sneller dan bij een gemiddelde ssd. Alleen is het niet zo dat de toegangstijd behoorlijk hoog wordt in RAID? Volgens mij heeft men met een ssd mede zoveel winst door de lage toegangstijd, zeker wanneer de drive als boot device wordt gebruikt, niet waar?

Desalniettemin, zal ik op korte termijn een betere controller aanschaffen. Eerst even kijken hoe deze configuratie stand houdt, gezien de slechte berichtgeving wat betreft de stabiliteit van deze WDs in RAID.

[ Voor 5% gewijzigd door Anoniem: 388209 op 25-12-2010 00:13 ]

[Anoniem: 15758]

Madrox schreef op vrijdag 24 december 2010 @ 18:08:
[...]

Ja, dat zijn Kb's. Als je dus 32 kiest, gaat je controller je bestanden on blokjes hakken van 32kb, en zet die om en om op je twee harddisks , hence RAID-0
bij 128, je raad het al, worden dat blokjes van 128Kb
Voordeel van grote blokken merk je vooral als je met veel grote bestanden werkt op zo'n array; denk aan videobestanden etc. Kleine blokken doen het juist weer goed bij kleine bestanden, denk aan je OS files, IE cache etc.etc.

Dat is dus een veelgehoord misverstand.

Een grote stripesize is met name goed voor random I/O; IOps performance.
Een lage stripesize is met name goed voor sequential I/O; wanneer je grote bestanden inleest of wegschrijft. Dit heeft te maken met de queue depth voor random IOps die doorgaans heel laag is, en het feit dat je niet twee schijven aan één I/O wilt laten werken. Door de stripesize groot genoeg te laten maken, zal het performanceverlies doordat twee hardeschijven aan één I/O moeten werken steeds lager worden; hoe groter de stripesize des te beter de IOps performance. Ergens bij 1MiB of 10 megabyte zie je verzadiging optreden.

Echter, je zult een hoge queue depth nodig hebben om met een 10Megabyte stripesize nog steeds voordeel te halen bij het lezen/schrijven van grote bestanden; dus hier kan een grote stripesize dus voordelig zijn voor IOps maar nadeling voor sequential I/O bij het lezen/schrijven van grote bestanden.

Anoniem: 356920 schreef op vrijdag 24 december 2010 @ 12:51:
WD10EARS wordt door WD afgeraden om in RAID opstelling te gebruiken, en de ervaringen zijn inderdaad nefast te noemen.

Ja natuurlijk; ze willen veel liever dat je hun RAID edition HDDs gebruiken; fysiek precies hetzelfde maar met wat firmware tweaks en huppa, 25 euro extra cash voor de HDD makers.

Je WD Black is evengoed 'ongeschikt' voor RAID. Het probleem is dat hardware RAID en Windows onboard RAID schijven die error recovery doen, uit de array flikkeren in plaats van even rustig te wachten. Dus het probleem is eerder de hardware RAID controllers en fakeRAID software onder Windows die veels te streng omgaat met je schijven.

Onder Linux/BSD met software RAID werken normale schijven dus prima, maar onder Hardware RAID en Windows onboard RAID heb je dus schijven nodig die maximaal 7 seconden recovery doen; want na 10 seconden wordt de HDD uit de array geflikkerd. Of dat nou een green of black schijf is, doet er niet toe. Schijven met 4K sectors zouden een klein voordeel moeten hebben (meer ECC per sector).

Dus het is een flinke industrie geworden om klanten te laten betalen voor een workaround/bugfix; best een vreemde gang van zaken moet ik zeggen maar nog steeds actueel.