Előmelegítés

Nem rajongunk a szintetikus benchmarkok iránt, de vannak helyzetek, amikor ezek használata, ha nem is elkerülhetetlen, de ésszerű, mert a legtöbb esetben gyorsak. A háttértárolókkal foglalkozó tesztjeinkben a HDTune-ra és az IOMeterre szoktunk támaszkodni, előző cikkeinkben még szerepelt az IPEAK is, de ezt végül kiemeltük a sorból. A HDTune kifejezetten a HDD-k tesztelésére jó (és nem az SSD-re), 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. 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 véletlenszerű elérési sebesség mérésére csak és kizárólag az IOMetert használtuk. A programmal létrehoztunk egy 10 GB-os tesztfájlt a merevlemez/SSD "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 kirívó eset egy asztali számítógép esetében, általában azért szokás 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).

Erre a célra használhattuk volna az igen népszerű AS SSD-t vagy a CrystalDiskBenchmarkot is, csak az a baj ezekkel a benchmarkokkal, hogy fix méretű tesztfájlokkal dolgoznak, ezért minél lassabb egy HDD/SSD, annál lassabban fut le a teszt, és egyes fórumozók visszajelzésiből kiderült, hogy régebbi SSD-ken ez a teszt akár fél napot is futhat. Az IOMeterben mi állíthatjuk be a futási időt, ezért ez nem probléma.

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, QD=4) mit teljesít a kiszemelt.

Kis SSD RAID-ben

Mint azt említettük, sokan úgy gondolják, hogy egy nagyobb (ami ezesetben 64/80 GB-ot jelent) SSD helyett két kisebbet használnának RAID 0-ban. Az Intel X25-V-t és az OCZ Vertexet mi is kipróbáltuk RAID 0-ban (illetve ott van még az OCZ RevoDrive), de mielőtt az alkalmazástesztekre került volna a sor, kimértük, hogy a RAID-tömbbel mekkora csíkméret mellett érjük el a legmagasabb teljesítményt. 4, 16, 64 és 128 kB-os csíkméreteket használtunk, és lefuttatuk az IOMeter egyes tesztjeit. Mint kiderült, a szekvenciális olvasási tempó 16 kB-os méretig növekedett, 186,42 MB/s-ről 366,22 MB/s-re nőtt, majd elkezdett lassulni. Ez 96%-os gyorsulás, ami nem éppen rossz. A szekvenciális írási tempó 128 kB-os stripeméret mellett érte el a csúcsot, de már kisebb méreteknél sem volt sokkal lassabb, két darab X25-V RAID 0-ban éppen olyan gyors, mint egy darab X25-M (~80 MB/s). A véletlenszerű olvasási teszt érdekesen alakult. Amikor csak négy egyidejű lekérdezés érkezett a vezérlő felé, a RAID-tömb alig volt gyorsabb, mint a szingli X25-V, ami gyakorlatilag azt jelenti, hogy egy átlagfelhasználó semmit sem érezne a RAID előnyéből, amikor az OS vagy programok betöltéséről van szó. 64 egyidejű lekérés esetén azonban maximálisan 84%-os gyorsulást érhető el, ez azonban az átlagfelhasználónak szinte teljesen lényegtelen. A random írás is közel kétszeresére gyorsult a stripeméret maximális méretének beállításával, de az X25-V már önmagában is olyan gyors, hogy ennek nincs semmi jelentősége. Végül úgy döntöttünk, hogy az X25-V-t és a Vertexet is 64 kB-os csíkméret mellett fogjuk letesztelni, elvégre az OCZ RevoDrive-nak is ez az alapbeállítása. Szerverbe valószínűleg a 128 kB-os stripeméret lenne a megfelelő, mert random IO-ban itt a leggyorsabb a tömb, otthon másolgatásra és videóvágásra viszont a 16 vagy a 64 kB-os méret tűnik a legjobbnak, mert ezekben az esetekben a legmagasabbak a szekvenciális értékek.

JMicron JMF602 vs. Toshiba TC58NCF602GAT

Az IOMeterrel kiteszteltük a JMicron JMF602 és a Toshiba TC58NCF602GAT vezérlők közti különbséget. Utóbbi alapvetően a JMF602 átnevezése, de egyes leírások szerint a Toshiba, a JMicron és a Kingston együttes erővel megszüntették az akadozás jelenségét, ami az alacsony véletlenszerű írási sebességre vezethető vissza. Állítólag azért nevezték át a vezérlőt, hogy a vásárlók ne rettenjenek el a megvételétől. Elég érdekes felfogás, mert mint az a tesztelés során kiderült, a Toshibává vedlett JMicron gyakorlatilag semmivel sem gyorsabb "elődjénél", sőt, még lassabb is annál szinte minden szempontból. Egyedül a random olvasás gyorsult, de az eltérés itt sem szignifikáns. Azért érdemes picit belegondolni, hogy mit is mértünk. A JMF602 mindössze 18 random írásra képes másodpercenként, ha 4 egyidejű lekérés érkezik, ez az átlag. Ez azt jelenti, hogy írásonként átlagban 0,2 másodpercet kell várni, de előfordulhat olyan eset is, amikor 2 másodpercet kell várni (2221 ms), és ez az, amit mi megakadásnak érzékelünk (gondoljunk arra, hogy megnyitunk egy weboldalt, ahonnan letöltődik mondjuk 50 kisebb képecske). A Toshibára átnevezett vezérlő értékei itt picit változtak, az átlag nőtt, de a maximum csökkent, ami végülis jó hír, de itt nagyon magas értékekről van szó, ami teljesen elfogadhatatlan 2010-ben, elég ha összevetjük a 7200 rpm-es Hitachi TravelStar 7K200 másodpercenként kb. 200 írásos eredményével.

Crucial RealSSD C300 SATA 3 Gbps-es és SATA 6 Gbps-es portra kapcsolva

A bemelegítés végén kiteszteltük, hogy a SATA 6 Gbps kompatibilis Crucial SSD mire képes. Először leteszteltük a SATA 3 Gbps-et támogató Intel alaplapban, majd egy SATA 6 Gbps-et támogató AMD-s alaplapban (Asus Crosshair IV Formula, BIOS 1102). Alapvetően azokat az eredményeket kaptuk, amire számítottunk. Az inteles platformon a SATA 3 Gbps-es csatoló az SSD-nek csak a szekvenciális olvasási tempóját fogta vissza, 267,51 MB/s-et mértünk, míg ugyanez az SSD az SB850-es déli híd mellett 327,6 MB/s-re volt képes. Érdemes ezt két szempont szerint is megvizsgálni. Egyrészt gondoljunk bele, hogy a mai HDD-k hol tartanak olvasásban: a maximum, amit mi kimértünk 151,2 MB/s (VelociRaptor 600 GB), erre is csak a külső peremen képes, tehát a HDD óriási lemaradásban van. Ugyanakkor gondolkozzunk el azon, hogy mi mikor tudjuk ezt kihasználni? Valószínűleg soha. A többi érték lényegében megegyezett a két platformon, ami jó hír az AMD-s gépet birtoklók számára, mert egy korábbi cikkünkben elég gyengén muzsikált az AMD déli hídja, de mint kiderült, a meghajtóprogrammal volt a gond (most a legújabbat, az 1.2.1.263-at használtuk).

A cikk még nem ért véget, kérlek, lapozz!