Testikokoonpano & suorituskykymittaukset

Testikokoonpano

Testialusta vaihtui jälleen kerran ja nyt käytössä on Intel Haswell -pohjainen kokoonpano, joka tulee myös vakiintumaan Muropaketin SSD-testialustaksi. Kokoonpanossa on Intelin 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 toimi prosessoriin integroitu Intel HD Graphics 4600. Biosista kytkettiin prosessorin C-virtatilat eli virransäästötilat pois päältä, sillä SSD-aseman suorituskyky ei välttämättä saavuta huippuarvoja, 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

• 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

Testit suoritettiin asentamalla 64-bittinen Windows 7 Ultimate ja SP1–päivitys apuasemana toimineelle Corsair Force LS –SSD-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.

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

• 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

Mittausmetodit

Uutuutena testeissä oli kolme eri testauslähtökohtaa: tyhjä, 90% täysi ja ”käytetty”. Kuten kiintolevyjen, myös SSD-asemien suorituskyky hidastuu aseman täyttyessä. Ei siis ole käytännön kannalta todenmukaista testata asemaa niin, että asennettuna on vain käyttöjärjestelmä ja testiohjelmat, jotka täyttävät asemasta yhteensä vain noin kolmanneksen eli 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-nimisen 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 päivittävät jatkuvasti muun muassa eri logitiedostoja, 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-operaatiossa (read-modify-write) 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äsittelemään 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 netin tietotekniikkasivustoista käyttää suorituskyvyn tasaisuuden testaamisen pelkästään synteettistä testiä, jossa koko aseman kapasiteetille kirjoitetaan satunnaista neljän kilotavun dataa jononsyvyydellä 32 (queue depth). 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. Tavallisen kuluttajan näkökulmasta tälläinen käyttö ei kuitenkaan vastaa todellisuutta, 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 muilla sivustoilla. 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
• Microsoft Security Essentials
• BootRacer 4.6
• Iometer 2010.03.25

Synteettiseen testaukseen käytettiin kuluttajienkin keskuudessa suosittua CrystalDiskMark-ohjelmaa, joka mittaa sekä peräkkäistä että satunnaista luku- ja kirjoitusnopeutta. Käytännönläheisempinä testeinä käytettiin erikokoisten tiedostojen kopiointia, Lightroomin asennustiedoston purkua, ohjelman asennusta seka kuvien tuontia ohjelmaan, Battlefield 4 –pelin ja kampanjan latausaikaa, Microsoft Security Essentialsin nopeaa haittaohjelmatarkastusta ja viimeisenä Windows-käyttöjärjestelmän käynnistysaikaa.

CrystalDiskMark

CrystalDiskMarkin perättäisluku testissä ei ole suurta huomioitavaa, sillä kaikkien asemien suorituskyky on hyvin lähellä toisiaan. Ainoastaan Samsungin 840 sarjan ja OCZ:n Vertex 450:n suorituskyky hieman heikkenee täytön tai käytön johdosta. Samsungin kohdalla kyse on todennäköisesti TLC NAND-piirien käytöstä, jotka ovat hitaampia ja näin ollen myös roskienkeruu prosessi on hitaampi, joka vuorostaan näkyy isäntäoperaatioiden lievänä hidastumisena.

Vertex 450:ssä kyseessä on OCZ:n kutsuma ”suorituskyky” –tila (performance mode), joka on käytössä, kun alle puolet aseman kapasiteetista on täytetty. Tällöin muistipiirit toimivat SLC-moodissa, eli kahden bitin sijaan yhteen soluun koodataan vain yksi bitti, joka parantaa suorituskykyä hieman. Kun yli puolet asemasta täytetään, kaikki data joudutaan uudelleenjärjestelemään, joka vie joitakin minuutteja, mutta tänä aikana suorituskyky on heikompi, koska asemassa on meneillään lukuisia sisäisiä luku- ja kirjoitusoperaatioita. Myös Vertex 460:ssä ja Vector 150:ssä on samainen ominaisuus, mutta joko OCZ on parantanut uudelleenjärjestelyalgoritmejaan tai Toshiban NAND-piirit ovat sen verran nopeampia, että vastaavaa hidastumista ei tapahdu.

Perättäisessä kirjoitusnopeudessa OCZ:n suorituskykytila näkyi myös muissa malleissa. Lukeminen NAND-piiriltä oli huomattavasti nopeampaa (noin 10-15 kertaa) kuin piirille kirjoittaminen, joten tämä on mahdollinen selitys sille, miksi hidastuminen näkyi lähinnä kirjoitusnopeudessa. On syytä huomioida, että hidastuminen tapahtui vain 90% täysi -testissä, mikä johtuu siitä, että käytetty-testissä datan uudelleenorganisointi oli jo ehtinyt tapahtua ennen varsinaista testausta.

Samsung 830:ssä oli myös havaittavissa pientä suorituskyvyn laskua käytettynä. Kyseessä ei vielä ollut dramaattinen hidastuminen, mutta valmistajien panostus suorituskyvyn tasaisuuten uudemmissa asemissa näkyi tässä hyvin.

512 kilotavun satunnaiskirjoitustestissä erot alkoivat konkretisoitua ja useamman aseman suorituskyky laski käytön johdosta.

Neljän kilotavun satunnaislukutestissä ei ollut erityistä huomoitavaa. Ainoastaan Samsung 840 Pro ja 840 EVO erottuivat edukseen, siinä missä muiden asemien suorituskyky oli lähes samalla viivalla.

Neljän kilotavun satunnaiskirjoitustestissä erot jälleen kasvoivat ja jyvät eroteltiin akanoista. OCZ:n asemat olivat tässä vahvoilla poislukien tilanteet, joissa suorituskykytilan aiheuttama datan uudelleenorganiointi hidasti asemia.

Kuluttajakäytössä jononsyvyys harvoin nousee yli viiden, joten 32:n jononsyvyys ei ole realistisimpia tapauksia, mutta voi olla asiaankuuluva vaativille tehokäyttäjille ja antaa myös kuvan aseman suorituskyvyn skaalautuvuudesta. OCZ ei päässyt muiden asemien tasolle lukutestissä ja ero oli pahimmillan jopa kaksinkertainen Samsungin johtaessa joukkoa.

Kirjoitustestissä OCZ sen sijaan loisti, eikä aseman käyttäminen näyttänyt heikentävän suorituskykyä.

Tiedostojen kopionti

Tiedostojen kopioinnissa mittaamiseen käytettiin sekuntikelloa ja testi suoritettiin kopioimalla tiedostoja Windows 7:n työpöydällä.

Pienten tiedostojen kansiossa tiedostoja oli yhteensä 2769 kahden ja 19 kilotavun välillä ja kokoa kansiolla oli 29,1 megatavua. Asemilla ei sekunnin tarkkuudella ollut eroja tässä testissä, mikä johtuu osittain välimuistin käytöstä kirjoitusoperaatioissa. Sen sijaan, että data kirjoitettaisiin suoraan NAND-piirille, asemat käyttivät DDR-välimuistia datan väliaikaiseen tallentamiseen, josta data myöhemmin kirjoitetaan NAND-piireille. Tarkoituksena on nopeuttaa etenkin pieniä kirjoitusoperaatioita, joiden kirjoittaminen on muuten hidasta. Muutaman sekunnin eroja syntyi, kun välimuistin käyttö kytkettiin pois päältä, mutta tämä ei taas vastaa kuluttajan näkökulmaa, sillä välimuisti on vakiona päällä.

Sekalaisten tiedostojen kansiossa tiedostoja oli yhteensä 3655, joiden koko vaihteli kahden ja 912:sta kilotavun välillä. Kokoa kansiolla oli 401 megatavua. Nyt eroja alkoi syntyä, mutta kyse oli edelleen vain parista sekunnista. Sekunnin ero menee vielä kevyesti allekirjoittaneen reaktioajan syyksi, joten käytännössä tuntuvia eroja ei ollut.

Isona tiedostona käytettiin yhtä 4,37 gigatavun MKV-tiedostoa. Tässä testissä eroja alkoi jo syntyä ja etenkin Samsungin 840:n suorituskyky kärsi huomattavasti käytöstä. Muista asemista ainoastaan Seagate 600 oli muita hieman hitaampi ja muiden kohdalla ero oli jälleen yhden tai kahden sekunnin luokkaa.

Lightroom

Adobe Lightroom 5.3 64-bit ohjelmasta ladattiin kokeiluversion Adoben sivulta, joka toimitettiin 871 megatavun suuruisessa purettavassa exe-tiedostossa.

Asentajaa aukaistaessa asentaja pyytää ensin purkamaan tiedostot ennen kuin itse asennus alkaa. Purkuun kuluva aika mitattiin sekuntikellolla eikä huomattavia eroja asemien välillä ollut.

Asennuksessa eroja sen sijaan syntyi ja Vector 150 sekä Vertex 460 suoriutuivat muihin verrattaen erinomaisesti. Käyttö ei vaikuttanut suorituskykyyn paria sekuntia enempää lukuunottamatta Vertex 460:n 90% täyttötestiä, jossa suorituskykytilalla oli jälleen sormet pelissä.

Lightroomiin tuotiin 1063 Canon 550D –kameralla otettua jpg-kuvaa, joilla oli yhteensä kokoa 6,44 gigatavua. Erot olivat tässäkin marginaalisia ja on selvää, että pullonkaulat olivat jossain muualla.

Battlefield 4

Battlefield 4 oli valmiiksi asennettuna asemalle, joten testeissä keskityttiin latausaikoihin. Peli käynnistettiin offline-tilassa, jolla ehkäistiin mahdolliset nettiyhteyden aiheuttamat eroavaisuudet.

Pelin latauksessa sekuntikello käynnistettiin exe-tiedostoa avatessa ja pysäytettiin DICE-logon tullessa ruutuun. Jälleen kerran eroja ei käytännössä syntynyt.

Kampanjan latauksessa aloitettiin uusi kampanja normaalilla vaikeustasolla ja ajanotto aloitettiin vaikeustasoa klikattaessa ja pysäytettiin EA:n logon ilmestyessä ruutuun.

Haittaohjelmatarkistus

Virustarkastuksessa käytettiin kuluttajien suosiossa olevaa ilmaista Microsoft Security Essentials ohjelmaa, joka on allekirjoittaneellakin ollut jo vuosia käytössä.

Erot jäivät vain muutaman sekunnin luokkaan, joten paremmuutta oli vaikea selvittää. Ainoastaan Vector 150:n käytetty tulos osui silmään, mutta tämä on suurella todennäköisyydellä virheellinen. Reaalimaailman testeissä ongelmana on aina Windowsin mahdolliset itsepäiset operaatiot eli tarkistus on voinut alkaa jo taustalla.

Windowsin käynnistyminen

Käynnistysaikaa mitattiin kolmesti sekä käsin että Boot Racer ohjelmalla. Selvästi väärentyneet tulokset jätettiin huomioimatta ja testi uusittiin.

Käsin mitattaessa ajanotto aloitettiin virtanapin painalluksesta ja lopetettiin Windowsin työpöydän tullessa näkyviin. Mitään merkittävää eroa asemien välillä ei ollut.