Gyurkity Péter

Gyors SSD-t dob piacra a Super Talent

A Super Talent által a napokban bemutatott MLC SSD-meghajtók igazi érdekessége, hogy sebességben elérik a kifejezetten vállalati felhasználásra szánt SLC-változatok által nyújtott szintet.

A MasterDrive SX névre keresztelt sorozat tagjai kivétel nélkül MLC-technológiával készülnek, kapacitásuk sorrendben 64, 128, illetve 256 GB. Az SSD-meghajtók piacon otthonosan mozgó cég ezúttal elsősorban nagyobb sebességet, megbízhatóságot, valamint agresszív árstratégiát ígér, ami azért érdekes, mert az első két területen eddig az SLC-változatok vezettek magabiztosan, bár többnyire horribilis árak mellett.



A hivatalos sajtóközleményben szereplő adatok alapján azonban a Super Talent sikeresen közelebb hozta egymáshoz a két különböző technológiát képviselő meghajtóit. Az új változatok ugyanis legfeljebb 220 MB/s írási sebességet nyújtanak, miközben a cég korábban piacra dobott, csúcskategóriás UltraDrive SLC-meghajtói ezen a területen 230 MB-ot érnek el másodpercenként. Mindezt a saját fejlesztésű nyolccsatornás vezérlővel, valamint 128 MB integrált DRAM-memóriával érik el, amely a gyorsítótár szerepét tölti be.

Ami a megbízhatóságot, illetve az élettartamot illeti, itt pontos adatokat nem közöltek, ám a gyártó ígéretet tett arra, hogy háttértárolói hosszú időn keresztül a vásárlók szolgálatára állnak majd, amit úgy fordíthatunk le, hogy az átlagosnál hosszabb ideig szolgálnak majd gond nélkül. Ez - már amennyiben a mindennapokban is így lesz - mindenképpen kedvező fejlemény, hiszen a nagyobb sebességet eddig többnyire az élettartammal kapcsolatos félelmek ellensúlyozták, amikor a választásra került sor a vásárlók részéről.

Az árak sajnos még mindig kissé magasnak mondhatók, hiszen például a 128 GB-os változat 360 dollárért lesz kapható az üzletekben. A 256 GB-os példányok ennél nyilván jóval többet kóstálnak majd, míg a 64 GB-os tárolók valamivel közelebb lesznek az emészthető szinthez.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • KillerBee #22
    "a legtobb problema abbol adodik, hogy az irasi blokknal is kisebb a blokkmeret, tehat minden irasnal van egy olvasas/torles/iras ciklus."

    Aha, te írási blokknak nevezed azt, amit én page-nek. Az általad említett szituáció tényleg SSD-gyilkos.
  • kvp #21
    "A kisebb szektor- ill. page-méret azért nem mindig tragikus, mert ha már törölt egy blokkot, akkor az abban lévő page-ek már egyenként, a blokk törlése nélkül is írhatók. Gond csak akkor van, ha felül kell írni egy page-et, mert hát akkor az egész blokkot újra kell törölni és a benne lévő összes page-et újraírni, ez a nagy időveszteség."

    Nem egeszen. Van torlesi blokk es irasi blokk. A filerendszer eseten az idealis, ha a torlesi blokkot hasznaljuk, de a legtobb problema abbol adodik, hogy az irasi blokknal is kisebb a blokkmeret, tehat minden irasnal van egy olvasas/torles/iras ciklus. A legjobb teljesitmenyt es sebesseget a legnagyobb blokkmeret adja, ahol egy filerendszer blokk mindig egyben torlodik es irodik. Sok kis file eseten ez eleg nagy helypazarlas, viszont nagyobb file-ok eseten igy lesz megbizhato es gyors a filerendszer. Ha 4KB helyett 4MB-os swap page-eket hasznalunk, akkor meg a windows swap file-ja is mehet ssd-re a nelkul, hogy tonkrevagnank azt. (igy kb. 10-20 evet is kibir az ssd swap meghajtokent) A windows-ok kozzul a szerver valtozatok szoktak kezelni a nagy meretu lapokat es 2GB fizikai ram felett erdemes oket hasznalni. Nemcsak gyorsabb lesz a gep az ssd miatt, de a kernel is kevesebb cpu idot tolt a lapozassal, foleg ha dma-t is hasznal a diszk vezerlo. Tehat a technologia megvan, a minoseggel sem lenne gond, de a legtobb ember nem tudja, hogyan kell jol hasznalni egy ssd-t. (az operacios rendszerek meg egyelore meg nem gondolkodnak a felhasznalok helyett, de azert ez valtozni fog pl. a win 7-el)
  • KillerBee #20
    A kisebb szektor- ill. page-méret azért nem mindig tragikus, mert ha már törölt egy blokkot, akkor az abban lévő page-ek már egyenként, a blokk törlése nélkül is írhatók. Gond csak akkor van, ha felül kell írni egy page-et, mert hát akkor az egész blokkot újra kell törölni és a benne lévő összes page-et újraírni, ez a nagy időveszteség.
  • kvp #19
    "Nem ertem miert nem nyomatjak az olcso raid controllerekkel az olcso es lassu SSD-ket:"

    Ez olyan, csak eppen a raid-tol olcso es gyors lesz, az mlc-tol meg lassu, tehat kapunk egy olcso es lassu ssd-t. A cikk errol szol. Egyebkent a megadott sebesseget csak akkor tudja, ha blokkra igazitva irjuk szekvencialisan, barmilyen mas esetben joval lassabb lesz. (kijon a kis blokkmeret miatti read/modify/write es az mlc atka) A lassu iras fo oka, hogy nincs megfelelo ram alapu write cache a rendszerben, de ezt a modernebb meghajtok mar kikuszoboltek. (sokat hasznal az is ha veletlenszeru irasnal is csak fizikai blokkonkent irunk)

    "Nem látom okát, hogy az eszköz kifelé miért NE olyan logikai elrendezést mutasson, amelynek határai a belső page határokhoz vannak igazítva, hiszen így sokkal egyszerűbb a két felépítés átszámítása."

    Igen, a gyartok tobbnyire az olcsobb, egyszerubb es gyorsabb megoldast hasznaljak, ami blokkra igazitas. De ha valaki akarja ellenorizheti a vezerlochip adatlapjan. Ezert kell a vezerlo es a memoriak adatlapja, hogy meg lehessen allapitani a valos blokkmeretet, ami ilyen megoldasoknal egy jo nagy szam lesz. (pl. 32 vagy 64 KB) Ha ezt hasznaljuk akkor a gyari sebesseg ertekeket fogjuk megkapni, meghozza a flash megnovekedett elettartalma mellett. (tehat a gyari mtbf ertekeket)

    A windows7 egyik uj fejlesztese elvileg pont az lenne, hogy helyettunk kiszamitja es beallitja a megfelelo blokkmeretet formazaskor. Ugyanis kb. ennyi kell a driver optimalizaciojahoz. A tobbit mar a hardveres wear levelling elintezi.
  • Hierogli #18
    Nem ertem miert nem nyomatjak az olcso raid controllerekkel az olcso es lassu SSD-ket:

    http://www.youtube.com/watch?v=96dWOEa4Djs
  • toyotakacsa01 #17
    Az "SSD teszt" szóra rákeresve lehet találni egy tavaly nyári tesztet, ott egész sok okosság le van írva. Akit érdekel a téma, guglizzon rá. Azóta nem tudom mennyire gyorsultak a cuccok, de akkor még nem nagyon voltak elájulva a tesztelők a teljesítményüktől.
  • KillerBee #16
    Nehezen tudom elképzelni, hogy ne fednék egymást bitre pontosan. A NAND flash eszközök csak blokkonként törölhetők, egy blokk mérete többnyire 512kB. Írni és olvasni viszont page-enként lehet őket, akár egy blokkon belül is, egy page többnyire 4kB. Szó sincs arról, hogy bárhol elkezdheted írni vagy olvasni a fizikai memóriát, az egyes memóriacellák szervezése és elérése ezt nem teszi lehetővé (NOR esetén igen, de NAND-nál nem).

    Nem látom okát, hogy az eszköz kifelé miért NE olyan logikai elrendezést mutasson, amelynek határai a belső page határokhoz vannak igazítva, hiszen így sokkal egyszerűbb a két felépítés átszámítása.
  • vasziszdasz #15
    Lehet hogy szekvenciálisan annyit "pörög", csak épp randomban behal (mint mindne jmicronos).

  • vasziszdasz #14
    Rakd memóriába a swapfilet, akkor az se fog.
  • vasziszdasz #13
    És milyen vezérlp lesz benne? Ha nem merik leiírni, akkor lehet hogy csak egy fos jmicron, annak meg hiába a gyors soros írás, ha lagol mint állat.