Bevezetés, SSD-alapok

Az még korántsem állítható, hogy kitört volna az "SSD-láz", de idén február-március környékén már nagyon úgy tűnt, hogy megmozdul valami. Sajnos a forint gyengülése nyomán bekövetkezett áremelkedés szinte azonnal lehűtötte a kedélyeket, pedig bizony már van miről beszélni. Azóta mi is másként tekintünk erre a témára, és bár talán túlzó ezt így kijelenteni, de azt kell, hogy mondjuk, az SSD napjaink egyik legfontosabb, ha nem a legfontosabb PC-s fejlesztési lehetősége. Az igazat megvallva mi ezt egy kicsit későn ismertük fel, ezért utólag is az olvasók elnézését kell kérnünk. Ez így nagyon komolyan hangzik, de pontosan miről is van szó? A PC-s felhasználóknak szánt SSD-k bemutatkozása után jópár tesztet készítettünk a témában, amelyek akkor és ott jónak tűntek, de ezek mai látásmódunk alapján, mai fejjel ha nem is vállalhatatlanok, de mindenképpen hiányosak és néhány esetben félrevezetőek lehetnek. Az SSD-k bemutatásának és tesztelésének nincs túl sok értelme "merevlemezes szemmel" (ahogy mi is tettük) ugyanis ebben a témában egy másfajta megközelítésre, vagyis szemléletváltásra van szükség. De hogy pontosan mire is gondolunk, arról kicsit később.

Az emberek többsége úgy tekint az SSD-re, mint egy szimpla háttértárolóra, amit berakunk a számítógépbe, aztán megy minden, mint a karikacsapás. A valóság azonban korántsem ilyen egyszerű. Egy merevlemez esetén három tulajdonságról érdemes szólni: a fordulatszám, a tányérok száma/mérete és a cache mérete. Általánosságban minél magasabb a fordulatszám, a tányérok mérete és a gyorsítótár, annál gyorsabb a merevlemez. Az SSD-kkel kapcsolatban azonban érdemes szót ejteni a vezérlőkről, a TRIM-ről vagy az azt helyettesítő algoritmusról, illetve a wear levelingről, a szabad kapacitásról, az operációs rendszer beállításáról és a későbbi használatról is. A fórumokat olvasgatva észrevettük, hogy a többség ezekkel a problémákkal nincs tisztában, és a fórumozók még az a kisebbség, aki fogékony és érdeklődik a különböző témakörök iránt, tehát a passzív többség valószínűleg még ennyire sincs képben. Ha van is némi fogalmuk, akkor is állandó jelleggel felmerül a mit, miért és hogyan kérdés, ezért úgy döntöttünk, hogy készítünk egy laza, kérdezz-felelek stílusú, könnyebben érthető, hétköznapi nyelven íródott összefoglalót a témáról, ami remélhetőleg megválaszol majd minden kérdést. Lesznek már korábban megfogalmazott, de most a könnyebb érthetőség kedvéért újra leírt kérdéskörök is.

Mi is az az SSD?

Egy olyan háttértároló, ami a merevlemezekkel ellentétben memória alapú. A merevlemezekben mágnesezhető réteggel bevont lemezek találhatók, ezeket író-olvasó fejek írják és olvassák, így lényegében mechanikus szerkezetűek. A fejek mozgatását halljuk, amikor a winchester ír/olvas. Az SSD-knek két fő részegysége van, ezek a (memória)vezérlő és a NAND chipek. A NAND chipekre tekinthetünk úgy is, mint sima memóriachipekre, ilyeneket találunk pl. a pendrive-okban is. Az SSD-ben nincs mozgó alkatrész, ezért hangtalan.

Milyen típusú SSD-k léteznek? Mit kérjek a boltban?

Erre az lenne a felületes válasz, hogy kétféle: SLC (single-level cell) és MLC (multi-level cell), azonban az SSD-ket a vezérlő típusa alapján is kategorizálhatjuk. A merevlemezeket általában a tányérok forgási sebessége alapján különböztetjük meg: "kérek egy 7200 rpm-es WD/Hitachi/Seagate/stb. winchestert". Az SSD-ben nincs tányér, nincs forgási sebessége, ezért egy ilyen kérdésnek nem lenne értelme. De annak sincs sok értelme (átlag PC-s szemszögből), hogy SLC-s vagy MLC-s SSD-t kérjünk az eladótól, ugyanis ezeken a kategóriákon belül is számtalan választási lehetőségünk van, ami a vezérlő típusától függ.

Mi az SLC és az MLC?

Az SSD-kben található memóriachipek SLC- vagy MLC-alapúak lehetnek. Egy kézzelfogható memóriachip (gondoljunk egy pendrive belsejében lévő chipre, eredeti nevén NAND-flashre) részegységekre bontható le. A legnagyobb részegység a "plane", ami az esetek többségében 512 MB adatot tárol. Egy plane általában 1024 blokkból épül fel, melyek egyenként 512 kB méretűek (tehát 1024 x 512 kB = 524288 kB). Egy blokk általában 128 darab 4 kB-os page-re (lapra) osztható fel (128 x 4 kB = 512 kB), a page-ek pedig cellákat tartalmaznak, melyek 1-3 bit tárolására képesek. Az SSD-kben az SLC (single-level cell) cellánként egyet, az MLC (multi-level cell) jelenleg az esetek túlnyomó többségében cellánként kettőt tárol.

Miért jó/rossz az SLC és az MLC NAND?

Az SLC adott területen kevesebb adatot, egészen pontosan cellánként 1 bitet képes eltárolni, ennek következtében gyorsabb, mert a cella értéke gyorsabban megállapítható, ráadásul hosszabb az élettartama, mint az MLC-é. Mindezen okokból kifolyólag drágábban adják, mint az MLC-t. Az MLC az olcsóbb típus, a hétköznapi felhasználóknak szánt változat, amit a gyártók úgy értek el, hogy az MLC-alapú chip kisebb területen több adatot képes tárolni (1 cella = 2 bit), ebből kifolyólag lassabb, és hamarabb megy tönkre.

Na várjunk csak! Miért lassabb és miért tart rövidebb ideig az MLC?

Igencsak leegyszerűsítve a választ azért lassabb, mert időigényesebb kiolvasni vagy újraprogramozni a pontos értékeket (1 helyett 2 bit). Élettartama pedig azért rövidebb, mert mint említettük, cellánként 2 bitet tárol. Íráskor a cellák fáradnak, a flash-memória már csak ilyen. Ha egy cella 2 bitnyi adatot tárol, akkor az írási műveletek is gyakoribbak az adott cellán. Ennek köszönhető, hogy az SLC-alapú SSD-k esetében 100 000, az MLC-alapú SSD-k esetében pedig 10 000 írási ciklus élettartamot adnak meg a gyártók. Ezek megközelítő értékek, tehát valójában csak az arányokat hivatottak szemléltetni.

Miként is kell ezt elképzelni egy hétköznapi példával szemléltetve?

Az azért remélhetőleg már nem újdonság, hogy az adatokat kettes számrendszerben tároljuk (0 vagy 1). Az SLC cella 1 bit tárolására képes, tehát az értéke 0 vagy 1 lehet, míg egy MLC-cella 2 bitet tárol, így értéke 00, 01, 10 és 11 között váltakozhat. Gondoljunk egy pohár vízre. Az SLC esetében vagy teli van a pohár, vagy üres. Az MLC esetében ezen felül lehet harmadig és kétharmadig is. Utóbbi esetben nehezebb megállapítani a víz mennyiségét, tehát emiatt lassabb az MLC.

Visszatérve a korábbiakra, a vezérlő típusa is fontos. Erről mit érdemes tudni?

Az SSD-ben található vezérlő - amit nevezhetnénk akár memóriavezérlőnek is, hiszen memóriát vezérel - ugyanolyan fontos paraméter, ha nem fontosabb az SSD sebességére és élettartamára nézve, mint az, hogy milyen típusú NAND memóriára épül az SSD. Elég csak az alaplapokon, illetve újabban a processzorokban található lapkakészletekre gondolni, nagyon sok múlik azon, hogy ezek miként kezelik a rendszermemóriát. Ugyanez a helyzet az SSD vezérlőjével is. Ez a vezérlő vezérli az adatok olvasását és írását, és vannak jobban és kevésbé jól sikerült vezérlők. Ezenkívül az élettartam vonatkozásában is sok múlik a rajta, és ezzel el is érkeztünk a wear levelinghez.

Wear leveling

Wear leveling? Az mi?

Magyarra lefordítva valahogy úgy lehetne megfogalmazni, hogy az elhasználódás kiegyenlítéséért felelős algoritmus, azaz módszer. Mint azt említettük, a cellák csak bizonyos számú írást képesek elviselni, az MLC NAND 10 000-et, az SLC 100 000-et (megközelítőleg, arányaiban). Biztosak lehetünk benne, hogy az SSD idővel írhatatlanná válik, de ha már tudjuk ezt, akkor jó lenne, ha az egész SSD "felülete" egyidőben, azaz minél később válna írhatatlanná, és nem különböző időpontokban. A wear leveling algoritmus ezért felel. Léteznek jobb és rosszabb algoritmusok. A jót onnan lehet felismerni, hogy a valós, általunk okozott adatforgalmon túl nem ró túl nagy terhet a cellákra (write amplification).

A wear leveling önkényesen írkál az SSD-re?

Muszáj neki. Ha van három cellánk (az egyszerűség kedvéért mindegyik 1 bitet tárol) amelyek 100 000 írást képesek elviselni, akkor meg kell oldani, hogy mindhárom cella egyidőben váljon használhatatlanná, pontosabban azt, hogy ne legyen köztük olyan, amelyik hamarabb elhasználódk. Ha az első kettő tovább tart, mint a harmadik, akkor nem beszélhetünk optimális működésről, viszont a kiegyenlítéshez adatok átmozgatására van szükség. Tegyük fel, hogy nincs wear leveling. Az első cella egy bizonyos ideig egy adott, statikus információt tárol, míg a másodikon és a harmadikon folyamatosan változnak az adatok (dinamikus). Ez wear leveling nélkül azt jelentené, hogy a második és a harmadik cella bizonyos számú írásciklussal előrébb jár az elöregedésben, mint az első cella, tehát hamarabb válik használhatatlanná. Ezt ki kell egyenlíteni, ennek érdekében a wear leveling úgy tárolja az információt, hogy mindhárom cella egyidőben váljon írhatatlanná. Az SSD-k esetében el kell felejteni azt a belénk rögzült képet, amit a töredezettségmentesítő programokban látni, amikor a merevlemezt szeretnénk optimalizálni, az SSD nem úgy működik, mint a HDD, hogy a tányér külső peremétől befelé íródnak fel az adatok, hanem az SSD vezérlője szétszórja az adatokat "mindenfelé", pontosabban lehetőleg egyenletesen a NAND-ok között. A wear leveling egyébként problémákat is felvethet, amikor már nem három celláról, hanem több gigabájtnyi adatról van szó.

Gondoljunk csak bele, veszünk egy 100 GB-os SSD-t, ezen mondjuk kb. 60 GB statikus adatot tárolunk. (A statikus adat olyan adat, amit nem változtatunk meg szinte soha, pl. operációs rendszer fájljai és a használt alkalmazások/programok fájljai (Program Files könyvtár) illetve a többi.) Wear leveling nélkül egy idő után szimplán elhasználódik a 40 GB szabad hely, és még az is valószínűtlen, hogy mindez egyszerre következik be. A maradék 60 GB ugyan továbbra is használható marad, de így már nem beszélhetünk 100 GB-os SSD-ről. Valójában erre a kérdésre kétféle megoldás létezik (egyelőre), ezeket a dinamikus és a statikus wear leveling névvel illették.

A dinamikus wear leveling mindig csak a szabad terület, azaz a statikus adatokon túl található terület épségét felügyeli, ahol dinamikusan változó adatok találhatók. A fenti példából kiindulva csak a 40 GB szabad tárhely elhasználódásának a kiegyenlítésére figyel. Sebesség szempontjából ez ideális, hiszen mivel a statikus adatokkal nem kell törődnie, csak nagyon ritkán van munkája és olyankor sem sok. Élettartam szempontjából viszont ezt csak alternatív megoldásként tartják számon, mert miután elhasználódik a dinamikus adatokhoz használt terület, csak a maradék használható tovább, de ez már nem ugyanakkora méretű SSD.

Napjaink SSD-i (legalábbis a többségük) statikus wear levelinget használ. Mint az a nevéből talán kitalálható, ez azt jelenti, hogy az algoritmus a statikus adatokat is folyamatosan mozgatja. Ez azzal az előnnyel jár, hogy az SSD teljes felülete egyidőben válik írhatatlanná, viszont az a hátránya, hogy magának az algoritmusnak a működése plusz terhet ró a cellákra, illetve a sebességet is csökkentheti. A kérdés csak az, hogy mekkora ez a teher, tehát mennyi plusz írással számolhatunk. Ez két tényezőtől függ, egyrészt magától az algoritmustól, másrészt attól, hogy mennyi szabad terület található az SSD-n. Az Intel állítólag elérte, hogy ez az úgynevezett "overhead", tehát hozzáadott írás (write amplification) csak a valós írás 10%-át érje el (1,1x-es szorzó); ez elméletben egy nagyon alacsony szám, ami jó, hiszen ez azt jelenti, hogy tovább "élhetnek" a cellák. Szintén az Intel szerint a kezdetleges SSD-k vezérlői esetében akár 2000%-os, azaz 20x-os adatmozgatással is számolhatunk a nem éppen ideális esetekben.

Ez enyhén szólva is hihetetlen. Mégis hogyan kell ezt elképzelni?

Vegyünk egy olyan szélsőséges példát, amiben egy SSD-t majdnem "csurig" megtelítünk, pl. egy 50 GB-os SSD-re 48 GB statikus adatot írunk fel. Tegyük fel, hogy a maradék 2 GB helyen az operációs rendszer és a böngésző ideiglenes fájljai találhatóak, amelyek folyamatosan frissülnek, cserélődnek. A statikus wear leveling nem hagyhatja, hogy a 2 GB "szemét" tárolását végző cella gyorsabban használódjon el, mint a maradék 48 GB statikus adat tárolását végző cella, ezért a háttérben megpróbálja eltolni a 48 GB adatot, tehát lényegében egy közel teljes SSD-nyi, 48 GB adatot fog áthelyezni. Persze ezt nem úgy kell elképzelni, hogy egy temp-fájl törlése/létrehozása után meg kell várni, amíg 48 GB adat elmozdul. Az SSD ezt a háttérben végzi (jó esetben olyankor, amikor nincs terhelés alatt a vezérlő); a 2 GB üresnek vélt cellamennyiséget (a dinamikus adatok "alatt") ide-oda tologatja az SSD felületén, így a cellák elhasználódása az SSD egészén egyenletes lesz.

Az SDD kapacitása és lassulása

Akkor ettől lassul az SSD, és a cellák is használódnak?

Pontosan. Az ilyen szélsőséges eseteknek két komoly hátulütője van, egyrészt az "overhead", az adatok háttérben való folyamatos mozgatása lassít(hat)ja magának az SSD-nek a működését, másrészt a cellák védelméért munkálkodó wear leveling egyúttal tulajdonképpen csökkenti a cellák élettartamát, de erről nem tehet, egyszerűen így működik az algoritmus.

Tehát igaz az, hogy az SSD-k idővel hajlamosak lelassulni új állapotukhoz képest és ez áll a háttérben? Mit tehetünk?

Igen, ez az egyik ok. Egyetlen dolgot tehetünk: minél több helyet hagyunk szabadon az SSD-n. A fejlesztők kiszámolták, hogy az SSD felhasználható területének 20-25%-át (tehát egy 100 GB-os SSD-t feltételezve kb. 20-25 GB-ot) szabadon hagyva jelentősen kitolhatjuk az SSD élettartamát. Mi ezt inkább úgy mondanánk, hogy ha ennél több adatot tárolunk rajta, akkor jelentősen megrövidítjük az élettartamát... Persze az előbbi jobban hangzik, ami a gyártók szempontjából fontos. A szabad terület megnövelésének kettős hatása van. Egyrészt arányaiban nézve kevesebb az elmozgatnivaló adat, másrészt több szabad terület áll a wear leveling rendelkezésére, tehát a cellák elhasználódásának a kiegyenlítésére ritkábban kerül sor. Minél több adatot tárolunk, annál gyakrabban lesz szükség a cellákon található adatok újrarendezésére.

Ezek a cégek ott vernek át minket, ahol akarnak... Nem tettek semmit annak érdekében, hogy megelőzzék ezt?

A cégek két dolgot tehetnek. Az egyik megoldás valójában nem a gyártók érdeme, ez inkább más okokra vezethető vissza. Mint tudjuk, a merevlemezek gyártói 1024 helyett 1000-es szorzót használnak a winchesterek méretének megállapításánál, tehát pl. egy 1 TB-os merevlemez 1024 x 1024 x 1024 x 1024 byte helyett 1000 x 1000 x 1000 x 1000 byte-ot képes tárolni, ebből következően egy 1 TB-os merevlemez valójában a formázás után csak ~930 GB-osnak mutatkozik az operációs rendszer felé. Az 1024-es értékkel való számolás csak a memóriáknál maradt meg, ez pedig az SSD-kre is kihatással van, hiszen az SSD is memóriákra épül. Egy 40 GB-os SSD valóban 40 GiB-nyi (40 x 1024 x 1024 x 1024 byte) NAND flash területtel rendelkezik, de ebből csak 37,2 GiB-ot (ami 40 GB) lát az operációs rendszer. Az SSD kis tokjában megtaláljuk az 5 darab 8 GiB-os NAND chipet, tehát nem veszett el semmi, csak éppen mi, illetve maga az operációs rendszer nem férhet hozzá ahhoz a maradék 3 GB-hoz. Ezt a területet "spare area"-nak, vagyis tartalékterületnek nevezik, és az SSD vezérlője takarékoskodik vele, az előzőleg részletezett okok fényében már érthető is, hogy miért. Általánosságban igaz, hogy minél nagyobb méretűnek adják el az SSD-t, annál nagyobb ez a tartalékterület, de százalékban mérve 10% körül/alatt marad. Egy itthon kapható 64 GB-os SSD-n 59 GB az általunk felhasználható terület, a maradék 5 GB a tartalékterület, és így tovább. A tartalékterület a wear levelingen kívül az elhasználódott cellák cseréjére is jó. Ez nem egy fizikailag elkülönített terület, egyszerűen a vezérlő így működik.

A másik megoldás az, ha maga a gyártó korlátozza az SSD-n felhasználható terület méretét, ezzel egyrészt meghosszabbítja az SSD életét, másrészt kitolja a teljesítmény degradálódásának időpontját. A tartalékterület mérete egyes újabb SSD-ken elérheti akár az összes NAND-flash közel 30%-át is, ami azt jelenti, hogy egy 64 GiB-nyi NAND-ot tartalmazó SSD-t 50 GB-osként árulnak, miközben formázás után már csak 46,6 GB adatot tárolhatunk rajta. A felhasználó az árlistában egy 50 GB-os SSD-t lát, tehát ezzel ilyenformán nincs baj, csak éppen ezeket az SSD-ket még a többieknél is drágábban adják éppen emiatt, mert több NAND-ot tartalmaznak, mint amit ráírnak a dobozra.

Mindebből az következik, hogy az SSD-k botrányosan magas ár/kapacitás aránya még annál is rosszabb, mint azt hittük?

Ez így igaz, de később még erre is kitérünk, mert szerintünk rossz felfogás uralkodik ezen a téren.

Az SSD belassulásának milyen más okai vannak még?

Egészen pontosan egy van, és az is csak az írást érinti, ráadásul ki is küszöbölhető, ennek megértéséhez azonban némi háttérismeretre van szükség. Amikor letörlünk egy fájlt a merevlemezről, az valójában nem törlődik a winchesterről. Annyi történik, hogy az operációs rendszer azt a "területet" (szektorokat) megjelöli felülírhatóként. Az adatok ott maradnak a HDD-n, de bármikor felülírhatóak. Egy merevlemeznek nem okoz gondot egy adat felülírása, semmiféle hátránya nem származik ebből, azonban az SSD-k működése más. Az SSD csak üres lap(ok)ra (4 kB-os egységek) írhatja fel az új adatokat, az érvénytelen adatokat tartalmazó lapok pedig ottmaradnak a helyükön, amíg szükség nem lesz a szabad területre. Ráadásul létezik mégegy korlátozás, ami további problémát jelent: az SSD csak egy komplett blokk (512 kB, azaz 128 darab 4 kB-os lap) törlésére vagy felülírására képes.

Ez nem hangzik túl jól... Pontosan mi is történik?

Egy új SSD-vel még semmi gond nincs. Rámásolunk egy 4 kB-os fájlt az SSD-re, a vezérlő ezt simán beírja egy üres blokkba vagy egy nem teljesen üres blokkba egy üres lapra, és meg is volnánk. A probléma akkor kezdődik, amikor az új, felírandó adatokat előzőleg törölt lapokat tartalmazó blokkokba kell bemásolnia. Ebben az esetben már nincs lehetőség a szimpla írásra, újraírásra van szükség. Ebben a helyzetben az SSD-nek először ki kell olvasnia a blokk (128 x 4 kB) tartalmát (1-es pont). Ezt betölti a gyorsítótárba (2-es pont), a gyorsítótáron belül kitörlődnek a nem kellő lapok (3-as pont), az új adatok beíródnak a blokkba (4-es pont), majd a cache tartalma felíródik a NAND memóriára (5-ös pont). A lényeg tehát: 4 kB-nyi adat írásához az SSD-nek egy beolvasás/módosítás/kiírás ciklust kell végrehajtania, ráadásul az eredeti adatmennyiség (4 kB) sokszorosával, egészen pontosan 512 kB-ot olvas be, aztán 512 kB-ot ír ki. Mondanunk sem kell, ez jelentősen le tudja lassítani az írási műveleteket, hiszen az eredeti adatmennyiség sokszorosának írására van szükség, és akkor még ott van a wear leveling is, ami tovább súlyosbítja a problémát.

Sokszor 4 kB írásával ez egy valóságos rémálommá válik, igaz? Mit tehetünk ellene?

Sokszor 4 kB írása rendkívül leterheli az SSD-t, amennyiben nem használjuk a TRIM-utasítást. A TRIM szócskáról valószínűleg már majdnem minden SSD iránt érdeklődő hallott. A TRIM elvileg egy konkrét SATA utasítás, ami jelzi a vezérlő felé, hogy az adott adat valóban törölhető. Ha az SSD vezérlője tudja, hogy az adat törölhető, akkor felszabadíthatja a TRIM nélkül csak felülírhatóként megjelölt területeket, ennek következtében pedig az új SSD sebességével folytatódhat az írás. Hiszen mi is történik? Letöröljük egy 4 kB-os lap tartalmát. TRIM nélkül az előzőekben taglalt módon ez valójában nem törlődik, csak felülírhatóvá válik. Ellenben ha az operációs rendszer elküldi a TRIM-parancsot az SSD vezérlőjének, akkor az SSD azonnal tudni fogja, hogy erre az adatra már nincs szükség, és azonnal törlődik a lap tartalma (valós időben), így később, amikor egy 4 kB-os adat írására kerül sor, már nem kell az egész blokk tartalmát beolvasni, a cache-ben módosítani, majd visszaírni, hanem szimplán egy lap beírására korlátozódik a műveletek "sora".

A TRIM-ről bővebben

Vajon a TRIM használata is csökkenti az SSD élettartamát?

Ezen töprengtünk egy darabig. Ha a TRIM csak egy szimpla utasítást takar, akkor valóban ez a helyzet. Tegyük fel, hogy egy blokkon belül egyesével töröljük a lapok tartalmát. Egy TRIM nélküli SSD ugye nem tesz semmit, a törölt lapok szimplán megjelölődnek újraírhatóként, majd amikor ide akar később írni az SSD, akkor a teljes blokkon lefut az olvasás-módosítás-írás "kombináció", de a lényeg, hogy az egyes lapok törlésénél nem használódik a NAND.

Ellenben ha bekapcsoljuk a TRIM-et, akkor a blokkon belül minden laptörlés után komplett blokk olvasás-módosítás-írásra van szükség, ergo elméletben a 128 lapból álló blokk akár 128 db blokkot képes egy írási ciklussal öregbíteni, ha be van kapcsolva a TRIM, ha csak egyenként töröljük a lapokat belőle. Ezt szándékosan nyilván senki nem akarja, de nem tudhatjuk, hogy az operációs rendszer, illetve az SSD-vezérlője mit művel a háttérben.

Tegyük fel, hogy van 128 darab 4 kB-os fájlunk, és ezek pont ráférnek egy blokkra. Kitörlünk egy 4 kB-os fájlt. TRIM nélkül a 4 kB-os terület (lap) felülírhatóvá vált, vagyis a vezérlő megjelölte felülírható területként. Ennek köszönhetően lesz később lassabb az SSD, amikor arra a területre írni szeretnénk, mert a szimpla lapírás helyett először ki kell törölni a felülírható lapot. A TRIM használata mellett viszont kiolvasódik a komplett blokk, mind a 128 db fájl, a cache-en belül módosul a blokk (kitörlődik belőle a 4 KB-os fájl), aztán újraíródik a blokk, vagy méginkább egy másik (wear leveling), már ha van rá lehetőség.

Ezek alapján a TRIM csökkenti az SSD élettartamát, azonban egyes források szerint a TRIM-et nem egy szimpla parancsként kell értelmeznünk, hanem több funkció gyűjtőneve, melyek a sebesség maximális szinten tartásán felül az érvényes és érvénytelen adatok kategorizálását is elvégzik, és így nem csökkentik az élettartamot. Hogy pontosan mi az igazság, azt nem sikerült kiderítenünk...

Mi a helyzet akkor, ha az SSD nem támogatja a TRIM-et?

A piacon kaphatóak TRIM-et nem támogató SSD-k is. Ezek vagy az első generációs, 2008-ban és azelőtt megjelent típusok, vagy a nemrég bemutatott Toshiba-vezérlő köré épülnek (a vezérlőkről később), amelyek a TRIM helyett/mellett (egyelőre nem tudjuk biztosan) egy belső optimalizációt tartalmazó algoritmust használnak, és a TRIM-től függetlenül képesek a maximumon tartani az SSD írási sebességét.

Intel SSD Toolbox

Az a helyzet, hogy a TRIM-et az SSD-n kívül az operációs rendszernek, sőt még az alaplapi drivernek is támogatnia kell. A TRIM parancsot ugyanis az operációs rendszer küldi el a SATA-meghajtóprogram felé, majd az továbbítja az SSD felé. Jelenleg csak a Windows 7 és a Windows 2008 R2, illetve a Linux 2.6.33-as kernele támogatja. A Windows Vista és Windows XP tulajoknak, illetve a korábban kiadott kernelre épülő Linuxot használóknak más megoldást kell találniuk. Erre hivatottak a különböző "garbage collector" (GC), azaz szemétgyűjtőként ismert programok, mint amilyen az Intel-féle SSD Toolbox vagy az Indilinx-vezérlős SSD-khez írt wiper, illetve a Linuxos wiper.sh, az erre épülő DiskTRIM és a hdparm. A GC-programok általában az SSD felülírhatóként megjelölt területeit írják teli FF-fel (255-ös érték), így létrehoznak egy akkora fájlt amekkora az SSD-n található szabad terület, majd letörlik azt, így gyakorlatilag megtisztítják az SSD "felületét". Ez a megoldás lassú és körülményes, mert a programot manuálisan kell futtatni, de még mindig jobb, mint a semmi.

Indilinx Wiper Tool

Egy TRIM-et támogató SSD egy TRIM-et támogató operációs rendszer alatt a gyorsformázással is "megtisztítható", persze ez értelemszerűen letöröl minden más adatot is, tehát nem lesz népszerű a használata.

SSD beüzemelése, TRIM parancs beállítása

Beszéljünk a gyakorlatról is! Az SSD beüzemelése kapcsán mire kell odafigyelni?

Konkrétan a beszerelés és bekapcsolás során semmire, ugyanúgy kell eljárni, mint egy merevlemez esetében. Viszont érdemes szólni az operációs rendszer beállításáról, jó pár dolog van, amit érdemes észben tartani.

Először is a BIOS-ban a SATA vezérlőjének módját állítsuk AHCI-ra, ugyanis a TRIM parancsot csak az AHCI meghajtóprogram képes továbbítani. Ha a Windowst előzőleg IDE módban telepítettük fel, akkor sincs gond. Windows Vista/7 operációs rendszerekhez töltsük le ezt a regisztrációs fájlt, Windows XP-hez pedig ezt használjuk. A Windowst IDE módban elindítva importáljuk be a regisztrációs fájlt a Windowsba. Windows XP alatt az innen letölthető fájlt másoljuk be a Windows/System32/Drivers könyvtárba (az XP-s megoldás csak Intel chipsetes alaplapokkal működik), majd indítsuk újra a gépet. A BIOS-ba lépve ezután a SATA módot kapcsoljuk át AHCI-ra, így el fog indulni a Windows, és feltelepíthetjük a déli hídhoz letölthető SATA drivert.

Ha a telepítéssel megvagyunk, Windows 7/2008 R2 alatt ellenőrizzük, hogy az operációs rendszer elküldi-e a TRIM utasítást. Ehhez parancssorban írjuk be, hogy "fsutil behavior query disabledeletenotify". Ha a visszaadott érték 0, akkor jó, viszont ha 1, akkor be kell kapcsolni a TRIM-et, ehhez az "fsutil behavior set disabledeletenotify 0" parancsot használjuk, ezután már működnie kell. Fontos hangsúlyozni, hogy ez a beállítás még nem jelenti azt, hogy a TRIM valóban működik. A Windows egy TRIM-et nem támogató SSD-nek vagy HDD-nek is elküldheti a TRIM utasításokat.

Mindezek előtt vagy akár után ellenőrizhetjük, hogy a maga az SSD támogatja-e a TRIM-et. Jópár diagnosztikai program áll a rendelkezésünkre, ami képes ezt kijelezni, az egyik legegyszerűbb és leggyorsabb megoldás a CrystalDiskInfo-t használni. Ha a "Supported Features" (támogatott funkciók) lista végén feketével szerepel a TRIM, akkor az SSD támogatja a TRIM-et.

SSD írási sebessége, ha be van kapcsolva a TRIM

Innentől kezdve nincs más tennivalónk, a TRIM működik. Ennek leellenőrzésére két mód létezik, egy gyors és egy lassú. A gyors módszer keretein belül teszteljük le az SSD írási sebességét valamelyik benchmarkkal (AS SSD, CrystalDiskBench, Atto, HDTune stb.), majd írjuk teli az SSD-t, aztán írjuk teli újra, hogy a tartalékterület (spare area) is biztosan megteljen. Ha ezután letörlünk mindent, és újra lemérjük az SSD sebességét, akkor az első méréssel megegyező eredményeket kell kapnunk. A lassú módszer a következő: mérjük le az SSD sebességét, majd használjuk "normálisan" pár hétig/hónapig, végül újra teszteljük le. Az előtte és utána mért írási sebességeknek egyeznie kell.

SSD írási sebessége, ha nincs bekapcsolva a TRIM

A fórumokban visszatérő kérdés, hogy bár az SSD biztosan támogatja a TRIM-et, az előtte és utána mért sebességek mégsem egyeznek meg, az utóbbi lassabb szokott lenni. Hogy ez minek köszönhető, az egy jó kérdés, és mi sem tudjuk. A TRIM elvileg valós időben tisztítja az SSD-t, tehát az elvileg nem képzelhető el, hogy még léteznek felülírhatóként megjelelölt lapok/blokkok, és emiatt az írás a NAND-terület egyes helyein lassabb, mint kéne. Az ilyen problémával szembesülők általában a szabad hellyel is okosan gazdálkodnak, tehát a wear leveling "overhead"-je is kizárható, röviden és tömören: fogalmunk sincs. Várjuk a megoldást a fórumba!

Most, hogy már működik a TRIM, mire érdemes még figyelni?

Lassan a testtel! Egyáltalán nem biztos, hogy a TRIM működik. Két probléma van. Az egyik az AMD AHCI-drivere: ez még mindig nem támogatja a TRIM-et (az 1.2.0.164-es verzió biztosan nem). A második a RAID tömbökbe rendezett SSD-k: ezek sem támogatják a TRIM-et. Az elsőre van megoldás, a másodikra egyelőre nincs. A Windows 7 saját maga által felkínált és feltelepített AHCI-drivere támogatja a TRIM-et és így használható AMD lapkakészletes gépeken is. Az Intel nemrégiben adta ki az első olyan driverét (Rapid Storage Driver 9.6), ami szintén támogatja a TRIM-et (akár RAID-módban is), de csak az egyedülálló, tehát nem RAID-kötet részeként használt SSD-ken. Az RST 9.6 előtti verziói nem támogatják a TRIM-et!

Ha a SATA driver kérdésén is túlléptünk, akkor jön egy újabb érdekesség, az úgynevezett "alignálás".

Partíció kezdetének eltolása

Mi az az "alignálás"?

Az "alignálás" a magyarosított "partition alignmentből" származik, pontosabban így rövidítik a fórumozók. Magyarra lefordítva a partíciók helyes eltolásáról van szó. A következő a helyzet: a Windows 7 előtt kiadott operációs rendszerek és a különböző, particionálással foglalkozó programok egy merevlemez felparticionálásánál 63 szektornyi helyet biztosítanak az MBR-nek (Master Boot Record). Ez a terület az első partíció (általában C:) előtt található. Lényegtelen, hogy mi is ez, a lényeg, hogy az első partíció elé 63 szektor kerül. 1 szektor 512 byte, tehát 63 szektor egyenlő 32 256 byte-tal, ami 31,5 kB. Ennyi hely marad a merevlemez kezdete és az első partíció kezdete között. Mint tudjuk, az SSD-ken a legkisebb olvasható/írható részegység a lap, ami (általában) 4 kB méretű. Ha az első partíció kezdete 31,5 kB-nál található, akkor az azt jelenti, hogy egy 4 kB-os adat kiírása miatt sok esetben két lapot kell majd kiírni/felülírni az SSD-n (ami egyben akár egész blokkok frissítését is magával vonhatja), és az SSD-k írásának mennyiségét jobb ha csökkentjük, mint ha növeljük. De ez nem csak az élettartamra nézve rossz, hanem a sebességre is hatással van, elvégre két darab 4 kB-os lap írása/felülírása biztosan lassabb, mint egyé.

Hogyan lehet leellenőrizni, hogy hol kezdődik az első partíció?

Windows alatt indítsuk el az msinfo32 nevezetű programot (parancssorba: msinfo32), majd az Összetevők/Tárolás/Lemezek almenüben található "Partíció kezdetének eltolása" mellett található értéket osszuk el 4096-tal (azaz 4 kB-tal). Ha a kapott érték egy egész szám, akkor a partíció jó helyen kezdődik, azaz az SSD-n található 4 kB-os lapok írásával nem lesz probléma. Az emberek többsége (Windows XP alatt biztosan) itt 7,875-ös értéket fog kapni, mert a 63 szektorral eltolt partíció nem megfelelő egy SSD szempontjából.

Hogyan állítható át a partíció kezdetének helye?

Ennek sajnos csak fájdalmas megoldásai léteznek, már amennyiben előzőleg adatokat tároltunk az SSD-n, ugyanis a partíció kezdetének eltolása megsemmisíti az összes korábban tárolt adatot hiszen a háttértárat újra kell partícionálni. Windows 7/2008 R2 alatt a Vezérlőpult/Felügyeleti eszközök/Számítógép-kezelés/Lemezkezelés almenüben szimplán töröljük a partíció(ka)t, majd hozzuk létre újra őket. Ez a két operációs rendszer 2048 szektoros, azaz 1 MB-os eltolást alkalmaz, ami megfelelő az SSD-k és a RAID-tömbök számára egyaránt (ugyanis a RAID-tömbök particionálásánál is érdemes erre odafigyelni). Windows XP/Vista alatt szintén törölni kell a partíció(kat), majd a diskpar nevezetű programot kell használnunk. A Lemezkezelő alatt jegyezzük fel, hogy a particionálni kívánt meghajtónak mi a számjele (Lemez/Disk 0, 1, 2 stb.), majd a parancssorba írjuk be, hogy "diskpar -s x" ahol x a meghajtó számjelölése. Ezután kétszer "Y"-t kell nyomni (yes), majd be kell írni a partícióeltolás mértékét, itt a 2048 megfelelő, azonos a Windows 7/2008 R2 által használttal. Ha ezzel elkészültünk, gyorsformázzuk az SSD-t, és már készen is vagyunk.

A Windows 7/2008 R2 telepítője egy teljesen új, particionálatlan SSD-t a telepítés során jól fog beállítani, tehát emiatt nem kell aggódnunk.

Mi a helyzet akkor, ha egy régebb óta használt rendszert szeretnék átmozgatni az SSD-re?

Ha egy már meglévő, használt rendszert szeretnénk átpakolni, akkor oda kell figyelni a partícióeltolás mértékére, ezt a kérdést ugyanis a különböző "backup" szoftverek másként kezelik. Ha a rendszer lementésére használt program felkínálja az MBR visszaállítását, akkor azt ne válasszuk ki, csak abban az esetben, ha az eltolás mértéke már az operációs rendszer eredeti helyén is jól volt beállítva (a reklámozás szándéka nélkül annyit sikerült kiderítenünk, hogy az Acronis True Image és a Drive Snapshot jó erre a célra).

Windows beállítások

Van még valami, amit tudnunk kéne?

Hogyne, még nincs vége a "mókának". Mivel az SSD-k működése teljesen eltér a merevlemezekétől, érdemes jó néhány Windows-specifikus problémára odafigyelni; itt különböző funkciók ki-, illetve bekapcsolására gondolunk.

A Prefetch és a Superfetch kikapcsolása

Az SSD-nek nincs szüksége a töredezettségmentesítésre, a prefetch-re, a SuperFetch-re és az indexelésre. Valójában a töredezettségmentesítés, amit a legfontosabb és mindenképpen ajánlott kikapcsolni (a Windows 7/2008 R2 elvileg így is tesz, ha SSD-re telepítjük), mert egyrészt az SSD minden egyes adathoz azonos sebességgel fér hozzá (tehát nem áll fenn a merevlemezeknél megszokott probléma), másrészt a töredezettségmentesítés azon kívül, hogy felesleges, még öregíti is az SSD-t, hiszen sok kis írási/olvasási műveletről van szó.

A töredezettségmentesítés kikapcsolása

Ezt a négy funkciót mindenképpen érdemes kikapcsolni. Ezeken felül létezik jó pár olyan beállítás, melyek használata vagy kikapcsolása hitvita tárgyát képezi. Ilyen például a lapozófájl, a rendszervisszaállítás és a hibernáció letiltása/áthelyezése, illetve a böngészési előzmények és a felhasználói változói értékek áthelyezése merevlemezre. Elvben ezek kikapcsolása az SSD élettartamát hivatottak meghosszabbítani. A rendszervisszaállítást értelemszerűen csak akkor kapcsoljuk ki, ha nincs rá szükségünk. Ugyanez igaz a hibernációra, egy notebooknál ez korántsem egyértelmű. A lapozófájl az igazi mumus: sokak szerint kell, mások szerint nem. Egyesek csak azért kapcsolják ki, mert nincs rá szükség, mi ezt nem tudjuk sem megerősíteni, sem cáfolni, inkább nem nem kapcsolnánk ki, hiszen valószínűleg nem véletlenül találták ki, belefuthatunk olyan programba, ami igényelni fogja. Viszont érdekes kérdés, hogy jelentősen csökkenti-e az SSD élettartamát. Egy Windows 7-tel foglalkozó Microsoft mérnöki blogban írtak szerint nem érdemes kikapcsolni/áthelyezni, sőt valójában az SSD-nek fekszik a lapozófájl használata, mert az írások inkább a nagyobb méretű, szekvenciális tartományba esnek, és végülis nem babusgatni vesszük a hardvert, hanem használni szeretnénk.

Tapasztalataink szerint a böngészési előzmények áthelyezése merevlemezre vagy RAM-diskre valóban megfontolandó, mert a böngészés közben rengeteg miniatűr kis fájlocska töltődik le a gépre melyek egy nap alatt elérhetik akár az 1 GB-os mennyiséget is (aktivitástól függően), és ezek szinte 100%-ban kis fájlok, tehát erősen rövidíthetik az SSD élettartamát.

Egyetlen fontosabb funkció bekapcsolását érdemes még megemlíteni, ez pedig az Eszközkezelő/Lemezmeghajtó/SSD-meghajtó neve ablakban a "Házirendek" fül alatt a "Windows írási gyorsítótárhoz tartozó puffer ürítésének letiltása az eszközön" bepipálása; ez az írási műveleteket hivatott felgyorsítani. Ezeken kívül léteznek még más, a regisztrációs adatbázis buherálását igénylő kis "tweak"-ek, melyek elvileg a sebességet és az élettartamot hivatottak kitolni, de egyik sem igazán lényeges.

Elhasználódás a gyakorlatban

Mindezek után miért venne bárki is SSD-t, miközben állandóan arra kell figyelni, hogy mikor mennyit írunk rá, macerás a használata, ráadásul ennyire drága? Nem tűnik úgy, mintha jó üzlet lenne...

Ez egy jó kérdés. Elsőként tisztázzuk az SSD élettartamával kapcsolatban megfogalmazódó aggodalmakat. Ugye az már világos, hogy az SSD-gyártók, pontosabban fogalmazva a NAND-chipek gyártói (Intel, Samsung, Toshiba stb.) az MLC NAND-ok esetében 10 000, az SLC NAND-ok esetében 100 000 írási ciklusnyi élettartamot határoznak meg. Az azért sejthető, hogy ez csak egy hozzávetőleges arányszám. Elképzelhető, hogy egy MLC NAND már 7000 írás után bedobja a törülközőt (de az sem lehetetlen, hogy 10000-nél tovább bírja), szóval ez alapján a kép még rosszabbul fest, mint azt eredetileg gondoltuk. Számolgassunk egy kicsit, hogy ez végül mennyit is jelent:

Vegyünk alapul egy 100 GB-os MLC SSD-t. Miután már jó ideje SSD-t használunk a szerkesztőségi munkához, tudjuk, hogy egy átlagfelhasználó napi 10-15 GB írással számolhat, de ez egy eléggé felülbiztosított értékhatár, általában jóval 10 GB alatt van ez az adatmennyiség, de mondjuk legyen 15 GB (nyilván akkor, ha nem videóvágásra használjuk). Mit is jelent ez? Ebből már egész egyszerűen kiszámolható, hogy meddig fog kitartani az SSD. Napi 15 GB írással számolva az SSD összes cellája 6,66 naponként telik meg, tehát 10 000 írási ciklussal ez 66 600 napot, azaz 182 évet jelent. Természetesen nem ilyen egyszerű a helyzet. Számoljuk hozzá a járulékos, vagyis be nem tervezett költségeket, tegyük fel például, hogy SSD-nk (pontosabban a cellák) 10 000 helyett csak 5000 írási műveletet képes elviselni, ezután írhatatlanná válik. Így a 182 év azonnal feleződik. A napi 15 GB nyers íráshoz hozzá kell adni a wear leveling adatrendezgetéséből adódó "overhead"-jét (write amplification), ami az Intel szerint kb. 10%, de számoljunk mondjuk 25%-kal, így a napi 15 GB írás valójában 18,75 GB-ot jelent, és már "csak" 73 évnél tartunk. Sajnos még ez sem teljesen igaz, mert ez a végeredmény azt feltételezi, hogy állandó jelleggel szekvenciálisan írjuk az SSD-t, ami sokkal kevésbé megterhelő, mint a véletlenszerű írás.

Az Intel egyik prezentációjából kiderül (azért hivatkozunk állandóan az Intelre, mert ők tudják, hogy mit beszélnek, ráadásul más cégek nem készítettek ezekhez hasonló statisztikákat), hogy egy belépőszintű szerverben használatos 160 GB-os Intel X25-M 15 és 370 TB közti írást képes elviselni, minél több a random írás, annál kevesebbet. Elég komoly a kontraszt. Egy adatbázist tároló MLC-alapú SSD - ami folyamatos igénybevételnek van kitéve - az egyik véglet 15 TB-tal, és egy "boot meghajtó", kvázi asztali számítógépbe vett SSD a másik (370 TB). Rosszindulattal vegyük a két érték közepét, azaz 190 TB-ot, és az jön ki, hogy 1900 írásciklusnyi időnk van hátra, tehát az SSD kb. 28 évig fogja bírni. Most őszintén, hol lesznek ezek az SSD-k 28 év múlva? De hogy az elméleti számolgatás helyett életszerű példával szolgáljunk, az általunk használt SSD 3 hónap használat után kb. 1100 GB-nyi írást rögzített, ez felszorozva 1,25-tel 1375 GB 3 hónapra levetítve, ami kb. 5,5 TB évente. 190 TB-tal számolva ez azt jelenti, hogy kb. 34,5 évet bír majd az SSD, de ha ennek a felhasználónak megelőlegezünk napi 30 GB-írást (15 GB helyett) még akkor is 17 évről van szó, és ez már tényleg közelít az elképzelhető legrosszabb eshetőséghez... Hol lesznek a mai hardverek 17 év múlva? Sehol...

Összegezve mindezt, szerintünk az élettartammal kapcsolatos aggodalmakat kicsit túllihegik az emberek.

Az Intel X25-M leírásában az áll, hogy 5 évet bír napi 20 GB írással terhelve. Most akkor mi az igazság?

Az Intel 5 év/napi 20 GB-os értéke minimumként szerepel a leírásban, ráadásul ez nem is konkrétan az élettartamra vonatkozik. Ezek az adatok a OEM-gyártók részéről felállított követelmények, ez volt a feltétele annak, hogy az Apple/IBM/Dell/stb. SSD-ket építsen a számítógépekbe.

Egy notebook esetében napi mondjuk négy-ötszöri hibernálás mit jelent az élettartam szempontjából?

Napi öt hibernálás 4 GB memóriával számolva maximum 20 GB adat, ráadásul szekvenciális írásról van szó, ami jót jelent, hiszen ez kevésbé terheli a cellákat. Ha ehhez hozzáadjuk az igencsak maximális napi 15 GB-nyi munka közben keletkező írást, akkor napi 35 GB-nál tartunk, ez a fenti számolás szerint kb. 15 éves élettartamot jelent. Azt azért hozzátennénk, hogy efféle használatra már ajánlatos a nagyobb, legalább 64 GB-os SSD-k környékén nézelődni, mert a statikus adatok megléte miatt egy kisebb SSD-n rendkívüli módon megnövekedhet a wear leveling adatmozgatásából következő adatmennyiség, ez pedig nem csak az élettartam, de a teljesítmény szempontjából is negatívum. Például egy 40 GB-os, formázás után 37 GB adat tárolására képes SSD pl. 20 GB statikus adattal, napi 35 GB írással már komolyan leterhelődik, ebben az esetben már extrém mértékű lehet a túlírás (write amplification) mértéke is.

Hogyan állapítható meg, hogy mennyire használódott el az SSD?

Egy Indilinx és egy Intel vezérlős SSD SMART-ja

Ez attól függ, hogy az adott SSD vezérlője támogatja-e ezt a funkciót valamilyen módon. A merevlemezek világából jól ismert SMART értékek között kell keresgélnünk; egyelőre csak három vezérlővel kapcsolatban tudunk nyilatkozni, ezek a JMicron JMF602, az Indilinx Barefoot és az Intel chipje. A JMicron vezérlője nemes egyszerűséggel nem jelez ki semmilyen, erre az információra utaló adatot. Az Indilinx vezérlője a "Remaining Drive Life"-on keresztül tájékoztat, ez maximálisan 100-as értéket vehet fel (16-os számrendszerben kijelezve a 64-es érték ennek felel meg), és onnan csökken az idő előrehaladtával. Az Intel vezérlője két adatot is közöl, az egyik a "Host Writes", ami az SSD-re történt írások mennyiségét jelzi, a "Media Wearout Indicator" pedig az Indilinx "Remaining Drive Life"-jához hasonlóan 100-ról indul és csökken. Három hónapos, közel 1,5 TB írást megélt SSD-nken ez a jelző még 98-on áll, tehát egyelőre nem tűnik vészesnek a degradálódás.

SSD kontra merevlemez

És mi a helyzet az SSD-k árával?

Ez a másik érdekes téma, ami körül komoly viták szoktak kialakulni. Az SSD-t ellenzők tábora az árakat szokta felhozni fő ellenérvként. Egy 1 TB-os merevlemez kb. 20 000 forint, tehát a GB-onkénti ára 20 forint. Ezzel szemben egy SSD GB-onkénti ára valahol 500 és 1000 forint között van, így valóban elég komoly a különbség. Sokan azt mondják, hogy egy SSD árából könnyedén összehozható egy brutális RAID 0 tömb, ami sokkal olcsóbb, jóval több adatot tárol, és szerintük még gyorsabb is.

Az a helyzet, hogy az utolsó érv kivételével mindez igaz, csakhogy nem vesznek számításba néhány dolgot. Az SSD hangtalan, fizikailag jóval strapabíróbb, mint a HDD, kicsi a súlya, ami a notebookfelhasználók körében fontos szempont lehet, és akkor még ott van az igen alacsony fogyasztás és a melegedés is; nem beszélve arról, hogy notebook, de még PC esetében sem evidens a RAID használata. A teljesítménnyel kapcsolatban viszont komoly tévhitben élnek. Ha egy merevlemezről esik szó, a felhasználók többsége azonnal a szekvenciális olvasási/írási értéket figyeli, holott egy asztali PC-ben ez az utolsó lényeges szempont, hacsak nem videóvágással foglalkozunk vagy állandóan filmeket/ISO-fájlokat vagy valami hasonlót másolgatunk ide-oda. Az most mellékes, hogy az SSD-k ezen a téren is gyorsabbak, mint a HDD-k, hiszen a leggyorsabb HDD-k jó ha 130-140 MB/s-mal másolnak (a tányérok külső peremén), erre pedig egy első generációs gyengébb SSD is képes, a kicsit is újabbak pedig már 250 MB/s körül olvasnak, és 80-200 MB/s között írnak típustól függően (tehát egy RAID 0 tömb sebességét hozzák). Ennél azonban fontosabb a véletlenszerű olvasási, illetve írási értékek halmaza. Vessünk egy pillantást a következő grafikonokra!

Egy ma kapható processzor 1-2 ns alatt fér hozzá az L1 cache-ben található adatokhoz, 2-4 ns alatt fér hozzá az L2 gyorsítótár adataihoz, 4-10 ns alatt a harmadszintűhöz, 50-100 ns alatt a memóriához és 10-15 ms, azaz 10-15 000 000 ns alatt a merevlemezhez. A merevlemezt leginkább úgy jellemezhetnénk mint egy a XX. századból (1950-es évek) ránk maradt mechanikus őskövületet (a DVD/Blu-ray meghajtókkal egyetemben). Amíg a merevlemez keresgéli a CPU számára szükséges adatot, addig a processzor és a memória üresben áll. Végső soron nincs vele túl nagy gond, olcsó, sok adat tárolására képes, jól bírja korunk megpróbáltatásait, de komolyan eljárt felette az idő. Az összehasonlítás kedvéért jegyezzük meg, hogy az SSD elérési ideje 0,05-0,1 ms körüli, azaz 100 000 ns. Még ez is igencsak messzi van az ideálistól, de már csak az egy százada a merevlemezének, így kevésbé fogja vissza a rendszert.

Fantasztikus! De mi haszna származik ebből a felhasználónak?

Igen szimplán fogalmazva sokkal pörgősebbé válik tőle a gép, reakcióideje jelentősen lecsökken. Az operációs rendszer, illetve a különböző felhasználói programok betöltésének sebessége alapvetően a kis fájlok elérésén áll vagy bukik. Az alkalmazások betöltésére nem az óriási, többszáz MB-os vagy több GB-os fájlokkal való munka a jellemző, hanem a sok, néhány kB-tól néhányszáz kB-ig terjedő adatcsomagok mozgatása, és ez az a terület, ahol az SSD villant. Érdemes megemlíteni azt is, hogy az SSD-k sebessége az egész "felületükön" egyenletes, míg egy HDD sebessége a tányéron befelé haladva lassul, általában a külső peremen mért feléig esik le. Az SSD-re egy HDD-vel való összehasonlításban gyakorlatilag nem kell várni semmire. Merevlemezen egy program hideg indítása igen hosszú ideig tarthat, ráadásul mindeközben nem tudunk mást csinálni, mondhatnánk úgy is, hogy malmozik a gép. Az SSD-n ilyen jelenséget igen ritkán tapasztalni. Véleményünk szerint egy SSD-vel szerelt gép a valódi, XXI. századi számítógép. És éppen ebből következik az SSD magas ára is, pontosabban ezzel magyarázhatjuk, ha úgy tetszik, nyugtathatjuk magunkat, miután már megvettük az SSD-t.

Az emberek akkor követik el a hibát, amikor az SSD-t a merevlemezekkel hasonlítják össze csak azért, mert adatokat tárolunk rajta, holott az SSD egy teljesen más műfaj. Az SSD egy olyan gépfejlesztési lehetőség, amit nem válthatunk ki sem egy jobb processzorral (csak részben), sem több memóriával, sem egy erősebb videokártyával; egy merevlemezzel meg aztán végképp nem. Az SSD jelenlegi formájában egy konfiguráció "felturbózására" való, és bár adatok tárolására vesszük, alapvetően a sebessége miatt jelent áttörést. Az igazsághoz hozzátartozik, hogy erre a magyarázkodásra a magas árak miatt van szükség, mert ha 1 TB-os SSD-t lehetne kapni a mai 100 GB-osak áráért, akkor még akár adattárolásra is ajánlható lenne, de a mai formájában, magas áron nem ez a helyzet. Az SSD egy asztali PC-ben jó szolgálatot tehet boot-lemezként, miközben betársítunk mellé egy gyors/halk/nagyméretű merevlemezt, amin a filmeket/zenéket/játékok zömét tároljuk. Egy notebookban ritkán van lehetőségünk két háttértár használatára, ezért ez a fajta felhasználás már kevésbé reális, de az USB 3.0 megjelenésével talán mégsem olyan reménytelen a helyzet. Egy szerverben meg aztán az SSD egyenesen csodákat művelhet.

Létezik, hogy egy tárolóeszköz cseréje többet számít, mint a memória vagy a processzor bővítése?

A későbbi oldalakon szereplő tesztekből kiderül!

SSD-vásárlási szempontok

Egy-egy SSD leírását böngészve némelyik nem is tűnik olyan gyorsnak, pl. az Intel X25-M 70 MB/s-os írási sebessége nem túlságosan meggyőző, nem beszélve az Intel X25-V 35 MB/s-os értékéről, nevetségesen kevésnek tűnik...

Valóban kevés, de tegyük fel a kérdést magunknak, hogy egy operációs rendszer alá berakott háttértár esetében melyik a fontosabb? Az, hogy a filmeket/ISO-fájlokat/játékokat és hasonlókat milyen gyorsan képes átmásolni/átmozgatni, vagy az, hogy a Windows működése közben a milliónyi kis plugin, modul, driver, mindenféle kiegészítő, regisztrációs bejegyzés és hasonlók betöltése mennyire gyors? Előbbiben versenyképes a merevlemez, utóbbiban viszont rettentően lemarad.

Ha operációs rendszer alá szeretnénk SSD-t venni, akkor egy adott SSD típus specifikációit szemlélve a szekvenciális olvasási/írási értékek (pl. 250/180 MB/s) gyakorlatilag irrelevánsak; a 4 kB-os fájlokkal való munka tempóját kell keresni a leírásban. Ezt általában IOPS azaz I/O műveletek (írás/olvasás) per másodperc értékkel szokták meghatározni, ez az igazán fontos, minél magasabb az értéke, annál jobb.

Akkor ezek után: milyen SSD-t vegyünk? Mire figyeljünk? Melyik manapság a "best buy"? Melyiktől óvakodjunk? Melyik a jövő?

A videokártyák és processzorok világában néha feltűnik egy-egy "best buy" termék, de az SSD-kkel nem ez a helyzet. Ahogy az lenni szokott, minden attól függ, mik az igényeink. Szerintünk három dologra érdemes odafigyelni azon felül, hogy mégis mekkora méretű SSD-re pályázunk. A méret is érdekes kérdés, mert ha csak az operációs rendszert és gyakran használt alkalmazásokat szeretnénk tárolni az SSD-nken, akkor sok esetben elég a 30-40 GB-os méret. Ha több és nagyobb program, esetleg 1-2 játék tárolása a célunk, akkor már a 60-80 GB-osak között kell nézelődni, míg olyan munkára, aminél számít a sebesség, a 128 GB-osak kerülnek reflektorfénybe. A 256 GB-os SSD-k jelenleg egyáltalán nem érik meg az árukat (véleményünk szerint a 128 GB-osak sem), de nyilván van ezekre is kereslet a videószerkesztéssel/vágással foglalkozó felhasználók között.

Tehát a három tényező, ami SSD-vásárlás esetén érdekes lehet, az az SSD-ben található vezérlő típusa, a TRIM-támogatás megléte/hiánya, és – ezt talán sokan nem is gondolnák – a megbízhatóság.

A vezérlők terén a következő a helyzet: a 2008-tól napjainkig megjelent SSD-ket szerintünk három csoportra, vagy mondhatnánk úgy is, hogy generációra oszthatjuk fel. Az első generációs SSD-k a Samsung anno igen drága, mára jelentősen leárazódott, SLC alapú SSD-i és a JMicron JMB602-es vezérlője, illetve annak leszármazottai köré épülnek. Talán ide sorolhatnánk még az Intel X25-M első verzióját is. Mit érdemes tudni ezekről? Először is, már jórészt kihaltak, csak elvétve találkozhatunk velük a piacon.

A Samsung SLC alapú SSD-je a maga idejében jól teljesített, de a TRIM-támogatás hiánya, a magas ár és a manapság kapható típusokhoz mért lassúsága miatt nem igazán érdemes rá pénzt szánni, csak esetleg ha nagyon olcsó. Az, hogy SLC-alapú, ne tévesszen meg senkit, emiatt (mint feljebb az élettartamra vonatkozó számolásoknál látható volt) nem éri meg a felárat.

Az Intel X25-M volt "AZ" SSD, amíg ki nem jöttek az újabbak és jobbak. Az X25-M rendkívül magas véletlenszerű adatelérési sebességével máig a topban tanyázik, de az első generációs X25-M-ből is hiányzik a TRIM támogatása, ráadásul szekvenciális írási teljesítménye mostanra már lassúcskának számít (80-100 MB/s).

Ha az X25-M "AZ" SSD, akkor a JMicron JMF602 és leszármazottai (első, második, harmadik teszt) köré épülő típusok az "ANTI" SSD-k. A JMicron által piacra dobott vezérlő olvasási teljesítményével nincs gond, de írási sebessége mai szemmel nézve botrányos, gyengébben teljesít, mint a merevlemezek, nem egy mérésünk szerint egyes esetekben 2-3 mp-nyi időre van szüksége egy kis fájl felírásához. Képzeljük el, hogy megnyitunk egy weboldalt, pl. a prohardver.hu-t. Az oldalról elkezd letöltődni egy rakás kis fájl (html, kép, script) és a gép akadozik, mert ezeket a kis fájlokat az SSD nem képes elég gyorsan kiírni a böngésző gyorsítótárába. Az igazat megvallva ez egy igazi melléfogás volt a JMicron részéről, egész egyszerűen érthetetlen, hogy hogy volt képük egyáltalán piacra dobni, de ez már nem változtat a tényeken. A JMicron vezérlő gyenge teljesítménye a gyorsítótár hiányára vezethető vissza, az ugyanis minimális méretű (32 kB). Utólag, hosszú idővel a jmicronos SSD-k piacra kerülése után kijött egy firmware, ami a teljesítményt hivatott javítani, de ez kb. annyit ért, mint halottnak a csók. A neten sikerült találnunk egy programocskát, ami a rendszermemóriából lenyisszant egy keveset, majd ezt betársítja az SSD-mellé, ezzel pedig felgyorsítja az írást, de ez is csak átmeneti megoldás. Összegezve mindezt az Intel X25-M G1-et már nem érdemes megvenni, mert már piacon van a G2 (és egyébként sem kapni), a JMicron JMF602 vezérlős SSD-k pedig egyenesen kerülendők.

A második generációs SSD-k csoportjába a 2009-ben kijött vezérlők köré épülő típusokat sorolhatjuk. Ide vehetjük az Intel X25-M G2-t, a Samsung S3C29RBB01-YK40 vezérlővel ellátott SSD-ket és az Indilinx Barefoot vezérlőjére épített modelleket. Az X25-M G2 teljesítménye lényegében megegyezik a G1-ével, de már támogatja a TRIM-et. A Samsung és az Indilinx vezérlője jó középkategóriáshoz méltóan kedveltek, napjainkban a Indilinx vezérlője a legelterjedtebb. Véletlenszerű elérésben továbbra is az Intel a nyerő, viszont szekvenciális írásban az Indilinx lépett az élre. Az Intel vezérlője felépítéséből adódóan max 100 MB/s-mal képes írni (ez is csak a 160 GB-os változatra igaz, a 80-as csak 80 MB/s-et tud) ami az Indilinx és a Samsung 150-200 MB/s-ához képest komoly lemaradást jelent.

A harmadik generációs SSD-k alatt a napjainkban megjelenő típusokat értjük. Ide vehetjük a Sandforce SF-1200/1500-at, mely a Micron által fejlesztett RealSSD C300-zal versenyzik a csúcson, illetve hazánkban komolyan terjednek a Toshiba és a JMicron társulásának köszönhetően létrejött vezérlő köré épülő SSD-k is (főleg a Kingston modellek), amelyek az alsó/középkategóriát célozzák meg. Jobb későn mint soha alapon már a Seagate és a Western Digital is kínál SSD-ket, de ezek a magas árnak köszönhetően aligha lesznek kedveltek; valószínűleg nem szeretnék kihúzni a talajt a merevlemezek alól, ami némileg érthetetlen hozzáállás, hiszen két külön termékről van szó. Ha 1-2 TB-os SSD-kről lenne szó, akkor még talán megértenénk őket, de ezek a kis 64-128-256 GB-os SSD-k biztosan nem adattárolásra lesznek befogva, legalábbis a PC-s felhasználók körében. Teljesítmény terén már 300 MB/s-os sebességnél tartunk, a SATA(2) 3 Gbps-os áteresztőképességén túlléptek a gyártók, jelenleg a Sandforce és a Micron vezérlője az ász, mondhatnánk azt is, hogy a jövő, de ez nem igaz, mert már megjelentek.

A "best buy"-ok mezőnye jelenleg igen népes, mert jópár olyan SSD létezik, amelyikkel nem igazán járunk rosszul. Az Intel X25-M 80 GB-os változata alacsony szekvenciális írási teljesítménye ellenére igen kedvelt két okból is: egyrészt véletlenszerű elérésben ez a legjobb, ami megfizethető, másrészt az Intel ismert név. Gondoljunk csak bele, az Indilinx vagy a Sandforce 2 évvel ezelőtt még sehol sem volt, senki sem ismerte őket. Hirtelen robbantak be a hardveres köztudatba, és egyelőre nincs arra semmiféle biztosíték, hogy nem tűnnek el 2 éven belül. Mi lesz azután? Azt sem tudjuk, hogy mennyire megbízható termékeket dobnak piacra. Végeredményben a jelenleg ismert, rövidtávú tapasztalatok alapján nem jelenthető ki, hogy egyik vagy másik gyártó rosszabb lenne a másiknál, de még nincsenek annyi ideje a piacon, hogy ezt bizonyosan meg tudjuk állapítani. Ennek ellenére az Indilinx vezérlői, illetve a köréjük épülő SSD-k igen kedveltek, az árazásuk is elfogadhatóbb szinten van, mint egy éve, és a terméktámogatással sincs egyelőre gond; ez a kis cég odafigyel a firmware-frissítésekre, és az Intel X25-M-hez hasonlóan támogatja a TRIM-et.

A "best buy"-ok mezőnyét erősítik az alacsonyabb árazású, nemrég kiadott Toshiba és JMicron által fejlesztett vezérlő köré épülő SSD-k is, melyek idehaza főleg a Kingston SSDNow termékcsaládjából kerülnek ki (SNV425-ös széria), de ilyet még nem teszteltünk, szóval egyelőre nem mondanánk róla véleményt. Annyit tudunk, hogy idehaza kedvelt.

Az SSD-gyártók oldalán észrevehető, hogy a kisebb méretű SSD-k mindig lassabbak, mint a nagyobbak. Ez minek köszönhető?

Ez a cikkünk elején taglalt vezérlők kérdésére vezethető vissza. Mint említettük, ezeket a vezérlőket memóriavezérlőként is felfoghatjuk, márpedig a processzorok és chipkészletek világából tudhatjuk, hogy minél több csatornás egy memóriavezérlő, annál több adatot képes egyidejűleg elérni. Ugyanez igaz az SSD-kre is. A kisebb méretű SSD-kben általában kevesebb NAND-chip található, ergo a vezérlő és a chipek között is kevesebb az adatútvonal, emiatt pedig lassabbak.

Az SSD-k jövője

Mi a jövő? Elmondható, hogy az SSD az "ultimate" tároló?

Az SSD-kben még van fejlődési potenciál. Ami a méreteket illeti, minden a NAND-flasheknél alkalmazott gyártástechnológiától függ. Az Intel jelenleg 34 nm-en gyártja NAND-jait, ilyeneket találunk az X25-M-ben is. Év végére ígérik a 25 nm-es csíkszélesség bevezetését, ami közel azonos területen dupla kapacitást ígér. A Samsung, a Toshiba és a Hynix is még idénre ígéri a huszonx nm-es lapkákat, tehát a kapacitás tekintetében hamarosan duplázásra számíthatunk, de könnyen lehet, hogy ez először csak a jelenleg kapható SSD-k árzuhanását fogja jelenteni.

34 nm-es 4 GB-os MLC NAND: 172 mm² és 25 nm-es 8 GB-os MLC NAND: 167 mm²

Ami a NAND-ok élettartamát és sebességét illeti, itt is van még hova fejlődni. Ennek első állomása valószínűleg az FFS, azaz Flash File System (flashekhez fejlesztett fájlrendszer) továbbfejlesztése lesz, ami a napjainkban használatos NAND-chipek írási "problémáinak" és a wear leveling további optimalizációjának, illetve az operációs rendszerek figyelembe vételével készül. Az írást úgy szeretnék felgyorsítani, hogy a valós írás minden esetben egy üres lapot/blokkot terheljen, majd a vezérlő a törlendő lapot/blokkot csak akkor törli ténylegesen, amikor ideje van erre, tehát üresjáratban (a SanDisk által propagált ExtremeFFS 100x-os írási gyorsulásának is ez áll a hátterében). A wear leveling hatékonysága javítható az írások tovább optimalizált "szétszórásával" a NAND-ok között.

És hogy mi lesz az SSD-k után? Jó pár olyan fejlesztésről tudunk, amely a NAND-okat hivatott leváltani, ilyen a Resistive random-access memory, a Programmable metallization cell vagy a Phase-change memory, de hogy ezekből mikor lesz kézzelfogható termék, az még talány, és persze a bevezetésük sem megy olyan könnyen; gondoljunk csak az OLED-re, amit már évek óta várunk, sokan a jelenlegi TFT LCD-panelek leváltójaként vizionáltak, és még mindig csak kiállításokon láthatjuk őket.

Van még valami, amit tudnunk kéne?

Az SSD-k teljesítményének degradálódása kapcsán érdemes megemlíteni, hogy azokat az SSD-ket, melyek nem támogatják a TRIM-et, különböző programokkal van lehetőségünk karbantartani. Ez itt nem a reklám helye, de a Diskeeper HyperFast és a PerfectDisk alkalmas az SSD-ken található nem TRIM-elt, de törlendőként megjelölt lapokat konszolidálni, ami után az írási sebesség az eredeti, maximális értékhez tér vissza. Mindkét programot lehetőségünk van úgy beállítani, hogy ezt a háttérben végezze. Sajnos egyik sem ingyenes.

Összefoglalás és a "teszt"

Összefoglaljuk az eddig leírtakat:

• SSD vásárlásánál az MLC vs. SLC kérdés nem releváns, az asztali PC-kbe az MLC-ket szánják;
• a NAND típusánál fontosabb, hogy az adott SSD milyen vezérlő köré épül (Intel, Indilinx, Samsung, JMicron, Toshiba, SandForce, Micron) és hogy az támogatja-e a TRIM-et (lehetőleg igen);
• itthon a jelenleg ajánlható SSD-k Intel, Indilinx, Samsung vagy Toshiba vezérlő köré épülnek;
• az SSD megvétele és beüzemelése után a BIOS-ban kapcsoljuk be az AHCI-módot, hogy a TRIM működésbe léphessen;
• Windows alatt is kapcsoljuk be a TRIM-et, és olyan drivert installáljunk fel, ami támogatja
• ügyeljünk a partíció helyes eltolására ("alignálás"), a rossz beállítás ugyanis teljesítménycsökkenést eredményez;
• kapcsoljuk ki a töredezettségmentesítőt, a SuperFetch-et, a prefetch-et és az indexelést;
• ha lehetőségünk van rá, akkor a böngésző cache-t (szemetét) helyezzük át egy merevlemezre vagy RAMdiskre;
• ne írjuk tele az SSD-t, lehetőleg a teljes kapacitás 20%-át mindig hagyjunk szabadon.

Jelen cikkünkben alapvetően inkább az SSD-k előnyeire szeretnénk koncentrálni, tehát nem egy nagy, sok SSD-t és HDD-t tartalmazó tesztet kell elképzelni. Ehelyett egy olyan összevetést készítettünk, amit még nem láttunk sehol a neten. Kicsit hasonlít a CPU-VGA párosító cikksorozatunkban megszokottakhoz, csak éppen ezúttal a processzorokat egy-egy SSD-vel és HDD-vel párosítottuk össze.

Adott három konfiguráció, egy régi "notebookszerű" egymagos processzorral, egy mai belépőszintű-közepes kétmagos és egy csúcsgép négymagos CPU-val:

És adott két háttértároló, egy mai gyors, 7200 rpm-es merevlemez és egy közepes teljesítményű SSD:

A játékos tesztek miatt érdemes még megjegyezni, hogy a videokártya esetében egy 1 GB memóriás Radeon HD 4850-re esett a választásunk, az operációs rendszer szerepét pedig a Windows 7 32 bites verziója töltötte be, ugyanis a Pentium M 760 még nem támogatja a 64 bites működést. Nagyon fontos kiemelni, hogy ez a rendszer nem egy két óra alatt összehozott, éppen felinstallált, szűz Windows, hanem egy hónapokon keresztül használt, jól megpakolt, rengeteg programot tartalmazó, tehát "teliszemetelt" rendszer folyamatosan scannelő vírusirtóval a háttérben, ami szerintünk reálisabb képet ad az erőviszonyokról. A kicsit több, mint három hónapos használat során be volt kapcsolva a SuperFetch, a töredezettségmentesítés és a Prefetch is, tehát a merevlemez megkapott minden segítséget, amire szüksége lehet. Ezeket kikapcsoltuk, miután a rendszert átklónoztuk SSD-re.

A kérdés pedig az, hogy az egyes kombinációk mit nyújtanak "érzésre", amit a legjobban a különböző betöltési idők lemérésével lehet szemléltetni. A most következő mérési eredmények egyúttal némi ízelítőt adnak a jövőben megjelenő háttértárolós cikkekben használt tesztekből, azokban ugyanis ezekhez hasonló mérési eredményeink lesznek.

Mégis, mit tippelnek az olvasók? Egy ilyen elavult, egymagos gép képes felvenni a versenyt napjaink egyik csúcsprocesszorával? Számolásban biztosan nem, de mi a helyzet a gép sebességével, amit a használat közben érzékelünk a programok megnyílása, az alkalmazások váltása közt érzékelhető idővel, azzal hogy mennyit töltöget a gép? Lehet annyira sima a munka egy egymagos gépen, mint egy négymagoson?

Tesztek először

Lássuk a legegyszerűbb, legkevésbé erőforrásigényes teszteket, avagy mondhatnánk alkalmazások betöltését is, mert ezek igazából nem tesztek, hanem a számítógép valós használata stopperórával a kezünkben.

Ezek a kisebb programocskák, mint amilyen az Excel, az Internet Explorer, a Thunderbird, a Windows Media Player, a Total Commander vagy éppen a Chess Titans, nagyon gyorsan betöltődnek. Az SSD itt is gyorsabb, de az embert nem különösebben izgatja 1 vagy 2 másodperc különbség, emiatt nem éri meg SSD-t venni. Kicsit komolyabban megdolgoztatva a tárolókat, azért már látszik némi különbség: a 3ds max 2010 egy egymagos CPU-s gépen SSD-vel olyan gyorsan töltődik be, mint a négymagoson HDD-vel (tegyük hozzá, hogy gyors HDD-vel, mert egy noti HDD ennél jóval lassabb). Az egymagos gépet négymagosra cserélve HDD mellett csak 33%-kal csökkent a betöltési idő, viszont SSD mellett közel a felére esett ez az idő, a HDD-s eredménnyel összehasonlítva pedig majdnem a harmadára. A Photoshop betöltése önmagában szintén nem tart sokáig (ez a CS4 előtti verziókra azért még nem jellemző), az SSD itt is gyorsabb, de 7 és 12 mp között sincs olyan kiemelkedően nagy különbség, hogy emiatt több tízezret kidobjunk az ablakon.

Sajnos számokkal nem lehet kifejezni de tudni kell, hogy az SSD nem csak gyorsabban tölti be a programot, de mellette további programok elindítására és a taszkváltásra is sokkal jobban reagál, tehát jóval gördülékenyebb rajta a munka, élvezhetőbb a gép használata. Ez a következő oldalon található tesztekben ki is ütközik.

Ezután kipróbáltunk két játékot is, a Far Cry 2-t és a STALKER COP-ot. Sikeresen kifogtunk két olyan címet, amelyeket nem különösebben hat meg az SSD jelenléte. Jól látható, hogy a Far Cry 2-t teljesen hidegen hagyja a háttértároló sebessége, ellenben a processzorok cseréjével rengeteget csökken a betöltési idő. A STALKER már jobban reagál a HDD cseréjére, de még ez sem az a különbség, ami "wow" effektust eredményezne a felhasználó részéről. Azért ismerünk jó pár játékot, amelyek rengeteget gyorsulnak a HDD-SSD cseréje után, ilyen a Team Fortress 2, a COD: MW, a Crysis (Warhead) és a DiRT 2 is gyorsabb, vagy említhetnénk még az Aliens vs. Predatort.

Tesztek másodszor

Éppen ezért érdemes egy kicsit jobban megizzasztani ezeket a tárolókat. A Windows betöltődése után különböző számítógépes munkásrétegek kedvelt programjait indítottuk el egyidőben. Ezt egy szimpla batch-fájl megírásával sikerült elérnünk, az egyes elindítandó programok közé betettünk egy | jelet, tehát a "webdesignerek" batch-fájlja így néz ki:

"c:\Program Files (x86)\Adobe\Adobe Photoshop CS4\photoshop.exe" "c:\teszt.psd" | "c:\Program Files (x86)\Adobe\Adobe illustrator CS4\illustrator.exe" "c:\teszt2.tiff" | "c:\Program Files (x86)\Adobe\Adobe Bridge CS4\bridge.exe".

A 3D-s tervezéshez használt csokorban a 3ds max 2010, a Sony Vegas 9.0c és az Adobe After Effects CS4, az újságírók csokrában pedig az MS Word 2007, az Adobe Dreamweaver CS4, a FireFox 3.6, a Thunderbird, a Swiff Chart Pro és a Gimp 2 szerepel. A batch-fájlokat úgy állítottuk be, hogy az adott programok egyúttal azonnal megnyissanak egy dokumentumot is, a 3ds max egy 3D-s jelenetet, a FireFox 10 előre megnyitott weboldallal nyílik meg, a Dreamweaver egy nagyobbacska HTML fájllal és így tovább.

A programok ilyen módon történő, egyidejű elindítása nem túlságosan elterjedt, mert az emberek hozzászoktak a merevlemezek lassúságához, ezért vagy egyesével indítják el az alkamazásokat, vagy végigkattintgatják az ikonokat, aztán elmennek kávét inni/dohányozni, amíg a programok betöltődnek. Az SSD-k megjelenése sem valószínű, hogy változtat majd ezen, csak éppen így már nincs indokunk a gép mellől ellógásra.

A bootteszttel kapcsolatban ki kell emelnünk, hogy az időt a "Boot from CD-ROM" szöveg eltűnésétől kezdődően mérjük egészen addig, amíg az ikonok, a gadgetek és a tálcán megjelenő programok be nem töltődnek, tehát a stoppert nem állítjuk le, amint a Windows asztal megjelenik, mert ennek nem látjuk értelmét, itt még nem használható a gép, mert még számos dolognak be kell töltődnie. Legalábbis ez a helyzet a merevlemezekkel, amíg ezek betöltődnek, addig hiába kattintgathatunk ide-oda, elég sokat kell várni még akár egy szimpla Windows Intéző megnyílására is. SSD-vel nem kell várni szinte semennyit, tehát bár már az időeredmények önmagukban is az SSD győzelmét mutatják, ez még nem meséli el a komplett sztorit.

Lássuk a boot-időt. Az egymagos gép SSD-vel feleannyi idő alatt végez, mint a négymagos gép HDD-vel. A négymagos gép SSD-vel negyedannyi idő alatt végez, mint HDD-vel.

A "webdesigner" programcsokor hatodannyi idő alatt töltődik be SSD-ről, mint HDD-ről egy négymagos gépen. Itt azért érdemes megfigyelni a "skálázódást" is, mert a kétmagoson már "csak" harmadannyi időt mértünk, az egymagoson pedig csak 50%-kal gyorsabb az SSD. A 3D-s csokor betöltése tart a legtovább, érdekes módon a "skálázódás" arányaiban itt is hasonló. A vak is látja, hogy a Core i7-870-et mennyire visszafogja a HDD, de még egy elavult, egymagos gép is képes profitálni az SSD jelenlétéből. Az újságíró programcsokor valójában egészen gyors lenne, ha nem szerepelne benne a Gimp, ugyanis csak annak a betöltése tart sokáig, a többi program szinte pillanatok alatt elindul. Az egymagos gépen itt már nincs olyan nagy különbség, a négymagoson viszont harmadára csökkent a betöltési idő. Végezetül lemértük a Windows 7-ben található Windows XP mód elindulásának az idejét is (lényegében virtualizációról, azaz egy virtualizált Windows XP bootról van szó), ez jól láthatóan kevésbé gyorsul a háttértárak cseréjét követően, inkább a CPU-ra hagyatkozik. Néhány esetben az egymagos gép SSD-vel hasonló eredményt futott a 4 magos CPU + HDD párosával. Ha az eddig elért eredmények nem elég meggyőzőek, akkor van még valami: amit a számok nem mesélnek el, az az, hogy az 1 magos gép SSD mellett alacsonyabb válaszidővel néha gyorsabbnak tűnik, mint a 4 magos konfig merevlemezzel ami már önmagában is teljesen nevetséges, hiszen az ember nem véletlenül veszi meg a drága processzort, egy gyors gépet szeretne, de ez a használat közben HDD mellett mégsem érződik...

Biztosan lesznek jó néhányan, akiket a szimpla időeredmények áradata nem fog meggyőzni, de nem is a meggyőzés volt a célunk. Azok, akik már beruháztak egy SSD-be, tudják, hogy miről szól ez az egész, mert az az igazság, hogy az SSD által nyújtott előnyök csak a használat közben válnak nyilvánvalóvá. Ahogy azt már említettük, az SSD nem csak a rendszer, illetve a programbetöltési idők lerövidülése miatt kívánatos, hanem azért is, mert jórészt megszűnnek a várakozások, több minden történhet egyszerre úgy, hogy közben a számítógép reakcióideje csak kis mértékben emelkedik. Aki egyszer SSD-re váltott, az többé nem akar merevemezt tenni az operációs rendszer alá.

Konklúzió

Az SSD egy notebook-felhasználó számára azért lehet fontos, mert a notebookvinyók eleve nagyon lassúak. Egy SSD beszerzésével jelentősen kitolhatjuk a notebook elavulási idejét, hiszen könnyen lehet, hogy a csere után már nem is érezzük szükségét egy új notebook beszerzésének. A hordozható gépeken nem szokás CPU-faló programokat futtatni, ezért az esetek többségében a lassúság a merevlemez számlájára írható.

Egy közepesnek tekinthető, kétmagos gépbe szintén a fentebb felsorolt okok miatt passzol az SSD. Ha lassúnak érezzük a gépet, de nem futtatunk erősen a CPU-ra támaszkodó programokat, akkor biztosan a merevlemez a szűk-keresztmetszet.

Az erős konfiguráció (4+ mag) nagyon jól láthatóan rengeteget profitál az SSD jelenlétéből (fogalmazhatnánk úgy is, hogy a merevlemezek irtózatosan visszafogják). Egy négymagos konfiguráció egy merevlemez mellett "érzésre" könnyen lassúnak tűnhet, holott nem a CPU-val, hanem a winchesterrel van a gond. Egy erős gépbe véleményünk szerint szinte kötelező SSD-t venni, anélkül ugyanis nem beszélhetünk csúcs gépről, csak egy kényszerből visszafogott, éheztetett "versenylóról".

Az SSD-k terjedése a magas árak miatt biztosan nem lesz gyors (egyelőre csak úri hóbort), de érdemes megfontolni, hogy fejlesztésnél egy komplett új gép/notebook, esetleg processzor cseréjével járunk jobban vagy egy SSD beszerzésével. Ha nem futtatunk gyakran a sokmagos processzorok erőforrásait kiaknázó alkalmazásokat, akkor szerintünk az SSD a nyerő választás.

Cikkünk lezárásaként belekezdtünk egy itthon kapható SSD-ket összesítő táblázat készítésébe, ez még nem teljes, az újabb típusok megjelenésével folyamatosan bővülni fog.

SSD vezérlők

Indilinx Barefoot: rengeteg SSD-t építettek köré. Véletlenszerű elérésben lassabb az Intel vezérlőjénél, de szekvenciális írásban gyorsabb annál. Rendszermeghajtónak tökéletes és nagy fájlokkal való munkára is megfelelő. A TRIM-et támogatja.

Intel PC29AS21AA0: az első generációs Intel vezérlő 2010-ig a véletlenszerű elérés királya volt, azonban az új Micron vezérlő már el tudja verni. Egyetlen gyengéje, hogy MLC-vel társítva (X25-M) szekvenciális írásban lassúnak tekinthető. Ez a vezérlő még nem támogatja a TRIM-et. Újonnan már nem kapni eköré épülő SSD-ket.

Intel PC29AS21BA0: a második generációs Intel vezérlő sebesség tekintetében nem jelent előrelépést, azonban már TRIM támogatással kerül piacra (ha másként nem, utólag lehetőségünk van firmware-t frissíteni). Rendszermeghajtónak tökéletes, azonban nagy fájlokkal való munkára jobban járunk az Indilinxszel.

JMicron JMF601/JMF602/JMF602B: az első SSD-meghajtók jelentős százaléka ezekre a vezérlőkre épült, mert anno a piaci versenyzők alacsony számának köszönhetően relatív olcsó volt. Úgy általában csak JMicronként hivatkoznak rá. Ezek azok a vezérlők, amelyek az úgynevezett "akadás" jelenséget előidézik, mert kevés gyorsítótárat társítottak mellé, ezért a kis fájlok írásánál akadozhat a számítógép. Ha nem lenne ilyen baja, akkor nem lenne vele semmi gond, azonban így nem ajánlható, maximum egy nagyon jelentős leárazás keretein belül. Egyébként is már egy igencsak kifutott modell, új SSD-kben már csak elvétve találunk ilyen vezérlőt. Nem támogatja a TRIM-et.

Samsung S3C29RBB01-YK40: az Indilinxhez hasonló paraméterekkel bír, de minden téren lassabb annál. A TRIM-et firmware-frissítés után támogatja. Az indilinxes típusoknál olcsóbban megfontolandó vétel.

Toshiba TC58NC/JMicron JMF618: ez egy állítólagosan Toshiba által felügyelt, második generációs JMicron-vezérlő, ami már nem szenved azoktól az akadozással kapcsolatos gondoktól, mint a JMF602. Véletlenszerű elérésben nem észrevehetően, de még mindig lassúcska a konkurenciához képest, ugyanakkor szekvenciális sebességével nincs probléma, és olcsó SSD-ket építenek köré, ezért egyre inkább népszerű. Az eddig látott tesztek szerint a TRIM helyett/mellett egy vezérlőchip által irányított mechanizmussal is rendelkezik, ami üresjáratban "megtisztítja" az SSD-t, így írási sebessége szinte állandóan a maximum közelében mozog.

SandForce SF-1200/1500: egyike a legújabb vezérlőknek; egy belső tömörítési eljárásnak köszönhetően tovább emelték az írási sebességet (a tömörítés miatt kevesebb adatot kell felírni), így jelenleg ez az egyik leggyorsabb szekvenciális műveletekben, már a SATA 3 Gbps-os határait feszegeti, ugyanakkor egyelőre kérdéses a megbízhatósága.

Marvell 88SS9174-BJP2 alias Micron RealSSD C300: az első 6 Gbps-kompabitilis SSD-vezérlő a piacon, amire szüksége is van. Szekvenciális olvasásban jelenleg ez a leggyorsabb, 300 MB/s felett jár (~320 MB/s), írásban viszont lassabb a SandForce SF-1500-nál, 200 MB/s környékén tanyázik. Véletlenszerű elérésben a világon elsőként képes elverni az Intel vezérlőjét. A Marvell-chipje köré épülő SSD-k idehaza egyelőre hiánycikknek számítanak.

SSD táblázat

A korábban itt található SSD táblázat átköltözött a Tudástárba.