Serial ATA en SCSI RAID-prestatievergelijking

Op Tom's Hardware Guide is een vergelijking verschenen van een vijftal Serial ATA en Ultra320 SCSI RAID-adapters. De SATA-interface werd vertegenwoordigd door de 3ware Escalade 8506-8, HighPoint RocketRAID 1820 en de RAIDCore RC4852. Adaptec en LSI Logic verdedigden de eer van het SCSI-kamp met hun ASR-2200S en MegaRAID 320-2 RAID-adapters. De rode draad van het artikel is het product van nieuwkomer RAIDCore. Dit bedrijf werd in 2000 opgericht door een aantal voormalige werknemers van Adaptec en legt zich volledig toe op de ontwikkeling van RAID storage producten. De toon en het enthousiasme waarmee de mogelijkheid van de RAIDCore RC4852 in het THG-artikel worden uitgemeten, geven je regelmatig het gevoel van doen te hebben met een advertorial voor het genoemde bedrijf.

Desalniettemin heeft RAIDCore een aantal interessante en vernieuwende technologieën ontwikkeld. Eén van de unieke features van de RAIDCore RC4852 is de mogelijkheid om gebruik te maken van zogeheten distributed hotspares. Hierbij wordt een deel van de capaciteit van de schijven in de array gereserveerd om gebruikt te worden als ruimte waarop de array gerebuild kan worden als een van de schijven uitvalt. Distributed hotspares zijn een alternatief voor reguliere hotspares, waarvan vaak maar één exemplaar in een systeem aanwezig is. Als die ene hotspare uitvalt én er tegelijkertijd een harde schijf sterft in een RAID-array kan er alsnog dataverlies optreden bij een defect aan de overgebleven harde schijven. Distributed hotspares zijn minder foutgevoelig mits er voldoende ruimte op de schijven wordt gereserveerd.

De RAIDCore RC4852 is momenteel de enige Serial ATA RAID-controller met ondersteuning voor PCI-X. Naast een hogere kloksnelheid van maximaal 133MHz biedt PCI-X een efficiëntere busbelasting dan PCI 2.2, waardoor de prestaties ook op een kloksnelheid van 66MHz beter zijn. De overige adapters in de test - ook die met een SCSI-interface - waren voorzien van 64-bit 66MHz PCI 2.2. LSI Logic's MegaRAID 320-2X was helaas nog niet meegenomen in de vergelijking. De verbetering ten opzichte van de MegaRAID 320-2 zijn onder andere ondersteuning voor PCI-X en de implementatie van een snellere 400MHz IOP321 (XScale) I/O processor met 200MHz DDR SDRAM. De MegaRAID 320-2 en de Adaptec 2200S moeten het nog doen met 100MHz SDRAM en een 100MHz IOP303 processor. Standaard beschikken de Adaptec 2200S en de LSI MegaRAID 320-2 over 64MB cachegeheugen. De controller van HighPoint heeft geen I/O processor en geen cache. Parityberekeningen moeten daardoor uitgevoerd worden door de processor. Dit geldt niet voor de 3ware Escalade 8506, die wel een I/O processor aan boord heeft maar is voorzien van slechts 2MB geheugen. De cachegrootte van de RAIDCore RC4852 werd niet vermeld in de review en is vreemdgenoeg ook niet terug te vinden op de site van RAIDCore. Op deze site is overigens wel veel interessante informatie is te vinden over RAIDCore's Fulcrum RAID-architectuur.

Helaas heeft THG een tamelijk brakke benchmarkmethode gebruikt die slechts een beperkt beeld kan geven van de prestaties van de controllers. Er werd uitsluitend getest in RAID 5-configuraties met acht Western Digital Raptor WD360GD schijven of acht Maxtor Atlas 15- harde schijven. Andere RAID-levels werden niet gebenched en ook werd er geen informatie gegeven over de performance settings die op de controllers werden gebruikt. De resultaten, voor zover door conclusies aan verbonden kunnen worden, laten zien dat de RAIDCore RC4852 zeer goed presteert in vergelijking met de Serial ATA-adapters van 3ware en HighPoint. In Winbench 99, de enige zinvolle desktop benchmark in de testsuite van THG, kwam de RAIDCore RC4852 dicht in de buurt van de gemiddelde prestaties van de MegaRAID 320-2. De performance van de RAIDCore-adapter bevond zich op geheel ander niveau dan de prestaties van de 3ware Escalade 8500-8 en de HighPoint RocketRAID 1820, welke een factor drie tot vijf slechter scoorden. De RAIDCore RC4852 presteerde vrijwel gelijk aan de snelste SCSI RAID-adapters in de fileserver en webserver simulaties, terwijl de LSI MegaRAID 320-2 superieur presteerde in de online transaction processing benchmarks. De HighPoint RocketRAID 1820 vormde het levende bewijs dat hoge sequentiële transfer rates niet gelijk staan aan hoge real world performance: ondanks STR's van bijna 450MB/s waren de prestaties in de server simulaties net zo bedroevend als in de desktop benchmarks.

	Winbench 99 v2.0 - Business en High-End gemiddelde (KB/s)
	LSI MegaRAID 320-2	53900
	RAIDCore RC4852	50550
	Adaptec 2200S	39900
	3ware Escalade 8506-8	18145
	HighPoint RocketRAID 1820	9030

Wat betreft prijs is de RAIDCore RC4852 een interessant alternatief voor RAID-adapters van de gevestigde orde. Uitgerust met acht Serial ATA-poorten kost de RC4852 slechts 350 dollar, waarmee de prijs aanzienlijk lager is dan de 3ware Escalade 8506-8 ($500) en de dual channel SCSI RAID-adapters ($650). De prijs per poort van de HighPoint RocketRAID sluit goed aan bij zijn prestaties. Beide behoren tot de laagste in de test .

Reacties (34)

[Verwijderd]

ik heb enkele bedenkingen bij deze review die volgens mij in de conclussie van ome Tom ontbreken.
-Het zijn die Raptors vs. SCSI schijven. En niet zomaar SATA schijven. Dit zijn schijven die volgens de technieken van 10.000 tr. scsi schijven zijn gebouwd. En die vele malen duurder zijn per MB opslagruimte dan de gewone SATA schijven.
- Er wordt weer maar eens niets gezegd over CPU last. En dat lijkt me toch ook niet onbelangrijk. Zeker niet in een workstation waar elke kloktik belangrijk is.
SCSI gaat harde tijden tegemoet? Ik weet het zo nog niet. SAS en SATA zijn compatibel. En traditiegetrouw hebben high-end SCSI-controllers een betere processor en meer en sneller geheugen aan boord dan een ATA controller. Om nog niet te spreken van on-board controllers die lekker op je systeem gaan wegen. Het lijkt me dus dat voor de SCSI technieken de komende jaren nog een mooie toekomst wacht. Want als ik een "goedkope" SATA schijf op een high-end controller (SAS) kan hangen waardoor ik minder last heb van vertragingen door CPU verbruiken van soms wel 50% met een on-board SATA controller ga ik dat zeker niet laten. En volgens mij zijn er veel pc gebruikers en bouwers die zo gaan redeneren.

[Pruttelpot]

ik heb enkele bedenkingen bij deze review die volgens mij in de conclussie van ome Tom ontbreken.
-Het zijn die Raptors vs. SCSI schijven. En niet zomaar SATA schijven. Dit zijn schijven die volgens de technieken van 10.000 tr. scsi schijven zijn gebouwd. En die vele malen duurder zijn per MB opslagruimte dan de gewone SATA schijven.

En dat is ook precies waar die schijven voor bedoeld zijn. Voor zeer snelle en betrouwbare opslag. Waarom zou je in een snelheidsmonster (zo kan je die SATA raid controller toch wel noemen) goedkope hardeschijven proppen? Gaat heel het nut verloren lijkt mij.
De schijven die getest worden zijn voor precies hetzelfde ontwikkeld als de scsi schijven waar ze tegenover staan. Snelheid, snelheid, snelheid en betrouwbaarheid.

- Er wordt weer maar eens niets gezegd over CPU last. En dat lijkt me toch ook niet onbelangrijk. Zeker niet in een workstation waar elke kloktik belangrijk is.
SCSI gaat harde tijden tegemoet? Ik weet het zo nog niet. SAS en SATA zijn compatibel. En traditiegetrouw hebben high-end SCSI-controllers een betere processor en meer en sneller geheugen aan boord dan een ATA controller. Om nog niet te spreken van on-board controllers die lekker op je systeem gaan wegen. Het lijkt me dus dat voor de SCSI technieken de komende jaren nog een mooie toekomst wacht. Want als ik een "goedkope" SATA schijf op een high-end controller (SAS) kan hangen waardoor ik minder last heb van vertragingen door CPU verbruiken van soms wel 50% met een on-board SATA controller ga ik dat zeker niet laten. En volgens mij zijn er veel pc gebruikers en bouwers die zo gaan redeneren.

Het voordeel van deze kaarten is dat ze hun eigen processor hebben, kortom, het kost de cpu in je pc nouwelijks tot niets qua capaciteit. En dat is nou precies een van de verijsten van zo'n kaart. Die meot alles zelf kunnen, de cpu heeft al genoeg te doen

[ijdod]

Is CPU load nog echt relevant als je systeem op de disk I/O bottleneck zit te wachten?

[Pietervs]

Als die ene hotspare uitvalt én er tegelijkertijd een harde schijf sterft in een RAID-array kan er alsnog dataverlies optreden
het idee van een hotspare is juist, dat deze een uitgevallen schijf kan vervangen. Kans dat een Hotspare uitvalt voor dat je andere schijven uitvallen, is als het goed is verwaarloosbaar: hij is wel "live", maar er wordt geen data naar geschreven of van gelezen. Ik vind het dus vreemd, dat er zo blij wordt gedaan over een distributed hotspare: het is een mooi systeem, maar ik vraag me af of het nou echt zoveel toevoegd t.o.v. je reguliere Raid5+1 systemen...

[LordMithril]

Meer zekerheid.
Ja de kans is klein dat je spare ook dood gaat of dat 2 schijven tegelijk overleiden maar het zijn altijd de dingen die je niet verwacht die alles verzieken op het moment dat je het het minste kan gebruiken.

Voor bedrijven is dit is best interresant.
(of voor een tweaker met een enorme pr0n collectie )

[mjtdevries]

Nee. Voor bedrijven is dit niet interessant. Die gaan namelijk serieus kijken hoe groot die kans eigenlijk is.

Maar als je die ongelooflijk kleine kans gaat meerekeningen in je hardware omgeving, dan moet je nog veel meer rekening houden met: overstromingen, een windhoos die toevallig je rekencentrum vol raakt en verwoest, vliegtuigen die op je server vallen, meteoren die er bovenop vallen, en meer van dat soort zaken waarvoor de kans veel groter is.

Dit is niet bedoeld om je belachelijk te maken, maar om een juist beeld te geven van de grootte van de kans waar je over praat.

[Verwijderd]

Kans dat een Hotspare uitvalt voor dat je andere schijven uitvallen, is als het goed is verwaarloosbaar: hij is wel "live"

Intel raid controllers zetten hun spare zelfs vrijwel helemaal stroomloos. Zodra er een schijf uitvalt spint de spare up.

Een raid 5 is een veilig en snel systeem. Een raid 5+1 is nog veiliger. Op een gegeven ogenblik is het wel genoeg en kun je beter kijken of de extra veiligheid het geld wel waard is.

[mjtdevries]

Ik denk eigenlijk dat als je dat werkelijk wilt overwegen, dat Raid 6 dan veiliger is dan Raid5+1.
(Bij raid6 heb je twee parity schijven)

[Ricochet]

Voor een nieuwkomer (als merknaam en bedrijf dan, er zit al behoorlijk wat informatie en kennis in huis) een enorm mooie binnenkomer.

Ik kan alleen zo gauw bij THG als bij RAIDCore niets vinden over eventuele prijzen. Iemand? (Of kijk ik er weer overheen?)

[Verwijderd]

De toon en het enthousiasme waarmee de mogelijkheid van de RAIDCore RC4852 in het THG-artikel worden uitgemeten, geven je regelmatig het gevoel van doen te hebben met een advertorial voor het genoemde bedrijf.

Dat gevoel heb ik wel vaker bij ome Tom...
Aan de andere kant. Hij heeft ook wel vaak echt goede artikelen.

[Pruttelpot]

K wil niet veel zeggen hoor, maarem, 53900MB per sec? Dus een transferrate van 53GB per seconde? Dat kan neit

[Verwijderd]

Ik denk dat ze 53,900 MB/s bedoelen

[Update]
Oeps, net een paar seconden te laat. Na de reload van mijn post stond er al KB/s.

[Pruttelpot]

En 53mb vind ik dan eigenlijk weer behoorlijk weinig De nieuste schrijven hebben tegenwoordig toch wel zo ongeveer een doorvoersnelheid van ruim 40mb per sec, per hd. Dus dan mag je van een raid controller verwachten dat ie wel iets van 200mb per sec kan halen toch? Of ben ik nou scheel?

[Defspace]

Jij bent scheel
Was het maar waar dat de performance opschaalde naar gelang je er meer schrijven bijplaatst. Iedere disk heeft toch een access- en seektime welke de totale performance nadelig beinvloeden. De performance in RAID5 configuratie is vrijwel altijd hoger dan een onafhankelijke disk. Maar RAID5 is er meer voor om redundantie te creeren op een logische disk die veel groter is dan 1 onafhankelijke disk.

[Femme]

Die 40MB/s van jouw ATA-harde schijf wordt alleen gehaald in een sequentieel toegangspatroon waarbij de lees/schrijfkop zijn huidige spoor kan blijven volgen en zich niet hoeft te verplaatsen naar andere posities op de schijf. Zodra dat wel gebeurt daalt de transfer rate dramatisch. Harde schijven hebben een relatief zeer hoge toegangstijd van 5,5 tot 13,0ms (afhankelijk van toerental en de prestaties van de van de actuators). Voor elke kopverplaatsing kan de schijf voor gemiddeld 5,5 tot 13,0ms niet lezen of schrijven (werking van de cache even buiten beschouwing gelaten). Als dat vaak gebeurt blijft er niet veel van je transfer rate over. 50MB/s is daarom helemaal geen slechte score voor een benchmark die real world applicaties simuleert. De snelste 15K SCSI-schijven halen in een volledig willekeurig toeganspatroon van kleine requests een transfer rate van enkele megabytes per seconde terwijl ze sequentieel meer dan 75MB/s doen.

Het is jammer dat zoveel mensen zich laten gek maken door ATTO STR's en daardoor de realiteit uit ogen hebben verloren.

[Femme]

200MB/s halen ze ook wel op sequentieel lezen en schrijven. Winbench 99 doet echte applicaties na en die doen hele andere dingen dan sequentieel lezen en schrijven. Sequentiële transfer rates hebben weinig relatie met real world applicatie performance.

[Pruttelpot]

Maar het zou toch echt een heel stuk sneller meoten gaan? Anders kan je netzogoed normale schijven gewoon mirroren, even snel

[robbert_nl]

Nee, indien goed geïmplementeerd is mirroring zowel sneller bij lezen als schrijven.

Het voordeel van RAID5 t.o.v. mirroring is niet de performance, maar kosten. Mirroring is een veel duurdere oplossing als redundante dataopslag.

[Marlibica]

Is dat waar? Raid 0 (stripe) is sneller dan een enkele schijf omdat access tijd bijvoorbeeld door de schijven gedeeld wordt (als de ene bezig is is de andere al beschikbaar).
Raid 5 is volgens mij raid 0 met parity.

(is reactie op Defspace_)

edit:

Jongens, leg eens uit. Waarom ktijgt Defspace een 2 inzichtvol terwijl hij het fout uitlegt en iedereen die hem corrigeert een 0 overbodig???
Thnx mjtdevries voor de uitleg

[mjtdevries]

Femme slaat de spijker op de kop.

Daar komt dan meteen het andere voordeel van Raid arrays om de hoek kijken: je haalt er je effectieve toegangstijd mee omlaag. Met name als je er veel schijven in hangt.
Want wanneer de ene schijf (of schijven) een file aan het lezen is, kan parallel daaraan een ander schijf (of schijven) in de array een ander file lezen.

Dat is een veel interessantere eigenschap van Raid arrays dan de sequentiele transferrate IMO.

Vandaar ook dat de performance van een raid array over het algemeen omhoog gaat bij een grotere stripe size. Het vergroot namelijk de kans dat twee files elk op aparte schijven staan en dus tegelijkertijd uitgelezen kunnen worden.

Overigens kun je in een serveromgeving best wel vaak sequentiele patronen terugvinden. Transactielogs van SQL en Exchange zijn zo'n voorbeeld. Aan de andere kant is de performance van huidige schijven zo goed op dat punt, dat dat zelden een bottleneck zal vormen en je daarvoor geen 8 schijven in Raid0+1 hoeft te zetten.

(Sorry Marlibia's reactie niet gezien. Deels een dubbelpost)
Inderdaad is Raid 5 Raid0 met parity. Maar die parity heeft erg grote invloed op de performance. Het zorgt er bv voor dat Raid5 relatief gezien erg langzaam is met schrijven en daardoor vaak amper sneller (of zelfs langzamer) is dan een enkele schijf.
Lezen is echter wel sneller en dat komt dan inderdaad door dezelfde redenen als bij Raid0. Die parity berekening hoef je dan niet te doen, dus is bij lezen de performance van Raid5 zoveel hoger.

[Verwijderd]

Leuke bench opzich wel, laten we hopen dat oom Tom er een beetje een objectieve blik op heeft geslagen, dit zou namelijk wel iets leuks betekenen op IDE gebied Vooral als de rocketraid adapter niet al te belachelijk duur is.

[Tomatoman]

Ik ben bang dat deze test nogal gekleurd is. Er is alleen in RAID 5 getest en het zou best kunnen dat dat is omdat de RAIDCore daar erg goed in scoort. Goede kans dat de RAIDCore-kaart een stuk minder scoort ten opzichte van de concurrentie in RAID 0 en RAID 1.

Uit (veel uitgebreidere) tests van c't Magazin bleek dat de kaarten zonder eigen controller en buffer (die dus met software-RAID werken) nauwelijks voordeel opleveren ten opzichte van losse IDE-schijven. De veel duurdere kaarten met hardware-RAID geven daarentegen een grote performancewinst.

Ik ben daarom bang dat het positieve imago van RAID voornamelijk te danken is aan de dure serveroplossingen, maar op onze nederige desktopmachientjes weinig voordeel biedt. Afgezien van een aanmerkelijk verhoogde tweakerstatus dan

[Verwijderd]

Ik ben daarom bang dat het positieve imago van RAID voornamelijk te danken is aan de dure serveroplossingen, maar op onze nederige desktopmachientjes weinig voordeel biedt. Afgezien van een aanmerkelijk verhoogde tweakerstatus dan

In deze test zit toch echt maar een software raid controller, de rest is allemaal hardwarematig. Daarbij komt nog dat een raid5 opstelling met 8 schijven erg zeldzaam is bij een normaal desktop systeem...

De raid configuraties die meestal gebruikt worden bij desktop systemen zijn 1 (mirror) of 0 (stripe). En deze worden dus toevallig ff niet getest door THG. Daarbij komt nog dat er geen enkel zichzelf respecterend bedrijf is dat op deze benchmarks afgaat (niet erg representatief). Wat dus wil zeggen dat deze benchmark zowel voor de thuisgebruiker als voor de bedrijfsinkoper geheel nutteloos is . . .

[Tomatoman]

Helemaal mee eens. Ik baseerde mijn conclusie dan ook niet op de review van THG, maar die van c't Magazin. Daar hadden ze het over RAID 0 en 1 in combinatie met 2 parallel ATA dan wel SCSI schijven.

[Femme]

De simpele firmware RAID-controller kan de desktop prestaties in RAID 0 met 2 schijven met ongeveer 45 procent verbeteren. Een intelligente RAID-controller met cachegeheugen kan een verschil van 80 procent realiseren in RAID 0 met twee drives. De cache speelt een belangrijke rol. Het verschil tussen een domme Promise-controller en een 3ware Escalade (geen cache) is minimaal.

[DavidAxe]

Het is helemaal niet zo raar dat ze geen RAID 0 en RAID 1 tests op deze kaarten uitgevoerd hebben, want daar heb je veel goedkopere kaarten voor.

[nAFutro]

Helaas heeft THG een tamelijk brakke benchmarkmethode gebruikt

Heeft er ook eentje al jaren een uitgebreide testmethode...

[loodgieter]

Waarom de FastTrak S150 SX4 nu weer niet in de test is opgenomen begrijp ik niet. Dacht dat Promise ook een vooraanstaand leider was in RAID (SATA, PATA) technieken.

[mjtdevries]

Die promise kaart doet het inderdaad erg goed.
Net alleen is ie veeel goedkoper, maar hij verslaat de concurrentie meestal ook nog eens.
Tech-report had er een goede review over. Alleen weet ik uit ervaring dat het ding wel ontzettend kritisch is tov het gebruikte geheugen.

De enige reden die ik kan bedenken waarom ie niet meegenomen is, is dat die kaart maximaal 4 schijven ondersteunt, terwijl Tom om een of andere vage reden perse met 8 schijven wilde testen.

Zal wel omdat je zelf met 8*36GB niet bepaald een spectucalair grote array hebt. Maar 250GB bruikbare opslag capaciteit, terwijl ik op mijn promise met 4*120GB al 360GB heb.

Een andere reden om 8 schijven te gebruiken kan zijn omdat dan de voordelen van SCSI tov SATA minder worden. Een Raid array word effectiever en sneller als je meer schijven gebruikt. Het aandeel van de interface van de schijven zelf wordt dan een stuk minder. Je ziet dan voornamelijk de performance van de Raid controller hardware zelf.
Wat met 8 schijven ook veel belangrijker wordt is de interface van de raid controller: PCI of PCI66 of PCI-X

Gezien de toon van het artikel krijg je dan toch wel heel sterk het gevoel dat hier specifiek een best-case scenario voor die RaidCore is gemaakt en dat dan getest is.

En dat zou me ook niet verbazen gezien de manier waarop Tom's hardware de laatste tijd opereert.

Hoewel het aan de andere kant ook wel interessant is om te zien hoeveel extra die Raidcore uit SATA kan halen.

[grimlock]

Alleen jammer dat IDE drivers niet gebouwd zijn op continue aan staan. Waarom klinken deze producten dan weer tegenstrijdig?

[mjtdevries]

Die Raptor schijven zijn er wel op gebouwd. En naast die raptors zijn er nog een aantal andere types IDE schijven die voor hogere beschikbaarheid gebouwd zijn.

Bovendien zorg je met een Raid5 controller juist dat die extra uitval helemaal niet interessant meer is. Je moet dan wellicht twee keer per jaar een schijf verwisselen ipv 1 keer. Dat is niet boeiend.

[cdwave]

Lekker objectieve test...

ATA: 10k rpm schijven
SCSI: 15k rpm schijven

Tsjonge, wie zou er nu toch gaan winnen?

Als gewoonlijk testen we weer voor 80% de schijven in plaats van controllers.

In de gewone throughput test zie je trouwens hoe goed die ATA controllers en disks (op 2/3 van het toerental) het doen. Troughput die hoger ligt dan de SCSI uitvoeringen. En denk eraan dat de controller hier een heel grote invloed op heeft, omdat de parity data met deze snelheid berekend wordt.

De RocketRAID heeft geen CPU aan boord, en wordt dus niet door deze CPU begrensd. Vandaar dat deze als enige tegen de 450MB/s haalt. Maar als er ook data geschreven wordt, moet deze het snel afleggen door gebrek aan cache, en door het gebruik van de host CPU, bus en memory voor de parity berekeningen.

Verder heeft elke SATA disk afzonderlijk beschikking over de volle 150MB/s bandbreedte, de disken op dezelfde SCSI bus moeten de 320MB/s "eerlijk delen". Met 8 schijven is dat 40MB/s per schijf.

[trogdor]

Waar wou jij 15k rpm (S)ATA schijven vinden dan?

[Femme]

Men had 10K SCSI-schijven kunnen gebruiken. Met deze grote aantallen schijven zal de bottleneck overigens eerder bij de RAID-controller dan bij de harde schijven liggen. Dat is ook wel te zien in de resultaten, die sterk verschillen per controller.