extra raptor, of extra 500GB?

[Mr Alfabet]

ik heb onlangs een 12 poorts Areca aangeschaft, en aangezien ik van een 8 poorts controller afkom, heb ik dus nog 4 vrije poorten.

dit is wat ik nu heb: (speeds gemeten met hdtune)
3x 36GB raptor, raid0, 300MBps max, 225MBps average, 8.3ms access time
5x 500GB samsung, raid5, 315MBps max, 245MBps average, 30ms access time

wat ik me eigenlijk afvroeg was hoeveel snelheidswinst er nog valt te halen met een 4e raptor.
de opties zijn dus:
4x raptor, 8x 500GB in raid5
3x raptor, 9x 500GB in raid5

aangezien de prijzen van beide soorten schijven nagenoeg gelijk zijn, is dat niet echt een punt van discussie.

ik heb al lopen zoeken in de tweakers benchmarks, maar daar is weinig vergelijkingsmateriaal te vinden tussen 3 en 4 raptors op een areca controller (onboard met areca vergelijken is niet echt realistisch)

wat voor mij belangrijk is: snelle windows (lage accesstimes) en een snelle apps startup.
kan iemand een beetje voorspellen hoe hard mijn raid0 erop vooruitgaat? en of het opweegt tegen 3.5 vs 4 TB.

[TheGhost]

Denk niet dat 1 schijf extra 't verschil zal maken wbt snelheid. En of je de ruimte nodig hebt kun je 't beste zelf bepalen natuurlijk... wat voor systeem praten we eigenlijk over? is dit voor een server (lijkt me bijna van wel, maar je weet 't soms niet he...)

[Andros]

Zeg vriend, als het je om accesstimes gaat, waarom heb je die raptors dan in godsnaam in raid staan? Als iets de accesstimes van die dingen verpest is het raid0 wel, een raptor heb daar geen fluit aan...

[Mr Alfabet]

lowrider schreef op woensdag 24 oktober 2007 @ 13:09:
Denk niet dat 1 schijf extra 't verschil zal maken wbt snelheid. En of je de ruimte nodig hebt kun je 't beste zelf bepalen natuurlijk... wat voor systeem praten we eigenlijk over? is dit voor een server (lijkt me bijna van wel, maar je weet 't soms niet he...)

u think? want wat ik van raid hoor zou t allemaal gewoon op moeten tellen... vroeg me alleen af wanneer je tegen een plafon aanloopt. anders zou t 300/3 * 4 = 400MBps op moeten leveren.

systeem is gewoon mijn gaming/ download rig. (yup, hou van downloaden)

Cubefanatic schreef op woensdag 24 oktober 2007 @ 13:11:
Zeg vriend, als het je om accesstimes gaat, waarom heb je die raptors dan in godsnaam in raid staan? Als iets de accesstimes van die dingen verpest is het raid0 wel, een raptor heb daar geen fluit aan...

can you back that up? en wordt t opstarten van progs en windows niet mede bepaald door de leessnelheid van de schijven? 8.3ms vs 6ms zal lang niet zo'n verschil maken als single raptor vs raid0 met 300MBps niet?

[ Voor 29% gewijzigd door Mr Alfabet op 24-10-2007 13:17 ]

[PROnline]

Mr Alfabet schreef op woensdag 24 oktober 2007 @ 13:14:
[...]

can you back that up?

[...]

Je hebt 't over acces time. even als rekendvoorbeeld gemiddelde is 10ms met soms 5ms en soms 15. Bij raid bepaald bij elke actie de schijf die er toevallig op dat moment 't langste over doet de access time. Dus drie schijven kunnen binnen 5 - 10ms reageren en de 4e 15ms dan is het toch echt 15ms de acces time.
I.p.v. één schijf die de acces time bepaald heb je nu dus vier schijven die de resultaten bepalen waarbij de traagste waarde/schijf elke keer degene is die meeteld voor 't resultaat/gemiddelde.
In ideaalsituatie waarbij schijven synchroon lopen, dan zou de accestime vrijwel identiek kunnen zijn, maar dat is in de praktijk dus niet 't geval.

Als we spreken over rauwe doorvoer, dan wordt die inderdaad weer aanzienlijk sneller, maar die is niet enorm relevant voor de snelheid van 't opstarten van windows omdat 't hier relatief veel kleine bestandjes betreft en 'niet een enkel groot bestand.
Aanzetten vanuit hybernate is wel merkbaar, maar of 8 of 6 seconden om te starten, is dat nou zo spannend te noemen?

Je ziet 't effect trouwens goed in de accestime van de raid5. De 30ms is aanzienlijk hoger dan de accestime van een enkele schijf.

[ Voor 5% gewijzigd door PROnline op 24-10-2007 13:34 ]

[Verwijderd]

Bij raid bepaald bij elke actie de schijf die er toevallig op dat moment 't langste over doet de access time.

Onzin, 1 I/O request hoort ook door 1 schijf in de RAID-set afgehandeld te worden (reads iig).

Als we spreken over rauwe doorvoer, dan wordt die inderdaad weer aanzienlijk sneller, maar die is niet enorm relevant voor de snelheid van 't opstarten van windows omdat 't hier relatief veel kleine bestandjes betreft en 'niet een enkel groot bestand.

En jij denkt dat de verwerking van kleine bestanden TRAGER is door het gebruik van RAID0? Met andere woorden je zegt dat access time gelijk staat aan non-sequentiele performance?

Je ziet 't effect trouwens goed in de accestime van de raid5. De 30ms is aanzienlijk hoger dan de accestime van een enkele schijf.

Dat komt door stripe misalignments door het gebruik van windows partities, zodat een cluster in NTFS op twee stripe blocks kan rusten. Daarnaast verhoogt het gebruik van RAID de latency lichtjes door de extra overhead. Dat wordt echter ruimschoots goedgemaakt door een boost in IOps performance.

[Mr Alfabet]

Verwijderd schreef op woensdag 24 oktober 2007 @ 14:32:
[...]

Onzin, 1 I/O request hoort ook door 1 schijf in de RAID-set afgehandeld te worden (reads iig).

inderdaad, het is toch niet zo alsof hetzelfde bestand gelezen moet worden door 3 schijven tegelijk om opgeroepen te worden? schijf 1 doet deeltje 1, schijf 2 doet deeltje 2, elk met zijn eigen access time, anders zou schijf 1 eerst deeltje 1 doen, en daarna deeltje 2, ook met een eigen access time per deeltje

[...]

En jij denkt dat de verwerking van kleine bestanden TRAGER is door het gebruik van RAID0? Met andere woorden je zegt dat access time gelijk staat aan non-sequentiele performance?


[...]

Dat komt door stripe misalignments door het gebruik van windows partities, zodat een cluster in NTFS op twee stripe blocks kan rusten. Daarnaast verhoogt het gebruik van RAID de latency lichtjes door de extra overhead. Dat wordt echter ruimschoots goedgemaakt door een boost in IOps performance.

om niet te noemen dat niet zeker niet de snelste 7200 toeren schijven zijn (wel de stilste, vandaar)

[Verwijderd]

Mr Alfabet schreef op woensdag 24 oktober 2007 @ 14:45:
[...]

inderdaad, het is toch niet zo alsof hetzelfde bestand gelezen moet worden door 3 schijven tegelijk om opgeroepen te worden? schijf 1 doet deeltje 1, schijf 2 doet deeltje 2, elk met zijn eigen access time, anders zou schijf 1 eerst deeltje 1 doen, en daarna deeltje 2, ook met een eigen access time per deeltje

Inderdaad, behalve als iemand een verkeerde (te lage) stripesize heeft gebruikt. Stel iemand gebruikt 16KB als stripesize en Windows leest met blokjes van 64KB sequentieel, dan bepaalt de traagste schijf wel de performance; er zijn dan 4 (4x16KB=64KB) fysieke schijven nodig om 1 enkele request af te handelen. Nog erger: dankzij de stripe misalignment waarj e bij windows mee te maken hebt heb je 5 fysieke I/O requests nodig (naar de schijven toe) voor 1 virtuele I/O request (afkomstig van windows naar de RAID driver). Maargoed dit is gelukkig wel erg worst-case.

Normaal gezien hoort 1 virtuele I/O request afgehandeld te worden door 1 fysieke schijf, dan heb je de hoogste IOps performance.

om niet te noemen dat niet zeker niet de snelste 7200 toeren schijven zijn (wel de stilste, vandaar)

Sorry maar deze zin kon ik niet ontrafelen.
Maar volgens mij wilde je zeggen dat Raptors sneller dan 7200rpm desktopschijven zijn? Dat is overigens niet waar voor sequentiele performance, waar ze voorbij worden gestreefd door perpendiculaire schijven. Maar qua IOps (verreweg de belangrijkste graadmeter voor realistische performance) zeker wel stukken beter.

[ Voor 4% gewijzigd door Verwijderd op 24-10-2007 14:58 ]

[Mr Alfabet]

Verwijderd schreef op woensdag 24 oktober 2007 @ 14:57:
[...]

Inderdaad, behalve als iemand een verkeerde (te lage) stripesize heeft gebruikt. Stel iemand gebruikt 16KB als stripesize en Windows leest met blokjes van 64KB sequentieel, dan bepaalt de traagste schijf wel de performance; er zijn dan 4 (4x16KB=64KB) fysieke schijven nodig om 1 enkele request af te handelen. Nog erger: dankzij de stripe misalignment waarj e bij windows mee te maken hebt heb je 5 fysieke I/O requests nodig (naar de schijven toe) voor 1 virtuele I/O request (afkomstig van windows naar de RAID driver). Maargoed dit is gelukkig wel erg worst-case.

Normaal gezien hoort 1 virtuele I/O request afgehandeld te worden door 1 fysieke schijf, dan heb je de hoogste IOps performance.


[...]

Sorry maar deze zin kon ik niet ontrafelen.
Maar volgens mij wilde je zeggen dat Raptors sneller dan 7200rpm desktopschijven zijn? Dat is overigens niet waar voor sequentiele performance, waar ze voorbij worden gestreefd door perpendiculaire schijven. Maar qua IOps (verreweg de belangrijkste graadmeter voor realistische performance) zeker wel stukken beter.

ik vergelijk de accesstimes van de samsungs met die van de raptors, om aan te geven waarom de accestimes vanmn raid5 rond de 30ms liggen ipv de 10ms

[u_nix_we_all]

Ik hoop dat je je wel realiseert dat de kans op uitval bij een RAID0 set hoger wordt naarmate er meer schijven inzitten ? Ik vind stripen over 3 disks al redelijk onzinnig, laat staan over 4 disks. Ik vraag me af of je het verschil uberhaupt gaat merken.
Waar je wel even op moet letten, is of er een maximum is aan RAID5 schijven wat je wilt gebruiken. Het kan zo zijn dat bij teveel disks de overhead van het opdelen van de data hoger wordt dan de snelheidswinst. In dat geval kun je beter meerdere RAID5 sets maken, maar dat kost weer overhead in de vorm van capaciteit.

[Mr Alfabet]

u_nix_we_all schreef op woensdag 24 oktober 2007 @ 15:10:
Ik hoop dat je je wel realiseert dat de kans op uitval bij een RAID0 set hoger wordt naarmate er meer schijven inzitten ? Ik vind stripen over 3 disks al redelijk onzinnig, laat staan over 4 disks. Ik vraag me af of je het verschil uberhaupt gaat merken.
Waar je wel even op moet letten, is of er een maximum is aan RAID5 schijven wat je wilt gebruiken. Het kan zo zijn dat bij teveel disks de overhead van het opdelen van de data hoger wordt dan de snelheidswinst. In dat geval kun je beter meerdere RAID5 sets maken, maar dat kost weer overhead in de vorm van capaciteit.

de raid5 gaat me niet om de snelheid, zolang die 300MBps+ is. en de raid0 zou puur voor de snelheid zijn als OS array die regelmatig gebackupped wordt. vraag is dus wat is de snelheidswinst op die raid0 met n extra disk.

[Verwijderd]

@ je post ervoor
Mja maar het punt is dat access time niet zo heel veel zegt over de performance. Het is een erg synthetische specificatie die een heleboel factoren totaal verwaarloost. Bijvoorbeeld: RAID is sterk in het tegelijk uitvoeren van meerdere I/O request, access time werkt echter alleen met één request, en is een interne spec van de fysieke hardeschijf. Je kunt harddisk performance nu eenmaal niet in 1 cijfer uitdrukken, helaas. Dat gaat voor bijna alle hardware op trouwens.

@ je laatste post
Als je meer snelheid verlangt van RAID0 dan kun je daar idd schijven bijlpaatsen. Als je RAID5-set niet voor de snelheid is, heeft schijven bijplaatsen niet zoveel zin (wat wil je daarmee bereiken dan? ruimte erbij?). Bedenk wel dat raptors dure schijven zijn, zeker qua prijs per gigabyte. Bedenk dus heoveel geld je wilt uitgeven voor wat extra performance. Heb je write-back ingeschakeld?

[ Voor 31% gewijzigd door Verwijderd op 24-10-2007 15:21 ]

[Mr Alfabet]

Verwijderd schreef op woensdag 24 oktober 2007 @ 15:14:
@ je post ervoor
Mja maar het punt is dat access time niet zo heel veel zegt over de performance. Het is een erg synthetische specificatie die een heleboel factoren totaal verwaarloost. Bijvoorbeeld: RAID is sterk in het tegelijk uitvoeren van meerdere I/O request, access time werkt echter alleen met één request, en is een interne spec van de fysieke hardeschijf. Je kunt harddisk performance nu eenmaal niet in 1 cijfer uitdrukken, helaas. Dat gaat voor bijna alle hardware op trouwens.

@ je laatste post
Als je meer snelheid verlangt van RAID0 dan kun je daar idd schijven bijlpaatsen. Als je RAID5-set niet voor de snelheid is, heeft schijven bijplaatsen niet zoveel zin (wat wil je daarmee bereiken dan? ruimte erbij?). Bedenk wel dat raptors dure schijven zijn, zeker qua prijs per gigabyte. Bedenk dus heoveel geld je wilt uitgeven voor wat extra performance. Heb je write-back ingeschakeld?

schijven bij de raid5 plaatsen zou idd puur voor de ruimte zijn, niet snelheid.
dat raptors duur per gig zijn wist ik, heb ze ook puur voor de performance.
write back weet ik niet wat het is/doet dus dat ga ik even uitzoeken en dan kijken waar ik dat in moet schakelen.

Edit:
Maar nog steeds: hoeveel performance zal ik winnen met een extra raptor? Het is namelijk extra performance vs extra disk space.

Edit2:
Heb write back even nagezocht, en dat staat aan inderdaad.
Heb t er vanavond met n vriend nog eens over gehad, en hij had een heel logische redenering:
hoeveel "real life" snelheid zou je winnen met n extra raptor? 't antwoord is vrijwel niks:
Of windows nu boot in 1m20 of 1m10 is me worst, aangezien dit bakkie 24/7 aanstaat. En of een programma nu opstart in 5 sec of 4 sec is ook niet zwaar boeiend. Ander ding: of een dvd nu uitpakt in 40sec of 35 sec, zal ook weer het verschil niet maken.
Dus? Lekker 500GB erbij stoppen denk ik. Kan ik weer een maandje of 2 vooruit.

Als iemand nog onderwerpen ter discussie heeft of andere argumenten dan hoor ik die graag!

[ Voor 24% gewijzigd door Mr Alfabet op 25-10-2007 07:12 ]

[Mr Alfabet]

Verwijderd schreef op woensdag 24 oktober 2007 @ 14:57:
Inderdaad, behalve als iemand een verkeerde (te lage) stripesize heeft gebruikt. Stel iemand gebruikt 16KB als stripesize en Windows leest met blokjes van 64KB sequentieel, dan bepaalt de traagste schijf wel de performance; er zijn dan 4 (4x16KB=64KB) fysieke schijven nodig om 1 enkele request af te handelen. Nog erger: dankzij de stripe misalignment waarj e bij windows mee te maken hebt heb je 5 fysieke I/O requests nodig (naar de schijven toe) voor 1 virtuele I/O request (afkomstig van windows naar de RAID driver). Maargoed dit is gelukkig wel erg worst-case.

Nu ik er even overheen lees: ik heb inderdaad een stripe size van 16K gebruikt... is dat slecht in dit raid0 gevalletje? had t gevoel dat t wel lekker snel werd, vooral met korte bewerkingen (snel progje opstarten)

[Femme]

PROnline schreef op woensdag 24 oktober 2007 @ 13:32:
[...]

Je hebt 't over acces time. even als rekendvoorbeeld gemiddelde is 10ms met soms 5ms en soms 15. Bij raid bepaald bij elke actie de schijf die er toevallig op dat moment 't langste over doet de access time. Dus drie schijven kunnen binnen 5 - 10ms reageren en de 4e 15ms dan is het toch echt 15ms de acces time.
I.p.v. één schijf die de acces time bepaald heb je nu dus vier schijven die de resultaten bepalen waarbij de traagste waarde/schijf elke keer degene is die meeteld voor 't resultaat/gemiddelde.
In ideaalsituatie waarbij schijven synchroon lopen, dan zou de accestime vrijwel identiek kunnen zijn, maar dat is in de praktijk dus niet 't geval.

De gemiddelde toegangstijd neemt nauwelijks toe in raid. Dit kun je gewoon testen met wat benchmarks.

Het is wel handig om een niet te kleine stripe size te gebruiken anders krijg je inderdaad situaties die jij beschrijft. In een omgeving waarin veel gelijktijdige requests worden gedaan (bijvoorbeeld een database-server) wil je idealiter dat de data van de requests binnen een stripe vallen, zodat elke schijf in het raid zijn eigen I/O requests kan afhandelen. Daarom presteert een stripe size van 128K (LSI Logic, Areca) of 256K (Adaptec) meestal het beste.

De gemiddelde toegangstijd van de harde schijf zul je niet lager krijgen door raid. Toegangstijd is echter maar één van de factoren die een rol spelen in de prestaties. De gemiddelde responsetijd van de I/O's zal wel degelijk omlaag gaan omdat je er meerdere tegelijkertijd kunt uitvoeren of meerdere schijven aan een I/O kunt laten werken.

Als we spreken over rauwe doorvoer, dan wordt die inderdaad weer aanzienlijk sneller, maar die is niet enorm relevant voor de snelheid van 't opstarten van windows omdat 't hier relatief veel kleine bestandjes betreft en 'niet een enkel groot bestand.

Als je Windows sneller wilt laten opstarten moet je sowieso niet aan een Areca (of een andere intelligente raid-controller beginnen) vanwege de tijd die ze kwijt zijn aan het initialiseren bij het booten.

[Verwijderd]

Femme schreef op donderdag 25 oktober 2007 @ 11:43:
[...]
[...]


Als je Windows sneller wilt laten opstarten moet je sowieso niet aan een Areca (of een andere intelligente raid-controller beginnen) vanwege de tijd die ze kwijt zijn aan het initialiseren bij het booten.

Zijn machine staat 24/7 aan.. dus gaat niet om het starten van Windows .

Mijn machine met RAID5 3xRAPTOR 150GB & 6x500GB loopt niet meer lekker en dus aan vervanging toe. Misschien een beetje een NooB vraag? Maar is het niet verstandig om naar SAS over te stappen voor het sneller starten van programma's ???

Natuurlijk een hoop extra kosten ivm nieuw mobo, dure i/o kaart...

[ Voor 5% gewijzigd door Verwijderd op 02-12-2007 21:13 ]