OCZ Octane 512 GB SSD: Indilinxin Everest-ohjaimen ensiesiintyminen

Artikkelin kirjoittaja: Teemu Laitila | 0 kommenttia

Suorituskyky pidemmällä aikavälillä ja TRIM-komento



Suorituskyky puhtaalla asemalla



Aseman suorituskyvyn mittaaminen pidemmällä aikavälillä ei ole erityisen vaikaa. Ensiksi koko käyttäjälle tarjolla oleva tila täytetään peräkkäisellä datalla, mikä tekee asemasta "likaisen". Sen jälkeen aiempi data vielä ylikirjoitetaan 4 KB kokoisilla satunnaisesti sijoittuvilla tiedostoilla. Koska asema on täynnä dataa, roskienkeräys ei kykene yhtenäistämään hajanaista sisältöä ja vapauttamaan kokonaisia osioita. Kun asemalle taas kirjoitetaan peräkkäistä dataa, aktiivinen roskienkeräys saa mahdollisuuden toimia.

20 minuuttia satunnaista kirjoitusta



Iometerin mittaustulosten mukaan peräkkäisten luku- ja kirjoitusnopeuksien pitäisi tuoreen aseman kohdalla olla 340/260 MB/s. Mutta kun asema ensin täytetään peräkkäisellä datalla ja sen jälkeen sitä moukaroidaan satunnaisemmalla sisällöllä kahdenkymmenen minuutin ajan, seuraavien peräkkäisten kirjoitustestien tulokset alkavat näyttää jo melko erilaisilta. Vaikka peräkkäiskirjoitusnopeus alkaa 250 MB/s vauhdilla, se tippuu nopeasti vain 6 MB/s vauhtiin.

Vaikkakin testaustapa on rankasti nopeutettu, testin tarkoituksena on simuloida pahinta mahdollista tilannetta, johon joudutaan kun koko asema on kertaalleen kirjoitettu täyteen eikä ohjaimelle jää tilaa omiin roskienkeräystoimintoihinsa.



Pienen odottelun jälkeen ohjain pystyy palauttamaan osan suorituskyvystä, mutta silti kirjoitusnopeus jää 40 - 50 megatavuun sekunnissa.

30 minuuttia satunnaista kirjoitusta

Tiedämme jo aiempien testien perusteella, että jo pakasta vedetyn Octanen suorituskyky satunnaisoperaatioissa jää jälkeen muista 6 Gb/s -liitäntään perustuvista asemista. Sen vuoksi pelkkä 20 minuutin satunnaiskirjoitus ei riitä "likaamaan" kaikkia muistisoluja, kun käytetään jononsyvyyttä neljä. Jäljelle jää vielä joukko "puhtaita" soluja, jotka estävät tilannetta muodostumasta vieläkin huonommaksi.



Jos jononsyvyys kasvatetaan aina 32 saakka ja asemalle kirjoitetaan yhteensä 30 minuutin verran eli käytännössä toistetaan aiempi testi vielä voimakkaampana, suorituskyky tipahtaa vain 7 megatavuun sekunnissa, mille tasolle se myös jää. Vaikka aseman jättäisi kuinka pitkäksi aikaa lepotilaan roskien siivousta suorittamaan, suorituskyky ei nouse normaaleihin lukemiin. Pyysimme OCZ:lta kommenttia tähän ongelmaan, mutta yhtiöstä ei vastattu tiedusteluihimme. Jos aseman onnistuu saamaan kokonaan likaiseksi, suorituskyky on pilalla.

Ylijäämätilan kasvattaminen

Toisin kuin monissa muissa asemissa, Octanessa ei ole jätetty yhtään NAND-muistia "reserviin". Sama tilanne on Crucialin m4-asemassa, mutta silti se pystyy toipumaan paremmin, vaikka aseman koko kapasiteetti olisi kertaalleen käytetty. Mikä on siis Octanen ongelma?

Suorituskyvyn voisi olettaa parantuan, jos asemalle luodaan todellista kokoa pienempi partitio eli käytännössä luodaan muistireservi manuaalisesti. Silti Octanen ongelmat eivät tunnu ratkeavan niinkin yksinkertaisesti, kuin emuloimalla ylimääräistä tallennustilaa jättämällä osa tallennustilasta partitioimatta. Alla olevat diagrammit selventävät asiaa:





Kun "over-provisioning" tilaa tehdään manuaalisesti, ohjain kykenee suorittamaan tehokasta roskienkeräystä vielä senkin jälkeen kun asema on täytetty ääriään myöten satunnaisella kirjoituksella. Tässä on silti yksi ongelma. Suorituskyvyn toipuminen uutta vastaavaan tilaan on suoraan verrannollinen aseman käyttöön tarjotun partitioimattoman tilan määrään. Ensimmäisessä diagrammissa aseman tilasta jätettiin käyttämättä 2,5 prosenttia ja suorituskyky pysyy hyvänä hetken aikaa. Toisessa diagrammissa asemasta jätettiin käyttämättä puolet ja sen jälkeen suorituskyvyn tippumista ei enää havaittu.


Ongelmana on kuitenkin se, että kukaan tuskin haluaa jättää puolia kalliin 512 GB aseman kapasiteetista käyttämättä, jotta suorituskyky pysyy hyvällä tasolla. Käytännössä siis ainut keino Everest-ohjaimella varustettua asemaa käyttäessä on pitää huoli siitä, että käytössä on TRIM-toimintoa tukeva käyttöjärjestelmä. Se tarkoittaa, että näitä asemia on turha käyttää RAID-kokoonpanoissa tai vanhemmilla käyttöjärjestelmillä.

Siirretään H.264-formaatissa oleva elokuva
Keskimääräinen kirjoitusnopeus
Puhtaalle asemalle
Likaiselle asemalle
Ei ylimääräistä tilaa käytössä
~ 250 MB/s
~ 7 MB/s
2.5% ylimääräistä tilaa
~ 250 MB/s ~ 10 MB/s
50% ylimääräistä tilaa
~ 250 MB/s ~ 250 MB/s


Tässä on saman tyyppinen koe esitettynä hieman selkeämmin. Ero "puhtaan" ja "likaisen" aseman välillä on silmiinpistävä, kun asemalle kirjoitetaan 32 GiB Blu-ray-rippi. Ilman kohtuuttoman suurta muistireserviä, siirtonopeus tippuu sietämättömän alas.

Suorituskyky TRIM-tuen kanssa



Onneksi tämänkin aseman suorituskyvyn pelastaa TRIM-tuki. Testien perusteella kävi selväksi, että aseman suorituskyky ei parane taustalla tehtävän roskienkeräyksen avulla, vaikka aseman annettaisiin toimia kuinka kauan. Mutta jos TRIM-komento käynnistetään tyhjentämällä Windowsin roskakori, nopeus palautuu normaalille tasolle, kuten käy ilmi yllä olevasta diagrammista.

Kommentoi artikkelia