Snel veel geheugen opslaan op een harddisk

maandag 9 april 2007 14:43

Topicstarter

Ik neem aan dat je niet maar 2 tientjes te besteden hebt, dus ik zou het goed doen, dus een goeie controller...

Trouwens met dit soort grote blokken data hoef je misschien helemaal geen raptors te nemen, maar kun je gewoon met nieuwe 7200 rpm schijven uit de voeten. Is goedkoper en je hebt meer ruimte.

De kosten van het systeem maken niet zoveel uit. Natuurlijk wel voor een goede prijs prestatie verhouding, maar het systeem moet natuurlijk wel ruim voldoen aan de specificaties.

7200 rpm schijven zijn inderdaad goedkopen, maar halen ze de snelheid?

Waarom met RAID-0 werken? Dan wachten de drie snelste schijven op de langzaamste. Schrijf elk vlak afzonderlijk weg, naar 1 schijf. Dat kan zonder serieuze overhead, en je schrijf dan 4 vlakken tegelijk.

Dit is inderdaad ook wel een goede oplossing. Ik had het in mijn verhaal niet echt duidelijk gemaakt, maar er staat nog veel meer data in het intern geheugen. Op dit moment is dat nog niet zo een groot probleem, maar in de toekomst misschien wel. Daarom wil ik het intern geheugen zoveel mogelijk sparen. Ik gebruik vier de zelfde schijven dus het wachten zal wel meevallen. Het grootste probleem is dat de theoretische snelheid van raid 0 bijna nooit in de praktijk wordt gehaald, maar ik denk dat als ik de block-size goed afstem op de bestands grootte, dat ik dan wel veel snelheids winst boek.

Acties:

Verwijderd

4*150MB is 600MB. Stel nu dat je een ramdisk hebt van 1gig. Daarin kan je 6 blokken bufferen. Is het dan geen optie, van zodra een blok is ingelezen, deze direct door te sluizen naar de ramdisk. Het werkgeheugen van 2 gig wordt dan voor maximaal 150MB bezet met data. De ramdisk kan je dan als buffer gebruiken om de data door te sluizen naar de harde schijven op de manier omschreven door MSalters.

maandag 9 april 2007 14:52

Acties:

kiddyl

Wat moet de computer doen nadat de scan is gemaakt? Gaat hij dan meteen verder met de volgende scan of worden er meteen andere dingen mee gedaan? Want dan moet er ook gekeken worden waar de opgeslagen data naar toe moet omdat de schijven anders wel heel snel volraken.

PV: 27kWp | WP: Adlar Aurora II 6kw

maandag 9 april 2007 14:54

Acties:

djexplo

Eigenlijk mis ik in dit hele verhaal de compressie mogelijkheden, dit is bepaald geen random data dus scheelt het als snel een factor 4x, zelfs met gewone bzip compressie inplaats van image 2D compressie.

ps. Tapes kunnen ook erg snel zijn als je in burst-mode schrijft ...

'if it looks like a duck, walks like a duck and quacks like a duck it's probably a duck'

maandag 9 april 2007 15:07

Acties:

cryforhelp

kiddyl schreef op maandag 09 april 2007 @ 14:52:
Wat moet de computer doen nadat de scan is gemaakt? Gaat hij dan meteen verder met de volgende scan of worden er meteen andere dingen mee gedaan? Want dan moet er ook gekeken worden waar de opgeslagen data naar toe moet omdat de schijven anders wel heel snel volraken.

Inderdaad belangrijk, als de data bijvoorbeeld via een netwerk weer weggehaald wordt, dan moet je er ook rekening mee houden dat het lezen daarvan ook ten koste van schrijfsnelheid gaat.
Of wordt er maar één kaart per keer doorgemeten, gevolgd door een flinke tussenpauze?

Want je kan maar 2 scans kwijt op die 4x74GB, dus of je moet er niet teveel doen, of je moet het snel wegschrijven.

maandag 9 april 2007 15:11

Acties:

maandag 9 april 2007 15:18

djexplo schreef op maandag 09 april 2007 @ 14:54:
Eigenlijk mis ik in dit hele verhaal de compressie mogelijkheden, dit is bepaald geen random data dus scheelt het als snel een factor 4x, zelfs met gewone bzip compressie inplaats van image 2D compressie.

ps. Tapes kunnen ook erg snel zijn als je in burst-mode schrijft ...

Bzip2 kun je wel vergeten realtime, maar opslaan in bijv een png-plaatje of gzip zou niet eens zo'n gek idee zijn om eens naar te kijken.
Mischien zijn er ondertussen ook al libs te krijgen die compressie doen via de GPU.

Voor wat betreft hdd's. Kijk inderdaad ook eens naar andere schijven dan de Raptors. Die dingen zijn met name snel bij de access-tijden, maar dat heb je hier helemaal niet nodig. Hier moet je gewoon een grote doorvoersnelheid halen en dan haalt een WD 500 GB RE2 schijf ook al zo'n 70 MB/s in de praktijk. Dat is bijna een derde van wat je nodig hebt.

Ik weet niet hoeveel tijd er zit tussen de scans, oftewel is er tijd genoeg om de data naar elders te krijgen tussen 2 scans?

Een goedkope voeding is als een lot in de loterij, je maakt kans op een paar tientjes korting, maar meestal betaal je de hoofdprijs. mijn posts (nodig wegens nieuwe layout)

Acties:

Frankie02

Waarom geen raid 5 (scsi?) kaartje met wat 7200 rpm harddiskjes. PCI-E / PCI-X kaartje

maandag 9 april 2007 15:20

Acties:

maandag 9 april 2007 15:26

Frankie02 schreef op maandag 09 april 2007 @ 15:18:
Waarom geen raid 5 (scsi?) kaartje met wat 7200 rpm harddiskjes. PCI-E / PCI-X kaartje

scsi schijven zijn per GB erg prijzig en raid5 is vaak toch een behoorlijke domper op de snelheid.
Dit lijkt mij een ideale toepassing voor raid0. (of 1)

Een goedkope voeding is als een lot in de loterij, je maakt kans op een paar tientjes korting, maar meestal betaal je de hoofdprijs. mijn posts (nodig wegens nieuwe layout)

Acties:

maandag 9 april 2007 15:46

Frankie02 schreef op maandag 09 april 2007 @ 15:18:
Waarom geen raid 5 (scsi?) kaartje met wat 7200 rpm harddiskjes. PCI-E / PCI-X kaartje

7200rpm met scsi?!

raid 5 lijkt me ook geen succes bij deze toepassing

het gaat hier niet om redundancy, maar om pure snelheid. daarom zou ik iig gaan voor een raid 0 met minstens 4 schijven, ik zou er ook nog over nadenken of je misschien niet beter een areca met 8 poorten (arc-1220) kunt kopen, zodat je later eventueel je array nog kan uitbreiden.
dit vind ik alleen een beetje raar:

Grove systeem eigenschappen:
Intel core 2 quad processor
2 GB ddr2 intern geheugen
Asus workstation moederbord.
4x WD raptor 36/74 Gb (raid 0)
WD raptor 150 Gb (windows)
PCI-X framegrabber
Areca ARC-1210LP (256MB)
2x PCI i/o kaarten

waarom een raptor 150Gb voor alleen windows? lijkt me dat je het met een 36GB ook wel redt

Acties:

maandag 9 april 2007 16:17

Topicstarter

4*150MB is 600MB. Stel nu dat je een ramdisk hebt van 1gig. Daarin kan je 6 blokken bufferen. Is het dan geen optie, van zodra een blok is ingelezen, deze direct door te sluizen naar de ramdisk. Het werkgeheugen van 2 gig wordt dan voor maximaal 150MB bezet met data. De ramdisk kan je dan als buffer gebruiken om de data door te sluizen naar de harde schijven op de manier omschreven door MSalters.

Als ik meer geheugen bij plaatst, dan is dit zeker een oplossing voor een bepaalde periode, maar wat is het voordeel dan van een ramdisk creëren als je de data ook even snel gewoon in het intern geheugen kan opslaan? Bedoelde je soms een ssd-disk in plaats van een ramdisk (softwarematige HDD in intern geheugen)? Ontwikkelingen gaan snel en probekaarten krijgen steeds meer kleinere probes. In de toekomst moet er dan nog veel meer geheugen bij worden geplaatst, maar dan kan er altijd nog overgestapt worden naar een 64bit besturingsysteem. Op dit moment zijn er nog geen 64bit drivers beschikbaar voor een aantal van onze i/o kaarten, maar deze moeten binnen afzienbare tijd toch wel eens beschikbaar komen. Deze oplossing is zeker het overwegen waard. Het voordeel is meer snelheid voor het zelfde geld en het nadeel is dat de complexiteit iets toeneemd.

Wat moet de computer doen nadat de scan is gemaakt?

Na de scan wordt per probe de nodigde data van de scan opgehaald, dan wordt de resulterende bitmap gefilterd, hierna vind er shape-matching plaats. Na de shape-matching van alle probes wordt er mesh matching uitgevoerd. Alleen het resultaat van het mesh-matching wordt opgeslagen, de rest van de data wordt vrijgegeven. Er blijft dus maar een paar MB over.

Eigenlijk mis ik in dit hele verhaal de compressie mogelijkheden, dit is bepaald geen random data dus scheelt het als snel een factor 4x, zelfs met gewone bzip compressie inplaats van image 2D compressie.

Het probleem van compressie is volgens mij dat het te langzaam is. Er is ongeveer 0,7 seconden de tijd om een blok van 146 MB te verwerken. Als dit langer duurt dan moet een scan worden gestopt. De beeldkwaliteit neemt af als je midden in een blok de motor stopt, omdat de beweging van de lijnscanner een constante snelheid nodig heeft om tot een zo duidelijk mogelijk beeld te komen. Je zou dan dus het volledige blok opnieuw moeten scannen. Dat betekent dan ook dat de motoren op nieuw op een goede start locatie moeten worden geplaatst, er is ook tijd nodig voordat de motoren een constante snelheid hebben bereikt. Het beste resultaat is dat er in één constante beweging 30 blokken worden gescand.

Acties:

maandag 9 april 2007 16:32

en die paar MB's die overblijven? nouja dat maakt waarschijnlijk niet veel uit, dan is snelheid niet meer van belang

als ik jou was zou ik gaan voor de oplossing die je eigenlijk in je startpost al hebt voorgedragen, een areca 1210LP met daarop 4x 74GB raptors (met 36GB raptors word het toch krap, je weet maar nooit). en dan zou ik een kleine raptor als OS schijf gebruiken.

Na de scan wordt per probe de nodigde data van de scan opgehaald, dan wordt de resulterende bitmap gefilterd, hierna vind er shape-matching plaats. Na de shape-matching van alle probes wordt er mesh matching uitgevoerd. Alleen het resultaat van het mesh-matching wordt opgeslagen, de rest van de data wordt vrijgegeven. Er blijft dus maar een paar MB over

hiertussendoor hoeft er dus geen grote kwak aan data opgeslagen te worden neem ik aan? anders moet je er natuurlijk rekening mee houden dat lezen en schrijven tegelijk op 1 raid0 array niet echt vlot gaat

al is het dan niet zo kritisch meer natuurlijk. maar volgens mij is dit helemaal niet van toepassing, toch?

Acties:

Fauna

Het gaat er als ik het goed lees alleen om dat er tijdens het scannen veel snelheid is. Daarna is het allemaal veel minder van belang.

Persoonlijk zou ik in dit geval meer neigen naar een 7k2 toeren schijf met hoge datadichtheid. Omdat er toch vrijwel altijd sprake is van sequentieel schrijven is een hoge doorvoer van groter belang dan een lage zoektijd. Denk dus bijvoorbeeld aan de 7200.10 serie van seagate, omdat deze zo ongeveer de meeste data per platter hebben.

maandag 9 april 2007 16:35

Acties:

kiddyl

Je kan eventueel voor een 8-poorts versie gaan van de Areca controller. Heb je tenminste nog een beetje headroom mocht de theorie in de praktijk anders uitpakken. Je kan dan makkelijk 2 of 4 schijven er bij zetten voor een nog hogere RAID-0 performance.

PV: 27kWp | WP: Adlar Aurora II 6kw

maandag 9 april 2007 16:39

Acties:

maandag 9 april 2007 16:42

Topicstarter

Hier moet je gewoon een grote doorvoersnelheid halen en dan haalt een WD 500 GB RE2 schijf ook al zo'n 70 MB/s in de praktijk.

Ik zou er ook nog over nadenken of je misschien niet beter een areca met 8 poorten (arc-1220) kunt kopen, zodat je later eventueel je array nog kan uitbreiden.

Volgens deze tweakers review [url=url, raptor review, raptor review]http://tweakers.net/reviews/621/1[/url] klopt dit inderdaad.
Het systeem moet alleen wel snel genoeg blijven. Ik had berekent dat ik ongeveer 9,23 minuten nodig heb met de raptors. Dit is al vrij krap.
Maar heb ik het wel goed berekent? Ik kwam tot een gemiddelde lees snelheid van ongeveer 289 MB/sec en een gemiddelde schrijf snelheid van ongeveer 238MB/sec. Heeft iemand toevallig zo'n setup staan en mij kan vertellen of deze getallen juist zijn?
Als ik ze te laag heb ingeschat dan is het misschien beter om WD 400 GB RE2 te gebruiken omdat deze de snelheid ook halen voor de zelfde prijs als raptors alleen dan met veel meer opslag ruimte.
Dat zou zeker voor de toekomst handig zijn.
Als ik het wel goed had ingeschat dan is het misschien beter om inderdaad te kiezen voor een areca met 8 poorten en misschien ook gelijk acht raptors.

waarom een raptor 150Gb voor alleen windows? lijkt me dat je het met een 36GB ook wel redt

Naast windows worden er ook nog andere grote programma's geïnstalleerd en we willen de klant ruimte genoeg bieden voor overige bestanden en programma's. 150 Gb is misschien ook wel iets teveel, 74 Gb moet ook volstaan.

hiertussendoor hoeft er dus geen grote kwak aan data opgeslagen te worden neem ik aan? anders moet je er natuurlijk rekening mee houden dat lezen en schrijven tegelijk op 1 raid0 array niet echt vlot gaat al is het dan niet zo kritisch meer natuurlijk. maar volgens mij is dit helemaal niet van toepassing, toch?

Nee, dit is niet van toepassing.

Acties:

maandag 9 april 2007 17:04

Zelfs daar netwerken?

Meer exacte beschrijvingen en details gewenst, ga je dit slechts 1x doen en rustig alles verwerken/opslaan? Gaat het enkel sequentieel?

Ik zou veel ram (meer dan 4GB) voorzien, waarschijnlijk heb je het wel nodig voor allerlei software en ongebruikte ram kan je als harde schijf caching gebruiken. Op mijn huidige Linux-fileserver staat 2GB ram klaar als harde schijf caching (als iemand opschept met zijn 16MB cache harde schijven

).

Dan een Areca RAID 5 controller halen met bv 8 Seagate 7200.10 harde schijven, kies de exemplaren dat het meeste aantal GB's per euro leveren. RAID 5 draaien voor veel storage, hoge snelheid en betrouwbaarheid.
Afbeeldingslocatie: http://tweakers.net/ext/benchchart/chart/11/

Afbeeldingslocatie: http://tweakers.net/ext/benchchart/chart/11/

Bereid je voor op "sick" transfer rates. Gelieve reviews te lezen en uit te zoeken: http://tweakers.net/reviews/cat/60

Acties:

maandag 9 april 2007 17:47

rapture schreef op maandag 09 april 2007 @ 16:42:
[...]
Bereid je voor op "sick" transfer rates. [...]

Vergeet niet dat de transferrate aan het eind van de schijf een stuk lager is dan aan het begin, dus houd daar rekening mee met de dimensionering dat dat al gauw een factor 1,5 kan schelen.
Dus als je dan 220 MB/s nodig hebt, dimensioneer dan op minimaal 400 MB/s.

Een goedkope voeding is als een lot in de loterij, je maakt kans op een paar tientjes korting, maar meestal betaal je de hoofdprijs. mijn posts (nodig wegens nieuwe layout)

Acties:

TheBorg

Resistance is futile.

rapture schreef op maandag 09 april 2007 @ 16:42:
Ik zou veel ram (meer dan 4GB) voorzien, waarschijnlijk heb je het wel nodig voor allerlei software en ongebruikte ram kan je als harde schijf caching gebruiken. Op mijn huidige Linux-fileserver staat 2GB ram klaar als harde schijf caching (als iemand opschept met zijn 16MB cache harde schijven ).

Aan een lading cache heb je erg weinig als je gedurende 10 minuten 220 MB/sec moet verwerken.

Ook ik denk dat het met een RAID array van de juiste hoeveelheid schijven zeker moet lukken, toch zou ik het gebruik van compressie niet onderschatten. Ik heb geen idee hoe je bitmap eruit ziet en hoeveel compressie er gehaald kan worden, maar stel dat je een compressie van 4x kunt halen dan heb je niet eens een RAID array nodig.

Een Intel Quad core moet makkelijk in realtime een simple delta-compressie/rice-encoding kunnen uitvoeren. Als je een factor van 20% haalt heb je er niks aan maar als je het niet probeerd dat weet je het ook niet. Een programmeur is er nog geen dag mee bezig om een goede inschatting van de mogelijkheden te maken.

maandag 9 april 2007 17:50

Acties:

maandag 9 april 2007 18:38

daar heeft TD-er gelijk in, ik zou alleen niet weten waarom TS raid-5 zou moeten draaien. het gaat hier totaal niet om redundancy, de data staat maar voor een korte periode op de raid array. daarom zou ik gaan voor een raid 0 array, om het meeste uit je schijven te halen.

8* 7200.10 / barracuda ES misschien? (een raptor maal 8 word erg kostbaar, en met 8 maal 7200.10 heb je ook ruim voldoende snelheid)

@theborg, ik denk dat de TS helemaal niet zit te wachten op compressie eerlijk gezegd

[ Voor 10% gewijzigd door struul op 09-04-2007 17:52 ]

Acties:

Onbekend

...

Ik heb het idee dat de TS de schijven als een soort RAM wil laten werken.
'Eventjes' 130 gig opslaan en dan verwerken.

Ik denk dat compressie (en een paar minuten later decompressie) meer verwerkingstijd gaat kosten vanwege de grote hoeveelheid data.

Speel ook Balls Connect en Repeat

maandag 9 april 2007 20:38

Acties:

maandag 9 april 2007 20:45

Ook onbekend schreef op maandag 09 april 2007 @ 18:38:
Ik heb het idee dat de TS de schijven als een soort RAM wil laten werken.
'Eventjes' 130 gig opslaan en dan verwerken.

zo moet je het ook een beetje zien, en ik denk dat 4 of 8 schijven in een raid-0 opstelling daar een prima oplossing voor is

een beetje kostbaar, maar ik denk niet dat dat een probleem is in deze bedrijfsmatige situatie

Acties:

maandag 9 april 2007 21:24

Topicstarter

Een Intel Quad core moet makkelijk in realtime een simple delta-compressie/rice-encoding kunnen uitvoeren. Als je een factor van 20% haalt heb je er niks aan maar als je het niet probeerd dat weet je het ook niet. Een programmeur is er nog geen dag mee bezig om een goede inschatting van de mogelijkheden te maken.

De achtergrond van een scan is vrij egaal. De probes zelf zouden een duidelijke ovale vorm moeten hebben, maar in de praktijk is dit niet altijd het geval vanwege beschadigingen. Ook hebben we zelfs in een cleanroom last van kleine storing (stof, ander vuil) en dat zie je heel erg als één pixel gelijk staat aan 0,8 micrometer.
Ik denk dat Huffman in dit geval iets sneller is dan Golomb en dat bij een plaatje zoals ik hierboven heb beschreven een factor van 30% zeker wel haalbaar is.
Alleen het probleem is dat een bestand van 146 MB in maximaal 0,7 seconden moet zijn gecomprimeerd en zijn weggeschreven op de HD. Dat gaat nooit lukken in die tijd.

Ok één ding is zeker 8 x 7200 hd raid 0 is sneller dan 4 x raptor raid 0. Daarnaast bied 8 x 7200 hd veel meer opslagruimte voor een lagere prijs.
Ook de HD waarop windows, overige applicaties en bestanden worden geplaatst verander ik van 150 Gb in 74 Gb, omdat 150 toch wat overdreven is.

Op dit moment denk ik dan ook aan de volgende configuratie:
8 x 7200.9 120Gb of 7200.10 250Gb
Areca ARC-1220LP (256MB)
1 x raptor 74Gb

Maar nu nog één vraag. Kan iemand mij vertellen wat de gemiddelde lees en schrijf snelheden van de bovenstaande raid 0 configuratie zijn (redelijk accurate schatting stel ik ook zeer op prijs)? Waarschijnlijk zal het sneller zijn dan nodig, maar toch belangrijk om te weten.

Acties:

maandag 9 april 2007 21:35

Zelfs daar netwerken?

bas wensveen schreef op maandag 09 april 2007 @ 20:45:
Maar nu nog één vraag. Kan iemand mij vertellen wat de gemiddelde lees en schrijf snelheden van de bovenstaande raid 0 configuratie zijn (redelijk accurate schatting stel ik ook zeer op prijs)? Waarschijnlijk zal het sneller zijn dan nodig, maar toch belangrijk om te weten.

2 Seagate 7200.10 leveren in RAID 0 75MB/s op het einde van de schijven, met 8 schijven in RAID 0 kan je extrapoleren naar 280MB/s.
KoppenSneller in "[Seagate 7200.10] Info en ervaringen"

Acties:

maandag 9 april 2007 21:53

volgens mij word dat wel iets meer dan 280 MB/sec

Acties:

maandag 9 april 2007 22:04

Zelfs daar netwerken?

struul schreef op maandag 09 april 2007 @ 21:35:
volgens mij word dat wel iets meer dan 280 MB/sec

Berekenen op de minimumwaardes, het maximaal zal inderdaad wat sneller zijn.

Acties:

maandag 9 april 2007 22:22

rapture schreef op maandag 09 april 2007 @ 21:53:
[...]
Berekenen op de minimumwaardes, het maximaal zal inderdaad wat sneller zijn.

precies, jij rekent met waardes die gelden voor het eind van de schijf. met 8* 250GB zal de TS alleen de buitenste, snelste gedeeltes gebruiken

ik denk dat je dan wel kan extrapoleren naar 400-440MB/sec

[ Voor 7% gewijzigd door struul op 09-04-2007 22:08 ]

Acties:

maandag 9 april 2007 23:32

Zelfs daar netwerken?

struul schreef op maandag 09 april 2007 @ 22:04:
precies, jij rekent met waardes die gelden voor het eind van de schijf. met 8* 250GB zal de TS alleen de buitenste, snelste gedeeltes gebruiken ik denk dat je dan wel kan extrapoleren naar 400-440MB/sec

Dus je begint de meting met volle snelheid en halverwege komt een foutmelding op het scherm dat de RAID-array te traag is? Vandaar dat ik van het slechtste ervan uit gaat, zelfs dan moet het nog goed gaan. Parameters zoals het aantal metingen achter elkaar draaien, is ook interessant om te weten. Is het zeker sequentieel? Vanaf het moment dat de koppen van harde schijven veel heen en weer moeten bewegen, zakt het aantal MB/s als een pudding in elkaar.

[ Voor 11% gewijzigd door rapture op 09-04-2007 22:24 ]

Acties:

maandag 9 april 2007 23:45

rapture schreef op maandag 09 april 2007 @ 22:22:
[...]
Dus je begint de meting met volle snelheid en halverwege komt een foutmelding op het scherm dat de RAID-array te traag is? Vandaar dat ik van het slechtste ervan uit gaat, zelfs dan moet het nog goed gaan. Parameters zoals het aantal metingen achter elkaar draaien, is ook interessant om te weten. Is het zeker sequentieel? Vanaf het moment dat de koppen van harde schijven veel heen en weer moeten bewegen, zakt het aantal MB/s als een pudding in elkaar.

ik zie het zo:
de totale grootte van de scan is hoe ik het begrijp 128,75GB groot, laten we zeggen 130GB. dat delen we door 8, kom je uit op 16,25GB per schijf. die 16,25GB staat dus op het snelste deel van de schijf

de ruimte daarachter zal niet gebruikt worden, hooguit misschien nog 1 scan erachter maar die kans schat ik ook vrij klein. en dan nog gebruik je het snelste deel van de schijf. maargoed het maakt niet uit, met 8*7200.10 hd's is er sowieso genoeg snelheid beschikbaar

. wil de ts gebruik maken van 7200rpm hd's, moeten het er dus wel minstens 8 zijn. 6 zou ook haalbaar zijn, al word dat alweer krap en kun je beter het zekere voor het onzekere nemen, die 2 poorten heb je toch al.

[ Voor 4% gewijzigd door struul op 09-04-2007 23:33 ]

Acties:

dinsdag 10 april 2007 00:05

bas wensveen schreef op maandag 09 april 2007 @ 20:45:
[...]

Op dit moment denk ik dan ook aan de volgende configuratie:
8 x 7200.9 120Gb of 7200.10 250Gb
Areca ARC-1220LP (256MB)
1 x raptor 74Gb

Maar nu nog één vraag. Kan iemand mij vertellen wat de gemiddelde lees en schrijf snelheden van de bovenstaande raid 0 configuratie zijn (redelijk accurate schatting stel ik ook zeer op prijs)? Waarschijnlijk zal het sneller zijn dan nodig, maar toch belangrijk om te weten.

Je zit nu naar behoorlijk laag geprijsde schijven te kijken. Houd er wel rekening mee dat als je dit dimensioneert, zonder al te veel marge, dat je in de problemen komt als er ooit 1 schijf stuk gaat.
Je zult namelijk na x maanden niet meer een zelfde schijf kunnen vinden en als je zo tegen het maximum aan gaat zitten van de schijven, dan kan een te snelle schijf ook nog de hele array vertragen.
De snelle schijf zal namelijk steeds moeten wachten op de trage schijven en het lijkt me onwaarschijnlijk dat dat wachten precies 1 rotatie is, en/of altijd netjes opgevangen kan worden door de cache op de schijven.
Kortom dan zal eens in de zoveel MB (afhankelijk van veel factoren waaronder de cache-grootte) de rest van de array moeten wachten op de snelle schijf.
Oftewel koop minstens 1 schijf extra van hetzelfde type en als je gaat voor de goedkopere (niet actuele of refurbished) schijven, sla er dan wat meer in.
Een ander nadeel van goedkopere schijven is dat ze een kleinere opslag hebben en dat wil dus zeggen minder data per rotatie onder de kop door. Hierdoor kan het zijn dat je bijvoorbeeld met 4 grote schijven uit zou kunnen, maar met kleine schijven dus toch duurder uit bent omdat je een 8-poorts controller nodig hebt.
Houd hier dus rekening mee bij het opstellen van de array.
Totale kosten is namelijk controller + cache geheugen + schijven.

Een goedkope voeding is als een lot in de loterij, je maakt kans op een paar tientjes korting, maar meestal betaal je de hoofdprijs. mijn posts (nodig wegens nieuwe layout)

Acties:

dinsdag 10 april 2007 00:24

Topicstarter

Totale kosten is namelijk controller + cache geheugen + schijven.

De snelle schijf zal namelijk steeds moeten wachten op de trage schijven en het lijkt me onwaarschijnlijk dat dat wachten precies 1 rotatie is, en/of altijd netjes opgevangen kan worden door de cache op de schijven.

Op de Areca controller zit al cache geheugen. Ik denk dat het later bijplaatsen van een nieuwe hd niet echt erg veel performance scheelt. Ik stuur in één keer een bestand van 146MB dit wordt in meerdere stukken verdeeld en in het cache opgeslagen. Het enige probleem is dat de snelste hd nooit op volle snelheid zal werken omdat hij moet wachten tot de sloomste hd klaar is. Het is niet zo dat het schrijven van data exact synchroon moet lopen. Aangezien de snelheid van een hd bijna altijd iets afwijkt van een hd van het zelfde type, zal dat bij jou beredenering betekenen dat alle hd's telkens op elkaar staan te wachten. Ik denk dat er dus gezegd kan worden dat de snelheid van elke hd in een raid 0 array net zo snel is als de langzaamste hd in deze array.

Na het lezen van wat andere topics op dit forum en wat googlen heb ik het volgende berekend. minimaal: 305 MB/sec
maximaal: 612.4 MB/sec
gemiddeld: 507.5 MB/sec

Het is inderdaad het beste om van de minimum snelheid uit te gaan. Bij een snelheid van 305 MB/sec duurt het opslaan van 128,75 GB ongeveer 7,2 minuten dus ruim binnen de 10 minuten. In praktijk denk ik dat ik kan rekenen op een snelheid van ongeveer 550 MB/sec. Bij deze snelheid duurt het opslaan nog maar 4 minuten.

De volgende configuratie zal ik aan mijn baas aanbevelen:
8 x 7200.10 250Gb (raid 0)
Areca ARC-1220LP (256MB)
1 x 7200.10 250Gb (windows en overige)

Als het zo ver is dan zal ik de test resultaten posten.

Iedereen bedankt voor alle posts!!!

Acties:

dinsdag 10 april 2007 00:41

Als je gaat testen ben ik heel benieuwd of je ook in de praktijk kunt zeggen dat de max snelheid afhangt van de traagste schijf.
Kortom, hang er dan ook 1 snellere schijf aan (bijv die raptor) en test dan de array-snelheid.
Let wel dat je dan van de grote schijven ook een navenant kleiner deel gebruikt, omdat die raptor een stuk kleiner is.

Ik ben gewoon benieuwd of de cache van de controller dat verschil kan opvangen of niet.
Zou namelijk een heel groot pluspunt zijn voor die Areca's. De cache-grootte per schijf op de controller is namelijk "maar" 2x - 4x zo groot als de cache op de schijven zelf.

Met software-raid weet ik helaas uit ervaring dat de snelheid van de array compleet in elkaar zakt als je niet gelijke schijven hebt (2 schijven RMA geweest en anderen ervoor terug gekregen

)

Een goedkope voeding is als een lot in de loterij, je maakt kans op een paar tientjes korting, maar meestal betaal je de hoofdprijs. mijn posts (nodig wegens nieuwe layout)

Acties:

ThaHandy

Discovery Channel

bas wensveen schreef op maandag 09 april 2007 @ 20:45:
[...]

Op dit moment denk ik dan ook aan de volgende configuratie:
8 x 7200.9 120Gb of 7200.10 250Gb
Areca ARC-1220LP (256MB)
1 x raptor 74Gb

Maar nu nog één vraag. Kan iemand mij vertellen wat de gemiddelde lees en schrijf snelheden van de bovenstaande raid 0 configuratie zijn (redelijk accurate schatting stel ik ook zeer op prijs)? Waarschijnlijk zal het sneller zijn dan nodig, maar toch belangrijk om te weten.

niet 8 maar hier heb je specs met 7x 7200.10 320GB
ThaHandy in "[Benchmarks] Post hier je RAID scores!"

dinsdag 10 april 2007 08:43

Acties:

dinsdag 10 april 2007 09:48

Topicstarter

Ik had me al verrekent in de snelheid, want een maximale schrijf snelheid van 612.4 MB/sec is natuurlijk nooit haalbaar als één hd maximaal 76 MB/sec doet.

niet 8 maar hier heb je specs met 7x 7200.10 320GB
ThaHandy in "[Benchmarks] Post hier je RAID scores!"

Ook kwam ik het volgende tegen:
[Benchmarks] Post hier je RAID scores! <- 4x 150 Gb WD Raptor raid 0
ThaHandy in "[Benchmarks] Post hier je RAID scores!" <- 4x 230
GB Hitachi raid 0
ThaHandy in "[Benchmarks] Post hier je RAID scores!" <- 8x WD RE2 400GB

Hier kan je duidelijk zien dat de WD raptor's maar iets sneller zijn dan de andere HD's. Maar wat mij opviel is dat het performance verschil van 4 HD's naar 7 tot 8 HD's er weinig uit maakt. Ligt dit misschien aan de performance van pci-x of pci-e bus, maar bijv de snelheid van pci-e x8 is toch ongeveer 1,25GB/sec of is dit theoretisch.
Dan ben ik er toch nog niet helemaal uit. Het prijsverschil tussen 4 HD's en 8 HD's (controller) moet wel worden gerechtvaardigd.

Als je gaat testen ben ik heel benieuwd of je ook in de praktijk kunt zeggen dat de max snelheid afhangt van de traagste schijf.

Ik zal vragen of ze er ook even een andere schijf tussen willen hangen tijdens bouwen.

Acties:

dinsdag 10 april 2007 09:51

Zelfs daar netwerken?

bas wensveen schreef op dinsdag 10 april 2007 @ 08:43:
Hier kan je duidelijk zien dat de WD raptor's maar iets sneller zijn dan de andere HD's. Maar wat mij opviel is dat het performance verschil van 4 HD's naar 7 tot 8 HD's er weinig uit maakt. Ligt dit misschien aan de performance van pci-x of pci-e bus, maar bijv de snelheid van pci-e x8 is toch ongeveer 1,25GB/sec of is dit theoretisch.
Dan ben ik er toch nog niet helemaal uit. Het prijsverschil tussen 4 HD's en 8 HD's (controller) moet wel worden gerechtvaardigd.

Je hebt snel en snel, Seagate 7200.10 kan op vlak van transfer rate mee met de Raptors. Maar als de koppen snel heen en weer moeten bewegen (bv 10 users halen tegelijkertijd 10 verschillende films van een fileserver af, "grote bestanden" kunnen plotseling als "kleine bestanden" gedragen), dan heb je de Raptors nodig.

Caching maakt voor kleinere bestanden of veel door elkaar schrijven/lezen uit. Puur sequentieel GB's pompen, zoekt vooral naar transfer rates en 2GB cache zou in 10 seconden vollopen. Maar de harde schijven lezen/schrijven niet perfect even snel zodat er wat cache tussen zit voor wat ademruimte, er kan direct wat data in de cache gedumpt worden, daarna schrijven de schijven het wel weg als ze tijd hebben.

Van 4 naar 7/8 schijven merk je pas op een goede controller, RAID 5 is tijdens het lezen bijna zo snel als RAID 0, maar tijdens het schrijven moet je pariteit berekenen en eenvoudige controllers zakken in elkaar. RAID 0 met 8 schijven, is aan de riskante kant. Wat wordt er met de data gedaan, naar waar gaat het? Hoeveel manuren verlies je als de RAID 0 faalt?

Acties: