Testikokoonpano & suorituskyky: CrystalDiskMark 3

Testeissä käytettyjen SSD-asemien firmware-versiot olivat seuraavat:

• Crucial MX100 256 Gt – MU1
• Crucial MX100 512 Gt – MU1
• Samsung 850 EVO 120 Gt – EMT01B6Q
• Samsung 850 EVO 250 Gt – EMT01B6Q
• Samsung 850 EVO 500 Gt – EMT01B6Q
• Intel 730-series 240 Gt – L2010410
• Intel 730-series 480 Gt – L2010400
• Crucial M550 256 Gt – MU1
• Crucial M550 512 Gt – MU1
• ADATA SP920 256 Gt – MU1
• ADATA SP920 512 Gt – MU1
• OCZ Vector 150 240 Gt – 1.0
• OCZ Vertex 450 256 Gt – 1.0
• OCZ Vertex 460 240 Gt – 1.0
• Samsung 830 256 Gt – CXM03B1Q
• Samsung 840 250 Gt – DXT08B0Q
• Samsung 840 Pro 256 Gt – DXM05B0Q
• Samsung 840 EVO 750 Gt – EXT0AB0Q
• Seagate 600 240 Gt – B660

Huomatuksena tähän väliin, että alla oleva testimetodien kuvaus on kopioitu edellisistä SSD-artikkeleista, joten vakiolukijat voivat hypätä suoraan itse tuloksiin. Ainoana erona edellisiin testeihin on haittaohjelmatarkastustestin poisjäänti, sillä uudemmat tulokset nopeutuivat useammalla minuutilla eikä testi ollut enään luotettava.

Muropaketin SSD-testialustana on käytössä Intelin Haswell-pohjainen kokoonpano, josta löytyy Core i7-4770K prosessori, Asuksen Z87 Deluxe -emolevy, kaksi Corsairin kahdeksan gigatavun Vengeance DDR3-1866 -muistikampaa ja Corsairin 750 wattinen CX750M-virtalähde. Näytönohjaimena toimii prosessoriin integroitu Intel HD Graphics 4600. BIOSista kytkettiin prosessorin C-virransäästötilat pois päältä, sillä SSD-aseman suorituskyky ei välttämättä saavuta huippua, jos prosessori on virransäästötilassa. Muut BIOS-asetukset jätettiin vakioiksi.

• Intel Core i7-4770K –prosessori (4/8 ydintä/säiettä; 3,5GHz; Turbo Boost 2.0: maks. 3,9GHz)
• ASUS Z87 Deluxe –emolevy (BIOS-versio: 1707)
• 16 Gt (2x8Gt) Corsairin Vengeance DDR3-1866-muistia (9-10-9-27 2T)
• Intel HD Graphics 4600 –näytönohjain (350MHz, Turbo Boost: maks. 1250MHz)
• Corsair CX750M –virtalähde

Testit suoritettiin asentamalla 64-bittinen Windows 7 Ultimate ja SP1–päivitys apuasemana toimineelle Corsair Force LS –asemalle. Lisäksi testikokoonpanoon asennettiin uusimmat versiot tarvittavista ajureista sekä testiohjelmista. Asennuksen jälkeen koko asema kloonattiin Acronis True Image HD –ohjelmalla testattaville levyille, joille oli suoritettu Secure Erase –toiminto ennen kloonausta. Itse testauksessa ei käytetty apuna toista asemaa, vaan testattava asema oli testauksen aikana ainut kokoonpanoon liitettynä ollut levy.

• Intel Rapid Storage Technology 12.9.0.1001
• Intel Chipset Device Software 9.4.0.1026
• Intel HD Graphics Driver 15.33.8.64.3345

Muropaketin SSD-testeissä on kolme eri testauslähtökohtaa: tyhjä, 90 % täysi ja ”käytetty”. Kuten kiintolevyjen, myös SSD-asemien suorituskyky hidastuu aseman täyttyessä, joten ei ole realistista testata asemaa niin, että asennettuna on vain Windows ja testiohjelmat, jotka täyttävät asemasta yhteensä vain 84,5 gigatavua. Aseman täyttämisessä käytettiin apuna Iometer-ohjelmaa, joka on hyvin yleinen SSD-asemien ja kiintolevyjen testiohjelma arvosteluissa, mutta peruskäyttäjälle sen käyttö on turhan haastavaa lukuisten parametrien takia. Yleensä Iometeriä käytetään ns. RAW-tilassa eli asemalle ei ole luotu tiedostojärjestelmää, mutta ohjelma tukee myös NTFS-tiedostojärjestelmää. Tiedostojärjestelmällä testattaessa ohjelma luo iobw.tst-tiedoston, jonka koko riippuu 512 tavun tarkkuudella määritellystä levyn koosta. ”90 % täysi” -testissä levyn koko määriteltiin siten, että testattavalle asemalle jäi noin 10 % tyhjää tilaa ja täyttödata oli perättäisiä 128 kilotavun kirjoituksia. Kun Iometer oli täyttänyt levyn, ajettiin asemalle samat testit kuin tyhjälle asemalle.

Hätäisimmät jo varmaan pelästyivät listattujen ja Windowsissa näkyvien kapasteettien eroja, mutta kyseessä on vain ero gigatavun määrittelyssä. Windows määrittelee gigatavuksi 1024^3 tavua, joka juontuu tietokoneiden binäärisyydestä (kaikki kapasiteetit kulkevat kahden potensseissa). Kiintolevy ja SSD-valmistajat sen sijaan määrittelevät gigatavun 1000^3 tavuksi, jolloin listatun ja Windowsissa näkyvän kapasiteetin eroksi jää noin 7 %. Kumpikaan määrittelyistä ei ole väärin, sillä Windowsin käyttämä pohjautuu JEDECin standardiin, kun taas valmistajien juontaa juurensa SI-järjestelmään. Tosin kuluttajalle asia saattaa aiheuttaa sekaannusta ja esimerkiksi Apple on vaihtanut 1000^3 määrittelyyn välttääkseen sekaannusta.

Aseman täyttäminen simuloi hyvin kevyen käyttäjän tilannetta, jossa valtaosa datasta on staattista, mutta ei huomioi tehokäyttäjälle tyypillistä dynaamisen datan tilannetta. Staattisessa tilanteessa kerran kirjoitettu data ei muutu, joka pätee erimerkiksi musiikki- ja videotiedostoihin. Monet ohjelmat kuitenkin jatkuvasti päivittävät muun muassa eri log-tiedostoja, josta aiheutuu kirjoituksia asemalle. Toisin kuin kiintolevyissä, SSD-asemissa dataa ei voi suoraan ylikirjoittaa, vaan jos asema on täynnä eikä tyhjiä sivuja (pages) ole jäljellä, täytyy koko lohko (yleensä 128-512 sivua) ensin tyhjentää. Tämä vie huomattavasti enemmän aikaa, sillä lohkon sisältö täytyy ensin lukea välimuistiin, jotta se voidaan tyhjentää. Vasta tyhjentämisen jälkeen haluttu data päästään kirjoittamaan, mutta kyseisessä lue-muuta-kirjoita (read-modify-write) operaatiossa menee huomattavasti kauemmin kuin pelkässä kirjoitusoperaatiossa.

Aseman ”roskienkeruun” (garbage collection) on tarkoitus pitää huoli, että tyhjiä sivuja ja lohkoja on aina riittävästi, ettei aseman tarvitsisi turvautua hitaaseen lue-muuta-kirjoita sykliin. Hyvin toteutettu aktiivinen roskienkeruu pitää aseman suorituskyvyn tasaisena ja jatkuvasti uudelleenjärjestelee dataa, jolloin suorituskyky ei pääse laskemaan huomattavasti. Sen sijaan huonosti toteutettuna roskienkeruu ei välttämättä aktivoidu ennen kuin asema on liian täynnä ja tällöin ei ole muuta vaihtoehtoa, kuin turvautua lue-muuta-kirjoita operaatioon. Tämä näkyy käyttäjälle hitautena, sillä asema ei pysty käsitellä isännältä (host) tullutta luku- tai kirjoitusoperaatiota ennen kuin lue-muuta-kirjoita operaatio on suoritettu. Yhden isäntäoperaation kohdalla tämä ei vielä haittaa, mutta jatkuvasti toistuvana käyttökokemus kärsii huomattavasti.

Valtaosa sivustoista käyttää suorituskyvyn tasaisuuden testaamisen pelkästään synteettistä testiä, jossa koko aseman kapasiteetille kirjoitetaan satunnaista neljän kilotavun dataa jononsyvyydellä (queue depth) 32. Tämä on toimiva keino asemien arkkitehtuurien tutkimiseen ja sopii myös yritysasemien testaamiseen, missä koko kapasiteetin käyttö, pienet satunnaiskirjoitukset ja suuri jononsyvyys ovat normaalia. Kuluttajan näkökulmasta tämä ei kuitenkaan ole kovin realistista, sillä SSD-asemia käytetään pääasiassa käyttöjärjestelmälevyinä, jolloin aseman koko käyttö on epätodennäköistä ja asemalla on myös aina jonkin verran staattista dataa (aseman koko kapasiteettia ei tällöin voi käyttää satunnaiskirjoitustestissä).

Koska Muropaketin SSD-testien lähtökohtana on käyttäjäläheisyys, päätettiin suorituskyvyn tasaisuutta katsoa hieman eri kantilta kuin muut sivustot. Apuna käytettiin jälleen Iometer–ohjelmaa, jolla pyrittiin simuloimaan käytettyä asemaa kirjoittamalla asemalle satunnaista neljän kilotavun dataa jononsyvyydellä 32 yhden tunnin ajan, jonka jälkeen asemalle ajettiin samat testit kuin tyhjälle ja 90 % täydelle asemalle. Käytettävä levytila rajattiin samaksi kuin pelkässä 90 % täyttötestissä, jotka on listattu yllä olevassa taulukossa. Tämäkin testi on todennäköisesti rankempi, kuin mitä tehokäyttäjä tekee asemallaan eikä sen vuoksi ole täysin realistinen, mutta antaa kuvan siitä, mitä suorituskyky voi pahimmillaan olla. Toistettavuuden takia käyttöä jouduttiin simuloimaan Iometerillä, sillä muuten olisi vaikea taata, että kaikki asemat olisivat lähtökohtaisesti samassa tilassa.

• CrystalDiskMark 3.0.3 x64
• Adobe Lightroom 5.3 64-bit
• Battlefield 4
• BootRacer 4.6
• Iometer 2010.03.25

Synteettiseen testaukseen käytettiin kuluttajienkin keskuudessa suosittua CrystalDiskMark-ohjelmaa, joka mittaa sekä perättäistä että satunnaista luku- ja kirjoitusnopeutta. Käytännönläheisempinä testeinä käytettiin erikokoisten tiedostojen kopiointia, Lightroomin asentajan purkua, ohjelman asennusta seka kuvien tuontia ohjelmaan, Battlefield 4 –pelin ja kampanjan latausaikaa ja viimeisenä Windowsin käynnistysaikaa.

CrystalDiskMark 3

850 EVO ja MX100 pärjäsivät hyvin perättäisessä lukutestissä ja molemmat tarjosivat SATA 6 Gb/s –asemille tyypillisen yli 500 megatavun sekuntinopeuden, mutta erot asemien välillä jäivät marginaalisiksi.

Perättäisessä kirjoitustestissä 850 EVO pärjäsi huomattavasti paremmin kuin MX100, joka johtui pitkälti TurboWrite–ominaisuudesta. Koska CrystalDiskMark kirjoittaa vain muutamia gigatavuja dataa, tallentui koko testin data ensiksi TurboWriten SLC-välimuistille, joka on nopeampaa kuin MLC- tai TLC-tilassa operoivat piirit. Lisäksi MX100:n “huonoutta” selitti 128 gigabitin NAND-piirit, jolloin piirien rinnakkaisuus jäi 256 gigatavun asemassa vajavaiseksi. Sama ilmiö oli huomattavissa myös esimerkiksi Intelin 730-sarjan kohdalla, jossa on käytössä 20 nanometrin viivanleveydellä valmistetut 128 gigabitin MLC-piirit.

512 kilotavun satunnaislukutestissä sekä 850 EVO että MX100 suoriutuivat vahvasti, mutta erot modernien asemien välillä olivat melko mitättömiä.

512 kilotavun satunnaiskirjoitustestissä loisti erityisesti 512 gigatavun MX100, joka oli huomattavasti nopeampi kuin 850 EVOt ja 256 gigatavun MX100, vaikka ei kuitenkaan aivan yltänyt nopeimpien asemien tasolle. Toisaalta MX100 aseman kohdalla oli huomattavissa käytöstä johtuvaa kirjoitusnopeuden hidastumista, mitä ei taas 850 EVOn kohdalla tapahtunut.

Neljän kilotavun satunnaislukutestissä 850 EVO sen sijaan dominoi ja oli nopein Muropaketin testaama SSD-asema. MX100:n suorituskyky oli maltillisempaa, mutta silti keskivertoa.

Neljän kilotavun satunnaiskirjoitustestissä 850 EVO ja MX100 suorituivat keskiverrosti, mutta tulosten huomattava vaihteluväli teki tarkemmasta analysoinnista hankalaa.

4K-32-satunnaislukutestissä sekä 850 EVO että MX100 pärjäsivät loistavasti ja molempien asemien kohdalla nopeudet lähentelivät 400 megatavua sekunnissa.

4K-32-satunnaiskirjoitustestissä tulosten heittely hankaloitti tulkintaa jälleen, mutta tulosten perusteella voitiin jälleen huomata MX100:n hidastuminen käytössä.