RAID 0 a legegyszerűbben

Az elmúlt hónapokban többször is foglalkoztunk a háttértárak sebességének témakörével, márpedig ez egy olyan kérdés, amit érdemes minél jobban körbejárni. Hosszú és részletes, az SSD-k természetével foglalkozó cikkünkben megállapítottuk, hogy az SSD a jövő. Az 500 GB-os merevlemezek tesztelése során rádöbbentünk, hogy még az azonos áron kapható, szimpla HDD-k sebessége között is nagy lehet a különbség. Végül bemutattuk a WD legújabb VelociRaptorát az SSD alternatívájaként. Bármennyire is hihetetlenül hangzik, szerintünk továbbra is igaz az az állítás, miszerint napjaink PC-iben a háttértárnak sokkal nagyobb figyelmet kéne szentelni, mint azt a legtöbben gondolják, hiszen egy elavult mechanikus alkatrészről van szó, ami a számítógép más alkatrészeihez viszonyítva borzasztó lassú. Az SSD sajnos túl drága, így a többség számára luxus. A VelociRaptor sem éppen olcsó, ráadásul nem is annyira gyors, tehát felmerül a kérdés, hogy ilyenkor mi a teendő? A kicsit is bátrabbak erre azt fogják felelni, hogy RAID 0. De valóban a RAID 0 a megoldás?

A RAID 0, más néven csíkozás/sávozás (striping) már majdnem olyan szinten osztja meg az olvasókat, mint egy AMD vs. Intel vagy egy ATI (azaz AMD) vs. NVIDIA vita. A RAID 0 mellett korteskedők annak egyértelmű előnyét szeretik kiemelni: a sebesség megduplázása. Az ellenzők általában az adatok biztonsága miatt aggódnak, nem beszélve a zajszintről, a hőtermelésről és a rezonanciáról. Ráadásul meg vannak arról győződve, hogy a RAID 0 csak a szekvenciális elérés sebességét növeli, így aztán éppen arra használhatatlan, amire az otthoni PC-knek szüksége lenne, vagyis a rendszerlemez szerepére, ahol a véletlenszerű elérés a fontos. A RAID 0-t kétségkívül csak és kizárólag a sebesség növelése érdekében érdemes használni, ezért a legfontosabb kérdés az, hogy ezen a téren mit nyújt. A következő oldalakon új tesztelési módszerünkkel fel fogjuk térképezni a RAID 0 erősségeit és gyengéit egy átlag PC-s szemszögéből; előtte azonban lássuk, hogy mi is az a RAID 0.

A RAID 0 alapvetően az adatok párhuzamos feldolgozásán alapul, ami a számítástechnika világában egyáltalán nem újkeletű (ahogy maga a RAID 0 sem az). Gondoljunk csak a többmagos processzorokra, a többcsatornás memóriavezérlőkre vagy a több videokártya sebességét "egyesítő" CrossFire-re és SLI-re, de már ide sorolhatjuk az SSD-ket is. A RAID 0-s tömbök sebessége azért magasabb az egyetlen egyedülálló háttértárolóénál, mert a RAID-vezérlő a felírt adatokat több kisebb részre bontja, majd szétteríti a tömb elemei, azaz a háttértárolók (HDD, SSD) között. Ebből következik, hogy a RAID 0 tömb sebességét két faktor befolyásolja. Egyrészt a tömb elemeinek a száma, ami teljesen logikus, hiszen minél több elemből, azaz háttértárolóból épül fel a tömb, annál többfelé oszlanak a felírt adatok. Például egy két merevlemezből felépülő tömb elvileg lassabb, mint egy négy HDD-s tömb. A tömb szélessége, azaz a tárolók száma pénz- és toleranciafüggő.

A második fontos szempont az úgynevezett sávméret vagy csíkméret (angolul stripe size), ami meghatározza, hogy az adatokat a merevlemezek között mekkora darabkákra "szelje fel" a vezérlő. Az alaplapi vezérlők esetében a csíkméret általában 2 kB-tól 128 kB-ig változtatható; ezt a tömb létrehozása során kell beállítani, később csak az adatok megsemmisülése árán változtathatjuk meg. Egyszerűen szólva: ha a sávméretet 4 kB-ra állítjuk, akkor a vezérlő egy 8 kB-os fájlt a két merevlemez között kétfelé oszt el (4+4), egy 1 MB-os fájlt viszont 2 x 512-felé (2 merevlemez, 128 db 4 kB-os csík). Ellenben ha a sávméret 128 kB, akkor a szóbanforgó 8 kB-os fájl csak a RAID-tömb egyik elemére íródik fel (hiszen a 8 kB kisebb, mint a 128 kB), ugyanakkor egy 1 MB-os fájl 2 x 4-felé "oszlik" (2 merevlemez, 4 db 128 kB-os csík). Ebből látható, hogy a csíkméret komoly mértékben befolyásolja a teljesítményt, hiszen az első esetben a nagy, 1 MB-os fájl felírásához túl sok írási műveletre van szükség, míg a második esetben nem csak hogy a helyet pazarolja a kis fájl, de elméletben még csak gyorsulásról sem beszélhetünk, hiszen csak egyetlen merevlemez dolgozik, legalábbis a felírásnál. Olvasásnál ugyanakkor általában egymás után sok kis fájlt kell beolvasni, és ilyenkor jól jöhet a kettő vagy több, egymástól független merevlemez.

Mint az látható, nem létezik ideális sávméret: minél kisebb, annál több, kisebb darabra darabolódnak a felírt fájlok. Ez elméletben jól hangzana, ha a RAID-tömböt rendszerlemezként szeretnénk használni, a gyakorlatban viszont mégsem olyan jó, mert így több fejpozicionálásra van szükség. Minél nagyobb a sávméret, annál kevesebb, nagyobb darab fájlrészletet találunk az egyes merevlemezeken. Ez egyes esetekben helypazarlásnak tűnik, de talán ez a legkisebb gond manapság, hiszen az 1-2 TB-os merevlemezek már nem olyan drágák. Ráadásul, ha egyidejűleg több kisfájlos olvasási kérelem érkezik a vezérlő felé, azt jobban ki tudják szolgálni a merevlemezek, mert egyenként 1-1 fájlt tárolnak (feltételezve, hogy 128 kB-os csíkméretről beszélünk, és a fájlok kisebbek, mint 128 kB), így egyszerre, párhuzamosan annyit képesek beolvasni, ahány eleme van a tömbnek.

Tesztkörnyezet

Nincs is más hátra, mint tesztelni! Alapvetően olyan tesztet szerettünk volna készíteni, ami két kérdésre is választ ad. Egyrészt tudni szeretnénk, hogy egy RAID 0 tömb mennyivel gyorsabb, mint egy önálló merevlemez. Másrészt kíváncsiak voltunk arra is, hogy a VelociRaptort bemutató cikkünkben szereplő merevlemezek RAID 0-ban hogyan viszonyulnak egymáshoz. Ez első hallásra igen egyszerű kérdés, hiszen gondolhatnánk azt is, hogy az a HDD lesz a leggyorsabb RAID-ben, amelyik önmagában is a leggyorsabb volt, és valószínűleg a sorrend is hasonlóan alakul majd. A valóságban azonban erről szó sincs: egyes merevlemezek RAID-re optimalizált firmware-rel kerülnek forgalomba, és ez kihatással lehet a végeredményre. Hogy ez az optimalizálás a sebesség szempontjából pontosan mit takar, azt nem tudjuk, de pl. a Western Digital Black Editionje tud olyat, amit a Blue és a Green nem, gondoljunk csak a StableTrac-re (vibrációtűrés). Az egyes gyártóknak léteznek direkt RAID-re "kiképzett" merevlemezei, ilyen a WD Caviar RE, a Seagate Barracuda ES (újabban Constellation ES) vagy a Hitachi UltraStar A7K1000, ezek általában jobban bírják a strapát, hosszabb garanciát vállal rájuk a gyártó és drágák. Mi csak azokat a HDD-ket teszteltük le RAID-ben, amelyeket már bemutattunk; ezek szimpla, asztali PC-be szánt merevlemezek, amiket az átlagfelhasználó is megengedhet magának, eleve a tesztkörnyezet is erre lett kialakítva, és nem szerverek esetében használatos programokat vizsgáltunk.

A sok teszteredményre való tekintettel kicsit megbolondítottuk a grafikonokat. Az alapgrafikonokon a RAID tömbök sebességét ábrázoltuk, azonban ha az egérkurzort a grafikonok fölé mozgatjuk, akkor a szingli merevlemezek sebességét látjuk majd viszont. Ez így talán áttekinthetőbb, mintha egy grafikonon ábrázoltuk volna az összes egymagában álló merevlemezt és az összes RAID-tömböt, ami legalább 19 csíkocskát jelentene. Mindkét grafikonon a RAID-tömbök által elért eredmények alapján állítottuk be a sorrendet, tehát így egyszerűen és közvetlenül összehasonlítható a merevlemezek és az adott típusból kialakított RAID-tömbök sebessége is.

A HDD-ket a szokásos, P55-ös chipset köré épülő, korszerűnek mondható számítógépen teszteltük, ennek csak a windowsos használat közben mért eredményekre lehet kihatása. A leglényegesebb tulajdonsága ezen konfigurációnak azonban a SATA 3 Gbps kompatibilis ICH10-es déli híd (pontosabban P55 PCH). Ezt most RAID módban használtuk, és az Intel Rapid Storage Driver 9.6.0.1014-et telepítettük fel. A HDTune tesztek lefutását követően minden RAID-tömböt 4 kB-os clustermérettel formáztunk meg.

A RAID beállítása és a csíkméret hatása

A RAID egyesek számára még mindig misztikum, pedig egyáltalán nem egy olyan technológia, amitől félni kellene. A beállítása is pofonegyszerűnek mondható. Miután az alaplapra rácsatlakoztattuk a kettő vagy több, RAID-tömb létrehozásához szükséges merevlemezt, a BIOS-ban a SATA-csatoló módját RAID-re kell állítani (általában IDE, AHCI és RAID szokott itt szerepelni). Ehhez persze olyan alaplapra lesz szükségünk, amely támogatja a RAID-et (az AMD, az Intel és az NVIDIA már évek óta). Ezután elindul a gép, és egy billentyűkombináció lenyomásával (Intel chipsetes alaplap esetén a CTRL+I) beléphetünk a RAID-konfiguráló menübe. Ez egy karakteres képernyő, ahol a legalapvetőbb műveleteket végezhetjük el (RAID-kötet létrehozása, törlése). Ezeknek a gyártóknak létezik Windows alatt is használható RAID-konfiguráló szoftverük, mint pl. a már említett Intel Rapid Storage driver.

A RAID-mód és a RAID-tömb elemeinek kiválasztása [+]

Ezt elindítva a létrehozás menü alatt állítsuk be, hogy melyik RAID-módot szeretnénk használni. Mint látható, a P55 PCH a RAID 0 (összefűzés), 1 (tükrözés), 5 (blokkszintű összefűzés körbeforgó paritásrendszerrel) és 0+1 (összefűzés és tükrözés) módokat támogatja. Mi egyszerűen csak a RAID 0-t szeretnénk használni, ezért ezt választottuk. A tovább gombra nyomva kiválaszthatjuk, hogy mely lemezek legyenek a RAID tömb elemei, itt a program felsorolja az összes alaplapra csatlakoztatott háttértárat. A kötet méretét is beállíthatjuk, ha ez kisebb, mint a kettő vagy több HDD mérete összesen, akkor "short stroke"-ról beszélhetünk. Ez akkor lehet érdekes, ha előre tudjuk, hogy mekkora helyre lesz szükségünk, a vezérlő így a merevlemezeknek csak a külső pereméhez legközelebb álló területét fogja használni, ami mindig gyorsabb, mint a belső perem. Végül beállíthatjuk az adatcsík/adatsáv méretét, ami 2 és 128 kB közötti érték lehet. A kötetszintű gyorsítótár engedélyezésével felgyorsulhatnak az írási műveletek, ugyanis a merevemez helyett a rendszermemóriába (ami sokkal gyorsabb) íródnak az adatok, és csak egy későbbi, "nyugis" időpontban íródnak fel a lemezekre. Ez persze áramszünet esetén nem éppen szerencsés, mert az összes adat elveszhet, tehát érdemes jól meggondolni a használatát.

Létrehozás [+]

Már csak egy kattintásra vagyunk a RAID-kötet elkészültétől.

És el is készült. Ez alig néhány másodpercet szokott igénybe venni.

A tömb adatai [+]

Ezután megtekinthetjük a RAID-kötet alapvető tulajdonságait, vagy akár törölhetjük azt, ami természetesen az összes a köteten lévő adat elvesztéséhez vezet.

Szerettük volna tudni, hogy a merevlemezeket milyen csíkméret mellett érdemes letesztelni, ezért szintetikus tesztprogramokkal kiteszteltük a 4, 16, 64 és 128 kB-os csíkméreteket két merevlemezen, a Seagate Barracuda 7200.12-n (átlagos HDD) és a WD VelociRaptor 600 GB-os változatán (nem éppen átlagos HDD).

Seagate Barracuda 7200.12 RAID 0 olvasás - 4 / 16 / 64 / 128 kB-os csíkmérettel [+]

Először a HDTune-t futtatuk. A görbék szerint a Barracuda esetében nem lényeges a csíkméret, a minimum, a maximum és az átlag is közel megegyező.

WD VelociRaptor 600 GB RAID 0 olvasás - 4 / 16 / 64 / 128 kB-os csíkmérettel [+]

Ezzel szemben a VelociRaptor görbéi nem teljesen azonosak. 4 kB-os csíkméret mellett nem tudott átlépni a 250 MB/s-os határon, de 16 kB vagy efölött 290 MB/s-hoz közeli tempót tudott elérni. Úgy tűnik tehát, hogy a kis csíkméret visszafogja a szekvenciális tempót ezen a gyors merevlemezen.

Mindezt grafikonon is ábrázoltuk. A Barracuda mind a négy csíkméret mellett közel ugyanolyan gyors volt, a VelociRaptort viszont visszafogták a 4 kB-os sávok. Ugyanakkor az is látható, hogy ez igazából nem volt komoly hatással az átlagra, tehát sokat nem vesztünk vele, ettől függetlenül szekvenciális olvasásnál úgy tűnik, hogy a nagyobb csíkméret a jobb.

Seagate Barracuda 7200.12 RAID 0 írás - 4 / 16 / 64 / 128 kB-os csíkmérettel [+]

De mi a helyzet az írással? Itt már komolyabb eltéréseket sikerült kimutatnunk. A Barracuda 4 kB-os csíkméret mellett maximum 35 MB/s-os tempót tudott elérni, ami siralmas, elvégre ez a HDD egymagában 100 MB/s feletti tempót diktál. 16 kB-os csíkméret mellett már 40 MB/s körül volt az átlag, ami még mindig nagyon alacsony, de 64 kB-os csíkméret mellett megtáltosodott, 200 MB/s környékéről csökkent 125 MB/s-ig; végül kiderült, hogy 128 kB-os csíkméret mellett a leggyorsabb, a görbe itt volt a "legegészségesebb": 240 MB/s-ről indult, és 125 MB/s-ig esett.

WD VelociRaptor 600 GB RAID 0 írás - 4 / 16 / 64 / 128 kB-os csíkmérettel [+]

A csík mérete a VelociRaptor írását is komolyan meghatározza. 4 kB-os mérettel 100-75 MB/s, 16 kB-os csíkokkal 125-100 MB/s, 64 kB-os csíkokkal viszont már 275-175 MB/s, 128 kB-os csíkmérettel pedig közel 300-175 MB/s-os tempót diktál. Ezek a grafikonok a folyamatos, azaz szekvenciális írás sebességét mutatják, és mint azt korábban említettük, minél nagyobbak a blokkok, annál kevesebb darabkára kell felszelni a nagyobb fájlokat, tehát gyorsabb tömbírásban, és ez be is igazolódott.

A grafikon talán jobban érzékelteti a különbségeket, egészen komoly szekvenciális sebességcsökkenéssel kell szembenéznünk, ha túl kicsire állítjuk a csík méretét, erre érdemes odafigyelni. Úgy tűnik, hogy a több ezúttal is jobb.

De mi a helyzet a véletlenszerű eléréssel? Ez az a szempont, amit egy rendszerlemez kiválasztásánál komolyan kell vennünk. Ahogy azt már korábban említettük, a nagy méret itt valószínűleg több előnnyel jár, mint hátránnyal. Hátránya, hogy a csík méreténél kisebb fájlok is a csík méretének megfelelő méretű blokkot fognak lefoglalni, ráadásul ez egyben azt is jelenti, hogy csak egyetlen lemezen lesz megtalálható az adott fájl, tehát a párhuzamosítás ugrott. Ez ugyanakkor egyben az előnye is ennek a beállításnak, ugyanis ez azt jelenti, hogy ha sok kis fájlt kell beolvasni egyszerre, akkor a két merevlemez párhuzamosan képes dolgozni és egy beolvasásnyi idő alatt két fájlt dolgozhatnak fel (feltételezzük, hogy két HDD-ból áll a RAID-tömb). És a mérési eredmények ezt a feltételezést meg is erősítik: a csíkméret növelésével a random olvasás sebessége is nő. Az az érdekes, hogy első ránézésre mérések nélkül talán éppen ennek a fordítottjára tippelne az ember.

Ugyanez elmondható az írásról is. Remélhetőleg az eredmények nem csak az Intel vezérlőjére érvényesek, és az AMD déli hídjai is hasonlóan viselkednek.

A RAID-et ellenzők gyakran azzal érvelnek, hogy a RAID-tömbök elérési ideje nem hogy csökken, de a RAID-vezérlő sebességétől függően még nő is, ebből kifolyólag esélyük sincsen az SSD-kkel szemben, hiszen azok éppen az alacsony elérési időnek köszönhetik félelmetes gyorsaságukat, amikor programok betöltéséről van szó. Ez azonban csak félig igaz. Az egyenlet másik felén a párhuzamosság áll: az SSD-vezérlője úgy működik, mint egy memóriavezérlő: minél több NAND-lapka kapcsolódik hozzá, annál több adatot képes behúzni vagy kiírni. Márpedig ez a RAID 0 egyik előnye is. Például ha azt vesszük, hogy van egy RAID-tömbünk 128 kB-os csíkmérettel, és be kell olvasnunk két, 128 kB-nál kisebb fájlt, akkor a RAID 0 tömb (amennyiben két merevlemezből áll) egy olvasási ciklus alatt mindkét fájlt képes beolvasni éppen úgy, mintha egy két NAND-lapkából felépülő SSD-ről lenne szó, ebből pedig már sejthető, hogy a RAID 0 valóban képes csökkenteni a betöltési időket, az időnyereség azonban attól függ, hogy mennyire terheljük meg a tömböt, hiszen minél inkább, annál valószínűbb, hogy a két HDD optimális kihasználtsággal tud működni (lásd fentebb az olvasási grafikont).

HDTune, IOMeter, IPEAK

A szintetikus benchmarkok sora nálunk összesen három programból áll: a HDTune-ra, az IOMeterre és az IPEAK-re esett a választásunk. A HDTune kifejezetten HDD-k tesztelésére jó (és nem SSD-kre), mert képes grafikonon ábrázolni az adott merevlemez szekvenciális, azaz folyamatos olvasási és írási tempóját a külső peremtől a belső körig. Mint tudjuk, a HDD-k kívülről befelé lassulnak, ezért ez egy fontos infó lehet. Alapvetően az átlagsebesség itt irreleváns, csak mint a grafikon sorbarendezési elve van értelme ábrázolni. Sokkal fontosabb a maximális és a minimális olvasási/írási tempó. A szekvenciális olvasás/írás kap szerepet nagyobb fájlok másolásánál, illetve esetleg még videószerkesztésnél, éppen ezért rendszerlemez-választásánál ez csak egy másodlagos szempont.

A RAID tömbök csatájában az új VelociRaptor győzött, de ez a tesztek 100%-ára igaz, tehát ezzel a kérdéssel nem érdemes tovább foglalkozni; érdekesebb kérdés, hogy a 7200 rpm-es HDD-k miként viszonyulnak egymáshoz. A Samsung F3 ahogy önmagában, úgy RAID-ben is tarolt, de a Hitachinak sincs miért szégyenkeznie. A szekvenciális elérés a RAID 0-nak nagyon fekszik, ezért itt az egyedülálló merevlemezekhez képest minden esetben 80-90% körüli volt a gyorsulás; ennél többet nem nagyon várhatunk.

Írásban nagyon hasonló a sorrend, itt a 150 GB-os VelociRaptor kicsit feljebb kapaszkodott, míg az SSD az utolsó helyre csúszott. Erről azonban tudni kell, hogy egy 64 GB-os változatot teszteltünk, márpedig általánosságban elmondható, hogy minél nagyobb az SSD mérete (kapacitása), annál gyorsabban ír, a 128 GB-os Indilinx vezérlős SSD-k kb. 200 MB/s-re képesek. A Seagate 7200.12-ese itt már elég rendesen lemaradt, az egytányéros WD Blue viszont feltört, ettől függetlenül a Samsung F3-asa és a Hitachi 7K1000.C a nyerő.

A véletlenszerű elérési sebesség mérésére az IOMetert használtuk. A programmal létrehoztunk egy 10 GB-os tesztfájlt a merevlemez "legelején" (külső peremén), és rászabadítottunk egy 2 perces, véletlenszerű 4 kB-os olvasásokból, majd írásokból álló löketet először 4, majd 64 konkurens lekéréssel. Hogy pontosan mit is jelent ez? Az operációs rendszert használva alapvetően a kis fájlok olvasási sebessége határozza meg, hogy milyen gyorsnak érezzük majd a rendszert. A Windows/Linux által eltárolt információk és a különböző feltelepített programok fájljai általában jóval kisebbek, mint 1 MB, átlagban mondhatjuk, hogy 4 kB-osak, vagy ha nem is a fájlok, akkor a szükséges információk (regisztrációs bejegyzések, pluginek, dll-ek, scriptek stb.) ekkora csomagokban érkeznek. Ezek mindenfelé "szétszórva" találhatóak meg a fájlrendszerben, éppen ezért, ha az oprendszer sebességéről van szó, akkor az a mérvadó, hogy a HDD/SSD milyen sebességgel képes beolvasni ezeket a picike kis adatcsomagocskákat, és ennek lemérésére hivatott a véletlenszerű 4 kB-os olvasási/írási teszt. Az, hogy 4 vagy 64 konkurens lekérésről van szó, csak annyit jelent, hogy egyidejűleg mennyi lekérés érkezik a HDD/SSD felé. Elmondható, hogy egy otthoni PC-n az esetek túlnyomó többségében maximum négy, tehát egyszerre négyfelé kell adatot továbbítania a HDD-nek vagy az SSD-nek (leegyszerűsítve vegyük azt, hogy pl. a Windows olvas a lapozófájlból, közben olvas két másik helyről, miközben a böngésző cache-ből is olvasás folyik). A 64 egyidejű lekérés már egy kirívó eset egy asztali számítógép esetében, általában azért szokták lemérni, hogy lássák, mire képes az adott HDD/SSD akkor, ha pl. adatbázist tárolnak rajta (ott könnyen elképzelhető, hogy 64 felhasználó egyszerre szeretne megszerezni valamilyen adatot).

Röviden és tömören: ha rendszerlemezt szeretnénk vásárolni, akkor azt figyeljük, hogy ebben a tesztben (elsősorban olvasásban) mit teljesít a kiszemelt winchester QD=4-es beállítás mellett.

Ebben a tesztben az egyedülálló merevlemezek sorrendjét látjuk viszont RAID 0-ban is, a VelociRaptorok 10 000-es fordulatszám mellett verhetetlenek (ebben a mezőnyben), a 7200-asok között a WD Caviar Black a nyerő 334 GB-os tányérokkal, őt pedig a Seagate 7200.12 követi. Érdekes látni, hogy a QD=4-es beállítás mellett (QD, azaz Queue Depth, tehát egyidőben beérkező lekérések száma) sokkal kevesbé gyorsul a RAID-tömb az egyedülálló merevlemezhez képest, mint QD=64 mellett. QD=4 mellett 50% körüli a gyorsulás mértéke, míg QD=64 mellett már több esetben 100%, azaz megduplázódott. Nem véletlen, hogy a RAID elsősorban a szerverekben használatos, a különböző hibajavító technológiákkal és redundanciával karöltve gyors és biztonságos rendszereket lehet vele kiépíteni.

Írásban szinte ugyanez a sorrend alakult ki. Itt az egyidejű lekérések száma nem változtat lényegesen a képen, a gyorsulás ezesetben is 80-100% körüli. A véletlenszerű írás alapvetően nem olyan fontos, mint az olvasás, csak ne legyen túl lassú, mert az megérződik (lásd JMicron-vezérlős SSD-kkel kapcsolatos problémák), ugyanakkor ha gyors, az sem baj persze, de nem lényeges.

Aki olvasta korábbi HDD-s tesztjeinket, az valószínűleg emlékszik még az IPEAK-re. Ez egy Intel által még 2000 előtt fejlesztett program, amivel rögzíthetjük egy adott számítógépben található merevlemez(ek) által elvégzett műveleteket. Ahhoz hasonlítható, mintha kamerával felvennénk, miközben dolgozunk a gépen, csak ez a program nem a monitor képernyőjén történő eseményeket jegyzi fel, hanem azt, amit a háttértár művel, méghozzá szektorról szektorra, így azt később visszajátszva letesztelhetjük, hogy egy másik háttértár milyen gyors ebben az adott, előzőleg elmentett szituációban. Ezzel lényegében egy komplett géphasználatot rögzíthetünk és tesztelhetünk. A program legnagyobb baja az, hogy már régi, ezért csak a Windows XP-vel kompatibilis. A fórumozók véleményei alapján összehoztunk egy olyan - úgymond - teszt-scriptet (kamerafájlt), amivel rögzítettük egy átlagos felhasználó mindennapi tevékenységét Windows XP alatt 2 GB memória társaságában. A következő programokat használtuk ezalatt: Total Commander, Firefox, Thunderbird, MSN, Skype, WinAMP, WMP, Word, Excel, uTorrent, Photoshop, a háttérben pedig ESET Smart Security. Dolgozgattunk a gépen, megnyitottunk, elmentettünk ezt-azt, levelet írtunk, olvastunk, kerestünk, chateltünk, táblázatot szerkesztettünk stb., és mindezen tevékenység merevlemezre gyakorolt hatását rögzítette a program. Ezt visszajátszva eredményül kapjuk, hogy másodpercenként hány műveletre képes az adott merevlemez, és minél magasabb ez a szám, annál jobb. Lényegében arra jó ez a teszt, hogy egyfajta támpontot adjon arra vonatkozóan, hogy a winchesterek "érzésre" milyenek egymáshoz viszonyítva Windows XP alatt. Ez elvileg jó lenne SSD-k és HDD-k összevetésére is, de úgy vettük észre, hogy a szekvenciális írás valamilyen okból kifolyólag túlságosan is nagy súllyal bír (vagy csak a sok kis random írást egyszerre egy nagy csomagban írja ki a háttértárra), ezért erre a célra végülis nem tűnik megfelelőnek.

Ez az első tesztprogram, amiben érdekesnek mondható eredmények jöttek ki. A szingli merevlemezek csatájában itt a Seagate és a Samsung volt a nyerő (a Raptorok mögött), a RAID-tömbök erőviszonya viszont teljesen másként alakul. A WD Black alacsony szekvenciális tempója ellenére az élre ugrott, a Seagate pedig lemaradt. Itt a RAID bekapcsolását követő gyorsulás HDD-ről HDD-re változó mértékű volt, a WD Black 46%-kal ért el jobb eredményt, míg a Seagate 7200.12 15%-ot gyorsult; ez elég komoly különbség. Ennek mi lehet az oka? Csak tippelni tudunk: a Seagate a 7200.12-t abszolút nem ajánlja RAID-es felhasználásra, talán a firmware tartalmaz valami olyan beállítást, ami lelassítja, hogy a Barracuda ES-nek is meglegyen a piaca (láttunk már ilyet). Még a WD Blackek között is komoly különbségek vannak, a kéttányéros 00L3B2 csak 18%-ot gyorsult az egytányéros 46%-ával szemben, ami totálisan értelmetlen, bár a WD-től ez nem szokatlan, mert a Caviarok már azonos címkével is sok esetben teljesen eltérő teljesítményt nyújtanak, így semmin sem lepődhetünk meg. Szerencsére az IPEAK is csak egy tesztprogram, minket pedig jobban érdekelnek a stopperrel mért időeredmények.

Windows 7 használat

A valós használatot reprezentáló teszteléshez egy valódi, több hónapos használatot megélt Windows 7-es rendszert használtunk. Ez nem egy sebtiben feltelepített Win7, hanem egy már teleszemetelt, rengeteg feltelepített és uninstallált programot tartalmazó rendszer háttérben futó ESET Smart Securityvel (vírusirtó és tűzfal). Ezt mentettük le a "szektorról szektorra" módszerrel, majd töltöttük vissza a teszt szereplőire; így egyenlő eséllyel indult az összes versenyző. A rendszer teljes mérete kb. 30 GB, ez egy 37 GB-os partíción foglalt helyet, amit azért alakítottunk ki éppen ekkorára, hogy a 40 GB-os SSD-kre is ráférjen a későbbiekben. A hibernáláshoz szükséges hiberfil.sys letörlésével még a 30 GB-os SSD-k tesztelésére is megfelelő. A rendszer lementés előtt töredezettségmentesítve lett, a SuperFetch és a Prefetch pedig be van kapcsolva. Minden tesztet háromszor ismételtünk meg.

A Windows 7 betöltési idejét a post után eltűnő "Boot from CD-ROM" felirattól mértük odáig, hogy teljesen felállt a rendszer, tehát betöltődött az összes ikon, az összes gadget és a tálcára az összes program (ESET, ATI Catalyst Control Center). A WD Blackek a 7200.12-től elszenvedett vereség után RAID 0-ban megemberelték magukat, és az élre ugrottak. Előnyük nem mondható jelentősnek, de mindenképpen érdekes ez a felállás. A Samsung F3 ezúttal sem remekelt. Érdekes látni az egyedülálló lemezekhez képest kimért gyorsulásokat: a Seagate alig 10 mp-et javított az idején, míg a WD Black 23-32 mp-et, ami nemcsak másodpercben, hanem százalékosan is rengeteg. A 150 GB-os VelociRaptorról ugyanezt mondhatjuk el, sokkal többet javított az idején, mint a 600 GB-os változat. Ugyanakkor érdekes látni azt is, hogy az SSD idejét még mindig nem sikerült még csak megközelíteni sem, az SSD még mindig feleannyi idő alatt végez, mint a leggyorsabb HDD RAID 0-ban. Mindenesetre a 40 mp-es eredmény már kiemelkedőnek számít, ez már tényleg az a szint, ami gyorsnak tekinthető, kár, hogy csak a legdrágább merevlemez képes rá.

A "3D-s programcsokor" főleg a kis fájlok elérésére koncentrál, ugyanis ezek a programok rengeteg kis plugint töltenek be, a szekvenciális sebesség nem annyira fontos. A sorrend a bootteszthez képest nem változott, és a gyorsulások mértéke is hasonlóan érdekes képet fest. A Seagate 7200.12 112-ről 78 mp-re csökkentette idejét, míg a WD Black 153 mp-ről 72 mp-re, azaz kevesebb, mint a felére. Egészen hihetetlen.

A "webdesigner programcsokor" már jobban támaszkodik a szekvenciális elérésre, mert a Photoshop és az Illustrator is egy-egy igen nagy méretű dokumentummal együtt nyílik meg. Itt a 7200.12 képes volt megtartani vezető pozícióját, de RAID 0-ban csak épphogy sikerült megelőznie a WD Blackeket, melyek esetében ezúttal is közel felére esett a betöltési idő.

Az "újságírói programcsokorban" ismét a pici fájlok kapnak szerepet; valójában ez a legjellemzőbb a mindennapi használatra, mert itt nem csak a fájlok, de maguk a programok is kisméretűek. A fekete Caviárok itt is rengeteget gyorsultak, elsősorban az egytányéros 00E3A0, amely befogta a Seagate versenyzőjét.

Többen kérték, hogy mérjük le a hibernálás sebességét. Az "újságírói programcsokor" megnyitása után hibernáltuk a gépet, ezek a programok együtt kb. 2 GB memóriát foglalnak. Nos, úgy tűnik hogy ez az első olyan alkalmazás, ahol a RAID 0-ból semmilyen előnyünk nem származik, a RAID-tömbök gyakorlatilag ugyanolyan időeredményeket értek el, mint az önmagában álló HDD-k. Elég érdekes, hogy ez így alakult, mert elvileg kb. 2 GB-nyi adat kiírásáról van szó, ergo itt a szekvenciális sebességnek meghatározónak kéne lennie. Felmerült bennünk, hogy esetleg a memória sebessége fogja vissza az írást, de ez nem lehet, mert a memória sokkal gyorsabb, mint a HDD, vagyis fogalmunk sincs, hogy ez minek köszönhető.

Lemértük a processzortesztekben használatos Photoshop-action lefutási idejét. Ez alapvetően processzortesztekhez lett kialakítva a sok szűrővel, de van néhány ezek között, amelyeknek a hatására a kép kinagyítása után komolyan használódik a lapozófájl, tehát végülis a lapozófájl szekvenciális írása itt a mérvadó. 10-15 másodperccel voltak gyorsabbak a RAID-tömbök, ami teljesen reális, hiszen a Photoshoppal való munka során nem csak és kizárólag a HDD dolgozik, hanem a processzor az elsődleges tényező.

Játékok, virtualizáció, másolás

A játékok betöltési idejének lemérése után érdekes fejleményeket tapasztaltunk. A HDD-k többsége semmit sem profitált a RAID 0 jelenlétéből. Még a Team Fortress 2 sem, ami egyértelműen "háttértárfüggő", elég csak az SSD időeredményére pillantani. Azon kívül, hogy a játékok betöltését elsősorban a CPU-ereje határozza meg, itt valószínűleg komoly szerepet játszik az elérési idő is, amiben az SSD utcahosszal vezet, ugyanakkor a RAID-tömb semmivel sem jobb, mint egy HDD. Főleg Far Cry 2 alatt csökkentek a betöltési idők, míg a Seagate 7200.12-ese TF2 alatt még lassult is, miután RAID 0-ban hajtottuk őket. Elég valószínű, hogy a Seagate szándékosan fogja vissza a 7200.12 sebességét, másképp nem mérnénk ki ilyen gyenge eredményeket.

Az fps-tesztben is van egy-két furcsaság, az átlagfps-ekben nincs komoly változás, de a minimumfps-ek egyes esetekben nem hogy nőttek, de még csökkentek is. Könnyen lehet, hogy itt is az elérési idő a ludas, bár ennek ellentmond, hogy a 7K1000.C és a Samsung F3 jobb volt RAID-ben, mint önmagában.

Egy másik ötletből született következő tesztecskénk, ami a virtualizációval kapcsolatos. Aki már foglalkozott otthon virtualizációval, az jól tudja, hogy a winchester rettenetesen lassú tud lenni, ha egynél több VM (virtuális masina) működik. Igazából már egy VM is le tudja "ölni" a gépet, ha telepítünk rá, nem kell ehhez kettő sem, pláne ha a VM a merevlemez "hátsó" 10-20%-án helyezkedik el, ahol a HDD feleolyan gyors, mint a külsején. Készítettünk négy Windows XP-s VM-et, és beütemeztük rajtuk, hogy egyidőben indítsák el a .NET Framework 3.5 telepítését. Teljesen lényegtelen, hogy miért éppen ezt telepítettük fel, ennél fontosabb infó, hogy ez a teszt alapjában véve a merevlemezek véletlenszerű és kis részben szekvenciális írási sebességét teszteli, méghozzá igen hatékonyan. Itt a legmeglepőbb eredményeket a Samsung F3 és a Hitachi 7K1000.C szolgáltatta, az F3 a sor végének közeléből RAID 0-ban az élre ugrott, míg a 7K1000.C ideje RAID-ben kevesebb, mint a felére csökkent. Annyit érdemes tudni erről a tesztről, hogy mindig az utolsóként végző VM idejét szoktuk feljegyezi, ugyanis az esetek túlnyomó többségében a VM-ek nem egyszerre végeznek a telepítéssel. Könnyen lehet, hogy a 7K1000.C esetében a RAID-nek köszönhetően egy szűk keresztmetszet tűnt el miután RAID 0-ba állítottuk, és ennek tudható be a jó időeredmény.

A telepítés után beállítottuk, hogy 0 mp-es időközökkel induljanak el a VM-ek, és lemértük a négy VM együttes bootidejét. Ez a .NET-telepítős teszttel ellentétben a véletlenszerű olvasás sebességét hangsúlyozza ki, ami nem csak a virtualizációnál fontos, de minden másban is, ahol olvasási műveleteket végez a háttértár. Ahogy azt sejteni lehetett, elsősorban a 4 VM-es bootidő csökkent jelentősen, hiszen 1 VM mellett nem kap komoly terhelést a HDD, illetve a RAID-tömb, több VM esetén viszont érvényesülni tud a párhuzamosság elve. A WD Blackek sima győzelmet arattak.

Az AS SSD az egyetlen, a szokásos benchmarkokon kívül alkalmazott tesztprogram, amit beválogattunk. Ezt is csak azért vettük elő, mert van benne egy beépített másolási teszt, amit érdemesnek találtunk a lemérésre, elvégre ez egy olyan dolog, amit otthon az olvasó is le tud tesztelni magának. Amit érdemes tudni: ez a HDD-n belül másol, az ISO-teszt nagy ISO-fájlokkal operál, a Program-teszt sok kis fájllal, a Game-teszt pedig vegyesen. A Samsung F3 7200 rpm-es létére nagyon jól szerepel, az új VelociRaptort szorongatja és mindenki mást elvert. A WD Blackek alacsony szekvenciális tempójuk miatt itt lemaradtak.

Végül először egy "teszt HDD-ről" mérés futott le, aztán egy "teszt HDD-re" telepítést végeztünk el. A telepítő átmásolási ideje RAMDrive-ra (tehát a "teszt HDD-ről") csak minimális mértékben csökkent a RAID-tömbökön, ami megintcsak furának tűnik első ránézésre, de itt szekvenciálisan kis fájlok olvasásáról volt szó, ezért a RAID-tömbök nem tudtak kibontakozni. A RAMDrive-ról való feltelepítésben (tehát a "teszt HDD-re") hasonló a helyzet, itt szekvenciálisan kis fájlok írásáról van szó, amiből a RAID-tömb ezúttal sem tud előnyt kovácsolni (ahogy az SSD sem).

Értékelés

Tehát akkor mi is a helyzet a RAID 0-val? Tényleg felgyorsítja a rendszert? Van értelme ebbe beruházni? Az első kérdésre a válasz egyértelműen igen. A RAID-tömbök sok esetben komoly mértékben fel tudják gyorsítani a rendszert (összehasonlítva egyetlen HDD-vel), gyakorlatilag csak 1-2 példát tudnánk felhozni, amikor nem történt semmi. Az már más kérdés, hogy mekkora a gyorsulás? Hasonlóan a CPU-k és VGA-k világához, itt sem 100%-os a gyorsulás. A szintetikus tesztekben néhol igen, de a valóságban korántsem. Mindenesetre a drága HDD-k és SSD-k mellett van létjogosultsága, már amennyiben az ember nem képes elviselni a szimpla HDD-k sebességét. Ha megnézzük az eredményeket, akkor jól látszik, hogy két WD Black RAID 0-ban az esetek túlnyomó többségében gyorsabb, mint a 600 GB-os VelociRaptor. Ha figyelembe vesszük, hogy emellett még olcsóbb is, és 500 GB-os WD-kkel számolva nagyobb kapacitást kínál, akkor egyértelműen ajánlhatóak. A zajszint itt nem játszik komolyabb szerepet, de egyébként a VelociRaptor egymagában is hangosabb, mint két WD Black, ez utóbbi esetben inkább a számítógépház rezonálására kell odafigyelni (ami kiküszöbölhető).

A RAID-tömbök összevetésének versenyének győztese szerintünk a WD Caviar Black lett. A szingli WD Blackhez képest felmutatott fantasztikus mértékű gyorsulás révén szinte mindenhol az első helyre tudott kerülni. Korábbi tesztjeink alapján meg merjük kockáztatni azt a kijelentést, hogy a WD Caviar Black és a WD Caviar RE4 belsőleg megegyezik, csak a firmware-ben van köztük különbség, tehát szerintünk nem véletlen a WD Black jó szereplése. Ez a típus még a 150 GB VelociRaptort is megfogta. Egyedüli gyengéje a szekvenciális tempó lassúsága, amiben a Samsung SpinPoint F3 lett a nyerő (RAID 0-ról van szó). Igazából annak nincs értelme, hogy külön ajánlgassunk, mert ha nem csak hobbiból, akkor általában valamilyen otthoni meló mellé állítanak RAID-tömböt, és az adott munka határozza meg, hogy melyik paraméter a fontos. A Samsung F3 videóvágáshoz jobbnak tűnik, mint a WD Black, minden másban az utóbbi a nyerő. A merevlemezek csatáját megnyerő Seagate Barracuda 7200.12 ezúttal leszerepelt, ahogy azt már kifejtettük, szerintünk a Seagate valamilyen módon visszafogja a merevlemez teljesítményét RAID-módban, hogy ne szippantsa el a Barracuda ES piacát, na de ennyit az összeesküvés-elméletekről...

Ami az SSD vs. RAID 0 kérdéskört illeti, az SSD továbbra is nyerő. Vicces is lenne, ha nem így lenne, elvégre nem véletlenül ilyen drága ez az alkatrész. De ha ezt a kérdéskört feszegetjük, akkor figyelembe kell vennünk az SSD méretét is, amennyiben videóvágással szeretnénk foglalkozni, ez ugyanis a sebességet és az árat is befolyásolja. Erre a munkára a HDD RAID 0 egyelőre jóval olcsóbb megoldást kínál, igaz, nem olyan halk, nem annyira kompakt, többet fogyaszt és sérülékenyebb is, de ezzel a RAID-et megfontoló felhasználók már tisztában vannak.

Samsung SpinPoint F3 500 GB (HD502HJ) - RAID 0-ban videóvágáshoz
WD Caviar Black 500 GB (WD5001AALS-00E3A0) - RAID 0-ban minden máshoz

fLeSs

A WD Caviarok többségét az Expert Zrt., a Seagate merevlemezeket a Computer Emporium Kft., a Samsung F3-at Gianni bazárja bocsátotta rendelkezésünkre. Az újabb WD Black és Blue merevemezeket az Aqua Electromaxtól kaptuk.

HDTune grafikonok

Hitachi 7K1000.C (500 GB/tányér) RAID 0 olvasás / írás

Seagate Barracuda 7200.12 (500 GB/tányér) RAID 0 olvasás / írás

Samsung SpinPoint F3 (500 GB/tányér) RAID 0 olvasás / írás

WD Caviar Black (334 GB/tányér) RAID 0 olvasás / írás

WD Caviar Black (500 GB/tányér) RAID 0 olvasás / írás

WD Caviar Blue (500 GB/tányér) RAID 0 olvasás / írás

WD VelociRaptor 150 GB (150 GB/tányér) RAID 0 olvasás / írás

WD VelociRaptor 600 GB (200 GB/tányér) RAID 0 olvasás / írás