Bevezetés

Minden bizonnyal már jó néhány, SSD vásárlásán elgondolkozó olvasónk fejében felmerült a kérdés, hogy megérné-e némi felárért cserébe két kisebb meghajtóból összeállítani a számára szükséges tárkapacitást. A merevlemezeknél látottakkal ellentétben a NAND flash alapú meghajtóknál sajnos a tárhellyel szinte lineárisan növekszik az ár, ami röviden az jelenti, hogy egy adott modellből a 128 GB-os verzió nem sokkal kerül kevesebbe, mint két 64 GB-os. Ennek fényében megpróbáltuk kideríteni, hogy van-e értelme egy egyszerű RAID 0 rendszerrel két kisebb meghajtóból összeállítani a kívánt tárkapacitást. Első lépés gyanánt kicsit frissítsük fel a RAID 0-ról szóló ismereteinket!

A RAID 0 az eredeti elnevezéssel (redundant array of independent disks) ellentétben semmilyen redundanciát, azaz biztonságot nem nyújt adataink számára. A RAID ezen módozatát csak és kizárólag az átviteli sebesség növelése érdekében lehet használni. A RAID 0 (striping) alapvetően az adatok párhuzamos feldolgozásán alapszik, ami a számítástechnika világában egyáltalán nem új keletű. 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 felépítésükből eredően még bizony magukat az SSD-ket is ide sorolhatjuk.

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 rendszer 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ő.

SSD – 8 NAND chip 8 csatornára

A második fontos szempont az úgynevezett sávméret vagy csíkméret (angolul stripe size), ami meghatározza, hogy az adatokat a meghajtók között mekkora darabkákra "szelje fel" a vezérlő. Az alaplapi vezérlők esetében a csíkméret általában 4 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. Leegyszerűsítve: ha a sávméretet 4 kB-ra állítjuk, akkor a vezérlő egy 8 kB-os fájlt a két meghajtó között kétfelé oszt el (2 x 4), egy 1 MB-os fájlt viszont 256-felé (2 meghajtó, 128 db 4 kB-os csík). Ellenben ha a sávméret 128 kB, akkor a szóban forgó 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 meghajtó, 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 kis fájloknál elméletben még csak gyorsulásról sem beszélhetünk, hiszen csak egyetlen meghajtó dolgozik, legalábbis a felírásnál. Olvasásnál ugyanakkor általában egymás után sok kicsi, szétszórtan elhelyezkedő fájlt kell beolvasni, és ilyenkor jól jöhet a kettő vagy több, egymástól függetlenül dolgozó drive.

Tesztkörnyezet, specifikációk

Ahogy már a bevezetőből is kiderült, jelen tesztünk elsősorban nem konkrét modellekkel hivatott foglalkozni, hanem sokkal inkább a RAID 0 egy bizonyos irányú létjogosultságát igyekszik vizsgálni. Ennek okán a mérésekhez olyan meghajtókat választottunk, amelyeket korábban már megismertettünk olvasóinkkal. Ez konkrétan a Samsung 830-as család modelljeit takarja, melyből a közelmúltban a 256 GB-os, valamint a 64 GB-os variáns is bemutatásra került.

[+]

SATA 6 Gbps-kompatibilis SSD-s tesztrendszerünkben egy Intel Core i7-2600K próbálja kipréselni a meghajtókból a bennük rejlő potenciált. Most is úgy döntöttünk, hogy a Turbo Boost lehetőségét mellőzzük, mivel a Sandy Bridge processzoroknál a maximális turbó órajel nemcsak fogyasztás, hanem hőmérséklet függvénye is, ezért fennállhatna olyan szituáció, hogy ugyanazon teszt alatt esetleg más órajelen dolgozik a CPU, ami befolyásolhatná az eredményeket. Ezt természetesen nem szeretnénk, így inkább kikapcsoltuk a turbót. Mindezek mellé nem kevesebb mint 16 gigabájt G.Skill RipjawsX DDR3 RAM is betársult, hogy a tesztek alatt egészen biztosan ne fogyjon el a szabad memóriánk sem.

Első körben a két 64 GB-os Samsung SSD került be a rendszerbe. Az alaplap BIOS-ában a lemezvezérlés módját RAID-re állítottuk, majd a külön erre a célra fenntartott, rendszer indulása előtt elérhető menüben 128 kB-os csíkmérettel létrehoztunk egy 128 GB-os RAID 0 kötetet.

Intel RST[+]

Erről gond nélkül tudtuk indítani az operációs rendszert, melyben a feltelepített Intel Rapid Storage alkalmazásában szemügyre vehettük a kötet néhány alaptulajdonságát, valamint kondícióját. Itt kell megjegyeznünk, hogy a TRIM támogatásáról egyelőre le kell mondanunk a RAID rendszerek esetében. Az AMD déli hídjaihoz már létezik megfelelő meghajtóprogram és alkalmazás, mellyel RAID esetében is engedélyezhetővé válik a TRIM, de az Intel chipkészleteihez meg kell várnunk az egyelőre alfa stádiumban lévő Rapid Storage Technology (RST) 11.5-ös, végleges verzióját.

[+]

A bevezetőben már utaltunk arra, hogy az SSD-k felépítése a párhozamosságot tekintve valamelyest hajaz a RAID 0 rendszerekére, mivel az SSD-k vezérlője gyakorlatilag úgy működik, mint egy többcsatornás memóriavezérlő: minél több NAND lapka kapcsolódik hozzá, annál több adatot képes behúzni vagy kiírni. A Samsung 830-as szériában található kontroller 8 csatornás, melyben a 128 GB-os modell esetében négy csatorna aktív (négy NAND chip kapcsolódik hozzá), míg a 64 GB-os esetében mindössze kettő. Az ebből fakadó, sebességet érintő eltérések jól láthatóak a lenti táblázatból.

A NAND chipek számának leginkább az írási tempóra van hatása: a 64 GB-os verzió pontosan feleakkora írási sebességre képes, mint nagyobbik rokona. Ezzel szemben mindez az olvasási tempót már nem befolyásolja ilyen mértékben. Most nézzük, hogy minderre a RAID 0 milyen hatással van!

IOMeter, AS SSD

A szekvenciális olvasás (és írás) a nagyobb fájlok másolásánál kap szerepet, illetve esetleg még videószerkesztésnél; ha rendszerlemezt keresünk, akkor ez csak egy sokadrangú szempont lehet. Ahogy számítottunk is rá, RAID kötetünk itt meglehetősen nagy előnyre szert téve állt az élre, igaz, a duplázástól még elég messze áll ez az eredmény.

Szekvenciális írásnál már majdnem meglett a dupla, az eredmény szinte tizedre megegyezett a 128 GB-os verziónál mérttel.

Véletlenszerű olvasásnál 4 lekérés esetén valamiért kissé visszaesett az eredmény, míg 64 lekérésnél bő 30%-kal nőtt egyetlen 64 GB-os meghajtóhoz képest.

A véletlenszerű írás egy átlagos PC-s felhasználó számára szintén nem túlságosan lényeges. Egy meghajtóhoz képest itt durván 20%-os emelkedésről beszélhetünk, ami messze nem volt elég a 128 GB-os verzió utoléréshez.

A kevés általunk használt benchmark egyike az AS SSD. Ennek is csak a beépített másolási tesztjét használtuk, mert ezt akár otthon az olvasó is le tudja mérni magának. Amit erről érdemes tudni: ez a meghajtó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. Ebben a tesztben szép előnnyel állt az élre az általunk összerakott RAID 0 kötet.

Windows 7 használat

A valós használatot reprezentáló teszteléshez egy valódi, többhónapos használatot megélt Windows 7-es rendszert vetettünk be. Ez nem egy sebtiben feltelepített Win 7, hanem egy már teliszemetelt, rengeteg feltelepített és uninstallált programot tartalmazó rendszer a háttérben futó ESET Smart Securityvel (vírusírtó é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. A rendszer lementés előtt töredezettségmentesítve lett, a SuperFetch és a Prefetch pedig be volt 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). Ez a "teszt" (mondhatnánk inkább használatot is) a véletlenszerű olvasásra koncentrál. Az SSD-k többsége gyakorlatilag szinte ugyanolyan eredményt ért el, illetve az 1-2 másodperces eltérés itt még éppen a mérési hibahatáron belül lehet.

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. Látható, hogy elég hasonló eredményt mutatott fel az öt meghajtó. Ez a teszt sokkal jobban támaszkodik a processzora, mint az SSD-re.

A "3D-s programcsokor" főként 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. Az SSD-k itt is viszonylag közel vannak egymáshoz, ami jelen esetben az Intel 510 kivételével azonos eredményeket jelent.

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. Itt többszöri mérésre is egy másodperccel gyorsabb volt RAID kötetünk egyedülálló rokonainál.

A "webdizájner programcsokor" már jobban támaszkodik a szekvenciális elérésre, mert a Photoshop és az Illustrator is egy-egy, igencsak nagyméretű dokumentummal együtt nyílik meg. Itt szinte csak a gyors elérés a döntő. Ebben az esetben abszolút holtversenyről beszélhetünk a tesztben résztvevő meghajtók között.

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. Már merevlemezes cikkeinkben megjegyeztük, hogy a hibernálás elvileg a szekvenciális írási sebességtől függ (hiszen a memória tartalmát ki kell írni a hiberfil.sys-be), ennek ellenére ismételten csak nagyon kis különbségeket sikerült kimérnünk.

Másolásos tesztek, játékok

A két következő "teszt" (másolás) eredetileg még a SandForce vezérlőinek olykor becsapós teljesítménye miatt született meg. Lemértük, hogy egy már tömörített Windows 7-et tartalmazó képfájl mennyi idő alatt másolódik át a tesztelendő háttértárra. A képfájlokat immáron a 250 GB-os Intel 510-en helyeztük el, ami – ahogy az IOMeter eredményből is látszik – körülbelül 450 MB/s-es szekvenciális olvasásra képes, tehát az SSD-k írási teljesítményét szinte biztosan nem korlátozza.

Míg az IOmeter szekvenciális írásos tesztjében a RAID tömb képes volt hozni a 128 GB-os Samsung tempóját, addig valós másolásban már valamivel lemaradt tőle.

A Batman – Arkham Asylum című játék másolásánál megismétlődött az iménti jelenség.

Tettünk egy próbát a Photoshop telepítőjének RAMDiskre másolásával, ez lényegében az SSD olvasási sebességét méri, hiszen az SSD-ről másolunk a RAMDiskre. A RAID 0 itt egy másodperc előnyt jelentett a többi meghajtóval szemben.

Ezután a RAMDiskről feltelepítettük a Photoshopot, ergo az SSD-k írását teszteltük, de ez felhasználóközelibb mérés, mert egy telepítés idejét mértük le. Az 64 GB-os Samsung kivételével az többi 830-as modell ugyanazt az eredményt produkálta.

A játékbetöltési időkhöz most is a két jól bejáratott játékot használtuk. A különbségek láthatóan az SSD-k között nem túl nagyok. A Samsungok – a RAID 0 kötetet is ideértve – egy mezőnyt alkotnak.

Virtualizáció és végszó

Egy másik ötletből született következő tesztecskénk, ami a virtualizációval kapcsolatos. Aki már foglalkozott otthon a témával, az jól tudja, hogy a háttértár sebessége nagyon sokat számít, 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 egy 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 egy időben indítsák el a .NET Framework 3.5 telepítését. Az installáció témája teljesen véletlenszerű volt, annál fontosabb infó viszont, hogy ez a teszt alapjában véve a merevlemezek véletlenszerű és kis részben szekvenciális írási sebességét teszteli.

Ezen tesztünk már tetszett a RAID 0 konfigurációnak: ha csak egytelen másodperccel is, de még a 256 GB-os modellt is megelőzte a kötet.

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. Ahol egyáltalán mutatkozik különbség, ott is csak minimális. A RAID tömb 4 VM indítása esetén egyetlen másodperccel volt gyorsabb az önálló Samsung SSD-knél.

Végszó

Cikkünk fő kérdése az volt, hogy megéri-e két kisebb SSD-ből összefűzni a számunkra szükséges nagyobb kapacitást. Mindent együttvéve arra jutottunk, hogy egy otthoni átlagfelhasználó jobban jár, ha egyetlen SSD megvásárlásával szerzi meg magának a kívánt tárkapacitást.

Kettő egy ellen [+]

Ennek egyik oka, hogy az esetek többségében a kisebb meghajtók a kevesebb NAND chipnek köszönhetően lassabbak. Ezen felül a RAID 0 összeállítása valamivel költségesebb és macerásabb, mintha csak egyetlen meghajtót használnák. Egyrészt két 64 GB-os SSD még mindig pár ezer forinttal többe kerül, mint egyetlen 128 GB-os, ráadásul két meghajtónak kell helyet, valamint kábelezést biztosítanunk. Ez egyben azt is jelenti, hogy két SATA portot kell feláldoznunk, ami ugyan a legtöbb rendszer esetében nem probléma, de természetesen lehetnek kivételek. Egyelőre Intel chipsetes konfigurációknál a TRIM nem működik, bár erre remélhetőleg hamarosan érkezik a végleges megoldás. Végül, de nem utolsósorban RAID0 esetén (a több meghajtó miatt) magasabb a meghibásodás valószínűsége, ezért könnyebben előfordulhat, hogy búcsút kell intenünk a köteten tárolt összes adatnak.

Oliverda

A 128 GB-os Samsung 830 SSD-t a Samsung magyar képviselete bocsátotta rendelkezésünkre, míg a 64 GB-os Samsung 830 SSD-t az AQUA electromax biztosította.