22
-
Szeszmester #1 Egy ilyesmi meghajtónak mekkora az olvasási sebessége?
Egy sima vinyóval összehasonlítva mennyivel gyorsabb? -
#2
"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."
Számomra ez csak egyféleképpen fordítható le, az pedig a garanciális idő években mért hossza. Mert hát nem kicsit furcsa olyan drive-okról olvasni, amelyekre a gyártó 1.5 - 2 millió órás MTBF-et ad meg, de csak 1 év garanciát vállal.
Szerencséjükre a kapacitás növekedésével még változatlan technológia mellett is javul a helyzet, mert egy tízszeres kapacitású meghajtóra valószínűleg nem fogunk naponta tízszer annyit írni.
-
falconmaster #3 Minimum kétszer, de inkább háromszor...
Igazán elindulhatnának már az árak egy erőltetett menetű csökkenésben - SSD nélkül nem Netbook a Netbook, de ha 150e+-ot kell érte fizetni (SSD-vel) akkor meg úgyszintén nem netbook a netbook, szóval jó lenne már ha a technológia meg a megfizethető ár találkozna... -
Rexhawk #4 Sandisk 120 GB-os SSD-je 200/140 MB/s-os sebességgel pörög és "mindössze" 250 dollár
kb 50000 forint
Szeszmester:
ez igez váltózó 150 től mehet akár 1500 MB/s-ig is.
amikor utoljára néztem tesztek a HDD-ről 90/70 MB/s volt az olvasási/irási sebessége
KillerBee:
"amelyekre a gyártó 1.5 - 2 millió órás MTBF-et ad meg, de csak 1 év garanciát vállal."
mert az MTBF annyi is, csak van egy másik érték az SSD-nél, mert iráskor aa szektorok leamortizálódnak, így nem bir ki akármennyi irási ciklust.MLC-nél 10 és 100 ezer között van, a SLC pedig 100 ezer és 1 millió -
bigjoe #5 Hát Linux tuti nem csapja szét hamar, mert ha elég a gépben a memória nem nyúl a lemezhez (swap).. Sajnos a Windowsról ez nem mondható el.. -
#6
Csak nem marketinges vagy? 1500MB/s-ot az interfész sem bír el, vagyis ennyit még burst módban sem tud a drive. PCI-e csatolóval elvileg tudhatná, de kevés az ilyen drive.
Ismerem a lebegő kapus (floating gate) MOSFET-ek működési elvét, sőt programozásuk és törlésük módját is. :) De számomra továbbra is a garancia hossza mérvadó, mert nem tudok mit kezdeni olyan MTBF-értékkel, amely csak olvasás esetén érvényes. Vagy ha a gyártó szerint napi x GB adat írása mellett pl. 10 évig jó lesz a drive, akkor vállaljon is rá 10 év garanciát. -
Rexhawk #7 apacer: 5 év
intel, kingston: 3 év
pqi, samu, transcend, corsair, buffalo: 2 év
super talent, imation, csx: 1 év
az 1500 MB-ot pedig azért mondtam mert az volt a legnagyobb amiről halottam (természetesen PCI-e csatolóval) -
kvp #8 Egy ssd-nel nagyon sokat szamit, hogy milyen modon irjuk a diszket. Ez pl. egy 8 szorosan raid0-ba pakolt ssd, tehat 4 KB-os blokkmeret eseten 32 KB-os szektormeret kell. Ha a formazasnal ezt kisebbre vesszuk, akkor minden blokkot tobbszor fog irni a rendszer mint ahanyszor szukseges. (a winnt rendszerek alap 512-es blokkmerete eseten 64-szer gyorsabban hasznalodik el a diszk, mint ami a normalis hasznalatot jelentene. Tehat nem a technika a rossz, hanem a felhasznalok nem tudjak hogyan kell rendesen hasznalni. Ha alap beallitasok mellett kibir egy ssd 1 evet, akkor korrektul hasznalva ez valahol a 32 es a 64 ev kozott lesz. A lenyeg, hogy az aramkorre forrasztott memoriachip-ek belso blokkmeretet fel kell szorozni a vezerlo altal parhuzamosan kotott csatornak szamaval es erre az ertekre kell beallitani a filerendszer blokkmeretet. -
#9
Igaz, amit írsz, de ebben a gyártó is ludas, ha öles betűkkel nem hívja fel a user figyelmét a helyes blokkméretre.
Amúgy a lebegő kapus technológia igenis rossz, de a gyártók nem fejlesztenek, amíg ezt is el lehet adni. Pedig vannak sokkal tartósabb alternatívák, csak pénzt kellene költeni a fejlesztésükre. -
blackeagle #10 hello , erről van valami magyar infó ? vagy csak itt töled ,mert eddig nem halottam róla pedig hasznos -
llax #11 Nincs garancia arra, hogy azonos blokkméret esetén a blokkok bit pontossággal fedik egymást, azaz a fájrendszer 4kB-os blokkja pontosan 1db. 4kB-os flash blokkot fog használni.
Ez csak egy szorosabb fájlrendszer-SSD együttműködés esetén valósulhatna meg, azaz kellene egy spéci SSD driver, vagy legalább spéci formázóprogram, ami pontosan a fizikai blokkokba teszi a fs blokkjait (és nincs pl. feles átfedés). Esetleg még az SSD mutathatna a külvilág felé a blokkokkal azonos méretű és azt fedő "szektor"méretet. -
Kheller #12 butaság a köbön...
esélyed nincs a fizikai blokkok méretéhez igazitani a filerendszert. Talán 10 éve még lehetett, de ma, főleg ssd-ken köze nincs az oprendszernek, de még a vinyóvezérlőnek se az eszközök fizikai tárolási adatairól. A vinyóvezérlő egy sorfolytonos számot lát (LBA) ird a 2343598435-es blokkra azt, hogy akármi, aztán ezt a vinyó ill az ssd belső vezérlője leforditja amire akarja, lemezekre, fejekre, sávokra vagy éppen memória modulok cimeire (figyelembe véve badsectorokat, wear levelingget és még ezer más dolgot) -
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. -
vasziszdasz #14 Rakd memóriába a swapfilet, akkor az se fog. -
vasziszdasz #15 Lehet hogy szekvenciálisan annyit "pörög", csak épp randomban behal (mint mindne jmicronos).
![]()
-
#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. -
#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. -
Hierogli #18 Nem ertem miert nem nyomatjak az olcso raid controllerekkel az olcso es lassu SSD-ket:
http://www.youtube.com/watch?v=96dWOEa4Djs -
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. -
#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 #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) -
#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.
