Hirdetés

Aktív témák

  • fLeSs

    nagyúr

    épp egy indilinxes SSD-t tesztelek, és elég érdekes eredményeket kapok.
    alapvetően majdnem úgy kezdem a tesztelést ahogy az anandtech, tehát iometer, 1 MB szekvenciális olvasás/írás, aztán 4K/4konkurens és 4K/64konkurens olvasás/írás.
    úgy tűnik, hogy az anandtech iometeres tesztelési módja részben nem ad megbízható eredményeket az SSD valós teljesítményére vonatkozóan.

    ő azt csinálja a 4K-s méréseknél, hogy létrehoz egy 8 GB-os tesztfájlt, és így méri le a random olvasást/írást. ezzel az a probléma, hogy így mindig az vadiúj SSD sebességét kapjuk vissza írásban, mert amikor felkerül a tesztfájl az SSD-re, azzal "betömíti" a cellákat, így elvileg ha ugyanoda írnánk vissza az adatot, akkor gyengébb eredményt kapnánk (hiszen másodszorra akarna odaírni). csakhogy az SSD belül megoldja azt, hogy a még szabad tárterületen (a 8 GB-on felüli részen) elossza a valós tesztelés közben bekövetkező írásokat, ergo egy új SSD írási teljesítményét kapjuk vissza ha az támogatja a TRIM-et.

    én egy az SSD méretének megfelelő tesztfájlt hoztam létre, és az írási sebesség lement a béka feneke alá, mert ugye az SSD-nek már nem volt hova elosztania a teszt írásait (pontosabban a legelején a "spare area" miatt még normális sebességű, de aztán amikor ebből kifogy, hirtelen lezuhan). a spare area ugye az általunk nem látott terület ahova ettől függetlenül az SSD még dolgozhat. ha van egy 64 GB-os SSD és formázás után csak 59 GB-ot látunk belőle az azt jelenti, hogy 5 GB a spare area, amit mi nem látunk, de az SSD igen.

    szóval. most akkor az a kérdés, hogy melyik írási sebesség a mérvadó?
    amikor felinstallálunk vmit a gépre az az üres területre megy tehát ott full sebességű az írás.
    viszont amikor egy program a már felírt adatokat módosítja (mondjuk a win a pagefájlt) sokadszor ott már kénytelen a read-modify-write ciklust lefuttatni, ergó sokkal lassabb lesz mint az első esetben.

Aktív témák