Toshiba valmistelee 5 bittiä soluun tallentavia PLC-NAND-muisteja ja nopeita XL-Flash-muisteja

  • Keskustelun aloittaja Keskustelun aloittaja Kaotik
  • Aloitettu Aloitettu

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
22 630
toshiba-plc-nand-flash-20190827.jpg



Toshiba on esitellyt Flash Memory Summit -tapahtumassa omia lähitulevaisuuden suunnitelmiaan. Yhtiö esitteli tapahtumassa muun muassa tarkempia yksityiskohtia sekä tulevista XL-Flash- että BiCS Flash -muisteista.

Flash-markkinoilla on tullut tämän vuoden aikana tarjolle uusia 4 bittiä per solu tallentavia QLC- eli Quad-level Cell -NAND-muisteja. Kehitys ei ole päättymässä kuitenkaan tähän, vaan Toshiballa on jo työn alla PLC- eli 5 bittiä per solu tallentavat Penta-level Cell -NAND-solut. PLC-soluille ei ole tässä vaiheessa antaa mitään aikataulua, mutta yhtiö kertoo onnistuneensa tuottamaan jo toimivia soluja nykyisiä QLC-soluja muokkaamalla.

Yhä enemmän bittejä per solu tallentavia NAND-muisteja tarvitaan tyydyttämään markkinoiden tarve suuremman kapasiteetin SSD-asemalle. Samalla kärsii kuitenkin solujen kestävyys ja luotettavuus. PLC-solujen toimiminen vaatii, että kukin solu kykenee tallentamaan luotettavasti peräti 32 jännitetasoa ja luonnollisesti ohjaimen, joka kykenee myös lukemaan ne luotettavasti.

Toshiban suorituskykyinen XL-Flash on suunniteltu kilpailemaan ennen kaikkea Samsungin Z-NAND- ja Intelin Optane-asemien kanssa. Toshiban mukaan XL-Flash kykenee alle 5 mikrosekunnin lukuvasteaikoihin, mikä on noin 10 kertaa nopeampaa kuin tyypillisillä TLC-NAND-piireillä. Itse sirut ovat kooltaan 128 gigabittisiä ja ne tulevat saataville 2, 4 ja 8 sirun paketoinneissa. Muistien sivukoko on 4 Kt. Yhtiö uskoo voivansa aloittaa nopeille vasteajoille optimoituihin SLC-soluihin perustuvien XL-Flash-tuotteiden massatuotannon ensi vuonna.

Lähde: Tom's Hardware

Huom! Foorumiviestistä saattaa puuttua kuvagalleria tai upotettu video.

Linkki alkuperäiseen uutiseen (io-tech.fi)

Palautelomake: Raportoi kirjoitusvirheestä
 
Viimeksi muokattu:
Kun QLC ei ollut tarpeeksi huono..

Joku voi vielä saada sen kuvan, että tämä on ainoa tapa saada lisää tilaa. Tilaa saa kahdella tavalla:
1) Laitetaan enemmän bittejä per solu, niinkuin nyt.. TLC -> QLC -> PLC on aina 2x tilaa lisää per nuoli, eli QLC -> PLC = 2x ja TLC -> PLC on 4x..
2) Tehdään parempi tuotantoprosessi, siinä vastaavat nuolet menisivät 14nm->10nm>7nm, eli 10nm->7nm = 2x ja 14nm->7nm->4x... Tämä tietenkin olettaen, että transistorimäärä menee prosessin mukaan oikein (eikä ole ns. markkinointiluku) ja se vaikuttaa suoraan tallennustilaan .

Järkevämpää on tehdä tavalla #2. Tapa #1 tuottaa helpommin halvempia levyjä, jotka hajoavat nopeammin. Yritykset tykkää, että on "halpa valmistaa" asema (paremmat katteet), joka hajoaa heti takuuajan jälkeen. Kuluttajien ei pitäisi.

edit: tilankasvu bittien lisäämisellä ei mene ihan noin.. Monta vastausta jaksoin kirjoittaa toisella kädellä, ennenkuin tarkistin asian. Olen väärässä tässä.
 
Viimeksi muokattu:
Kun QLC ei ollut tarpeeksi huono..

Joku voi vielä saada sen kuvan, että tämä on ainoa tapa saada lisää tilaa. Tilaa saa kahdella tavalla:
1) Laitetaan enemmän bittejä per solu, niinkuin nyt.. TLC -> QLC -> PLC on aina 2x tilaa lisää per nuoli, eli QLC -> PLC = 2x ja TLC -> PLC on 4x..
2) Tehdään parempi tuotantoprosessi, siinä vastaavat nuolet menisivät 14nm->10nm>7nm, eli 10nm->7nm = 2x ja 14nm->7nm->4x... Tämä tietenkin olettaen, että transistorimäärä menee prosessin mukaan oikein (eikä ole ns. markkinointiluku) ja se vaikuttaa suoraan tallennustilaan .

Järkevämpää on tehdä tavalla #2. Tapa #1 tuottaa helpommin halvempia levyjä, jotka hajoavat nopeammin. Yritykset tykkää, että on "halpa valmistaa" asema (paremmat katteet), joka hajoaa heti takuuajan jälkeen. Kuluttajien ei pitäisi.

Mä voisin ihan hyvin ottaa vaikka 6 bittiä soluun kirjoittavan levyn pelikirjastolleni, jos giga/€-suhde olisi nykyisiä parempi (hieman vajaa 10Gt per 1€) . Mä en tule sadassa vuodessakaan kirjoittamaan nykyistä QLC-levyäni puhki.

Ongelmia toki tulee siinä, kun esim läppärivalmistajat laittavat pelkän QLC-levyn koneeseen. Tai no ei kyllä peruskäyttäjällä sekään todenäköisesti kulu vielä puhki, mutta se alkaa olla jo käytännössä jossain tilanteessa mahdollista.

Valveutuneelle käyttäjälle tästä sen sijaan on vain etua. Saadaan edullisempaa ja äänetöntä tallennustilaa peleille, elokuville ja muulle ei-kriittiselle tavaralle uhraamalla hieman luotettavuutta. Kalliimmalla tekniikalla tehtävät levyt ja perinteiset pyörivät kiintolevyt sitten kriittiselle datalle ja varmuuskopioille.
 
Mä voisin ihan hyvin ottaa vaikka 6 bittiä soluun kirjoittavan levyn pelikirjastolleni, jos giga/€-suhde olisi nykyisiä parempi (hieman vajaa 10Gt per 1€) . Mä en tule sadassa vuodessakaan kirjoittamaan nykyistä QLC-levyäni puhki.

Ongelmia toki tulee siinä, kun esim läppärivalmistajat laittavat pelkän QLC-levyn koneeseen. Tai no ei kyllä peruskäyttäjällä sekään todenäköisesti kulu vielä puhki, mutta se alkaa olla jo käytännössä jossain tilanteessa mahdollista.

Valveutuneelle käyttäjälle tästä sen sijaan on vain etua. Saadaan edullisempaa ja äänetöntä tallennustilaa peleille, elokuville ja muulle ei-kriittiselle tavaralle uhraamalla hieman luotettavuutta. Kalliimmalla tekniikalla tehtävät levyt ja perinteiset pyörivät kiintolevyt sitten kriittiselle datalle ja varmuuskopioille.

Tai sitten on hiljainen NAS nurkassa ja siellä on 3TB (fiksusti kahdennettuna) leffoille. Riittää koko DVD-kirjastolleni. Jos joskus siirrän sinne Bluraytä, sitten tarvitsen enemmän.

Käytännössä myöskään SSD:llä ei säily tieto ikuisesti, tai niin hyvin kuin magneettisilla levyillä. Tästä keskustelimme, niin joku on nyt todistanut, että tiedon kirjoituslämpötila vaikuttaa tiedon säilyvyyteen ja sitä solua pitää välillä refreshata , että tieto pysyy siellä -> niin siitä tulee kirjoituskertoja pahimmassa tapauksessa monta kertaa levyn koko/vuosi ja levyn käyttöikä saadaan sinne valmistajille optimaaliseen pariin vuoteen. Minulla on kaapissa vielä SLC-levyjä ja yksi MLC, jotka on vuosikymmenen alusta.. Ne toiminee ok vieläkin.

Tietenkin linkitetty artikkeli puhui vaan kirjoituslämpötiloista yhdellä kalvolla, niin tuo refresh ei välttämättä vaadi solun uudelleenkirjoitusta, vaan voi riittää, että sähköt on päällä.
 
Pienempi tuotantoprosessi heikentää kestävyyttä siinä missä useamman bitin tallentaminen, joten ei sekään mikään oikotie onneen ole. Halvimmat QLC levyt kestää sen sata kertaa vuodessa koko levyn uudelleen kirjoittamisen takuun ajan, eikä SSD:t hajoa juurikaan pelkästä ajan vaikutuksesta. Kestävyys pitää mitoittaa levyä raskaiten käyttävän prosentin mukaan tai muuten takuuhuollot tulee kalliimmaksi kuin levyjen valmistuksessa säästetyt eurot.

NASsiin kelpaisi varastolevyksi hyvin joku OLC SSD, jonka solut eivät kestäisi kuin jonkun 20 kirjoituskertaa. ZFS pitää huolen, ettei data pääse korruptoitumaan, eikä rebuild levyn hajottua rasita muita levyjä, toisin kuin HDD:illä.
 
Kun QLC ei ollut tarpeeksi huono..

Joku voi vielä saada sen kuvan, että tämä on ainoa tapa saada lisää tilaa. Tilaa saa kahdella tavalla:
1) Laitetaan enemmän bittejä per solu, niinkuin nyt.. TLC -> QLC -> PLC on aina 2x tilaa lisää per nuoli, eli QLC -> PLC = 2x ja TLC -> PLC on 4x..
2) Tehdään parempi tuotantoprosessi, siinä vastaavat nuolet menisivät 14nm->10nm>7nm, eli 10nm->7nm = 2x ja 14nm->7nm->4x... Tämä tietenkin olettaen, että transistorimäärä menee prosessin mukaan oikein (eikä ole ns. markkinointiluku) ja se vaikuttaa suoraan tallennustilaan .

Järkevämpää on tehdä tavalla #2. Tapa #1 tuottaa helpommin halvempia levyjä, jotka hajoavat nopeammin. Yritykset tykkää, että on "halpa valmistaa" asema (paremmat katteet), joka hajoaa heti takuuajan jälkeen. Kuluttajien ei pitäisi.
Minulla on ollut muistikuva, että jossain myös väitettiin solujen kestävyyden heikkenevän kun prosessi menee pienemmäksi. Onko näin?
 
Minulla on ollut muistikuva, että jossain myös väitettiin solujen kestävyyden heikkenevän kun prosessi menee pienemmäksi. Onko näin?

Kyllä, niinkuin @Loisteho jo sanoi.. Ei ole oikotietä onneen..

Kuitenkin tarpeeksi monta bittiä/solu, niin puhutaan niistä kymmenistä kirjoituskerroista, kun nykyään ne on sadoissa..
 
Mä voisin ihan hyvin ottaa vaikka 6 bittiä soluun kirjoittavan levyn pelikirjastolleni, jos giga/€-suhde olisi nykyisiä parempi (hieman vajaa 10Gt per 1€) . Mä en tule sadassa vuodessakaan kirjoittamaan nykyistä QLC-levyäni puhki.
Isoin ongelma ei ole kirjoituskesto vaan datan säilyminen.
Johon Samsungin planaari-TLC 840 EVOkin törmäsi.
QLC:lläkin on jo vähäiset toleranssit varauksen vuotamiseen ja häiriöihin viereisistä soluista ja PLC puolittaa ne edelleen.

Samoin kirjoitusnopeus varmaan lähestyy ensimmäisiä kiintolevyjä, kun QLC:n kirjoitusnopeuskin ottaa turpaan nykyisiltä mekaanisilta levyiltä.

Eli keikutaan entistä pitemmällä kuilun reunalla (kun ei homma räjähtänyt silmille viimeksikään) ja käytetään entistä enemmän purkkaa ja Jeesusteippiä tekniikan kusisemmaksi muuttumisen peittämiseen.
Kun ei hintakaan todellakaan laske mainostetusti.


Minulla on ollut muistikuva, että jossain myös väitettiin solujen kestävyyden heikkenevän kun prosessi menee pienemmäksi. Onko näin?
Pienemmät transistorit >
Ohuemmat ja heikommat eristeet > Hankalampi estää varauksen vuotaminen ja myös kuluvat enemmän kirjoituksen rasituksista.
+
Transistorin pienetessä siihen mahtuvan varauksen määrä pienenee, jolloin toleranssit pienenevät.
 
Kun QLC ei ollut tarpeeksi huono..

Joku voi vielä saada sen kuvan, että tämä on ainoa tapa saada lisää tilaa. Tilaa saa kahdella tavalla:
1) Laitetaan enemmän bittejä per solu, niinkuin nyt.. TLC -> QLC -> PLC on aina 2x tilaa lisää per nuoli, eli QLC -> PLC = 2x ja TLC -> PLC on 4x..
2) Tehdään parempi tuotantoprosessi, siinä vastaavat nuolet menisivät 14nm->10nm>7nm, eli 10nm->7nm = 2x ja 14nm->7nm->4x... Tämä tietenkin olettaen, että transistorimäärä menee prosessin mukaan oikein (eikä ole ns. markkinointiluku) ja se vaikuttaa suoraan tallennustilaan .

Järkevämpää on tehdä tavalla #2. Tapa #1 tuottaa helpommin halvempia levyjä, jotka hajoavat nopeammin. Yritykset tykkää, että on "halpa valmistaa" asema (paremmat katteet), joka hajoaa heti takuuajan jälkeen. Kuluttajien ei pitäisi.
Onhan tuossa kolmaskin tapa, eli kasataan kolmannessa ulottuvuudessa kerroksia, mikä on ollut merkittävä syy muistien halpenemiseen viimeisten viiden vuoden aikana.

Vielä pilkun viilaamisena MLC tuplaa bitit SLC:stä, TLC lisää kolmannen bitin, QLC neljännen ja nyt PLC viidennen, eli tilavuus kasvaa noissa ensin 100 % MLC:llä SLC:stä, sitten 50 % TLC:llä MLC:stä, seuraavaksi 33.3 % QLC:llä TLC:stä ja lopulta PLC:llä 25 % QLC:stä.
 
Onhan tuossa kolmaskin tapa, eli kasataan kolmannessa ulottuvuudessa kerroksia, mikä on ollut merkittävä syy muistien halpenemiseen viimeisten viiden vuoden aikana.

Vielä pilkun viilaamisena MLC tuplaa bitit SLC:stä, TLC lisää kolmannen bitin, QLC neljännen ja nyt PLC viidennen, eli tilavuus kasvaa noissa ensin 100 % MLC:llä SLC:stä, sitten 50 % TLC:llä MLC:stä, seuraavaksi 33.3 % QLC:llä TLC:stä ja lopulta PLC:llä 25 % QLC:stä.

1 bitti, yksi varaustaso, kaksi arvoa (päällä, pois)
2 bittiä, kaksi varaustasoa, neljä arvoa 00, 00, 10, 11
3 bittiä, kolme varaustasoa, kahdeksan arvoa 000,001,010,011,100,101,110,111
4 bittiä, neljä varaustasoa, kuusitoista arvoa (jätetään harjoitukseksi lukijalle)
5 bittiä, viisi varaustasoa, 32 arvoa, tästä on kuva ylhäällä

..eli ei kasva lineaarisesti, kasvaa eksponentiaalisesti..

edit: tämä vastaus minulta on virheellinen.
 
Viimeksi muokattu:
1 bitti, yksi varaustaso, kaksi arvoa (päällä, pois)
2 bittiä, kaksi varaustasoa, neljä arvoa 00, 00, 10, 11
3 bittiä, kolme varaustasoa, kahdeksan arvoa 000,001,010,011,100,101,110,111
4 bittiä, neljä varaustasoa, kuusitoista arvoa (jätetään harjoitukseksi lukijalle)
5 bittiä, viisi varaustasoa, 32 arvoa, tästä on kuva ylhäällä

..eli ei kasva lineaarisesti, kasvaa eksponentiaalisesti..
Arvojen määrä kasvaa eksponentaalisesti, mutta tallennustila lineaarisesti. 1 000 001 bitin levylle ei mahdu tuplasti dataa verrattuna 1 000 000 bitin levyyn, vaikka siihen mahtuukin tuplasti enemmän arvoja.
 
Ei jessus. Sitten kun vielä tuollainen PLC NAND paritetaan cachettoman 5 pennin/sentin ohjaimen kanssa, joka vetää koko käyttiksen I/O:n lukkoon kirjoituksen ajaksi niin kyllä on käyttökokemus kohdallaan kun se "SLC-like" bufferi lopahtaa.

Läppäristä löytyy vastaavanlaisella ohjaimella oleva Intelin kötöspaska QLC. Isompi kirjoituspurske kun tulee devatessa koneella olevaan testitietokantaan niin tekisi mieli heittää koko kone 6.kerroksen ikkunasta asfalttiin ja käydä vielä hakemassa parkista auto ja ajaa yli. :rage:

Ei jatkoon, ei tule mulle omiin koneisiin vaikka 1 eurolla saisi. :)
 
Arvojen määrä kasvaa eksponentaalisesti, mutta tallennustila lineaarisesti. 1 000 001 bitin levylle ei mahdu tuplasti dataa verrattuna 1 000 000 bitin levyyn, vaikka siihen mahtuukin tuplasti enemmän arvoja.
Se 1 000 000 bitin SLC levy olisi PLC:nä 5 000 000 bittiä.
 
Se 1 000 000 bitin SLC levy olisi PLC:nä 5 000 000 bittiä.
Jep, 5x enemmän, 5(PLC)/1(SLC)=5. PLC levyllä kuitenkin saadaan vain 25% enemmän tilaa kuin QLC levyillä (5/4=1.25), bittisyyden lisääminen yhdellä ei siis tuplaa tilaa kuin ainoastaan SLC->MLC tapauksessa.
 
edit: Olin väärässä taas! Nyt kävi näin.
 
Viimeksi muokattu:
Otetaan esimerkiksi satunnainen 12 bitin luku joka halutaan tallentaa: 1001 1100 0101
SLC levyillä se näyttäisi tältä: 1|0|0|1|1|1|0|0|0|1|0, 12 solua käytetty
MLC: 10|01|11|00|01|10, 6 solua käytetty
TLC: 101|110|001|110, 4 solua
QLC: 1001|1100|0101, 3 solua.

Haluan nähdä miten samainen 12 bitin jono saadaan mahtumaan TLC levyllä kolmeen (puolta vähempään kuin MLC:llä) kolme bittiä tallentavaan soluun.
 
Otetaan esimerkiksi satunnainen 12 bitin luku joka halutaan tallentaa: 1001 1100 0101
SLC levyillä se näyttäisi tältä: 1|0|0|1|1|1|0|0|0|1|0, 12 solua käytetty
MLC: 10|01|11|00|01|10, 6 solua käytetty
TLC: 101|110|001|110, 4 solua
QLC: 1001|1100|0101, 3 solua.

Haluan nähdä miten samainen 12 bitin jono saadaan mahtumaan TLC levyllä kolmeen (puolta vähempään kuin MLC:llä) kolme bittiä tallentavaan soluun.

No näinhän se menee.. Aivopieru minulla, kun vastailen tänne toisella kädellä töistä :facepalm:

En osaa multitaskata. Onneksi työt tuli tehtyä.

--

Pyrin tulevaisuudessa rajoittamaan väittelyni 2-3 viestiin, ennenkuin tarkistan asian. Nyt mentiin vahvalla mutulla, ennenkuin edes miettiin asiaa. Tuo esimerkki selittää tyhmemmällekin, että noin se on.
 
Otetaan esimerkiksi satunnainen 12 bitin luku joka halutaan tallentaa: 1001 1100 0101
SLC levyillä se näyttäisi tältä: 1|0|0|1|1|1|0|0|0|1|0, 12 solua käytetty
MLC: 10|01|11|00|01|10, 6 solua käytetty
TLC: 101|110|001|110, 4 solua
QLC: 1001|1100|0101, 3 solua.

Haluan nähdä miten samainen 12 bitin jono saadaan mahtumaan TLC levyllä kolmeen (puolta vähempään kuin MLC:llä) kolme bittiä tallentavaan soluun.
Samoin jos tietylle kapasiteetille x tarvittava piiala on SLC:ssä vaikka 1, niin MLC:llä se on siitä 50%
TLC:llä ~33,3%.
QLC:llä 25%
PLC:llä 20%.

Eli sitä piipinta-alaakaan ei edes enää säästy paljoa.
Ainoa mikä kasvaa eksponentiaalisti on tekniikan surkeus ja ongelmat.


Läppäristä löytyy vastaavanlaisella ohjaimella oleva Intelin kötöspaska QLC. Isompi kirjoituspurske kun tulee devatessa koneella olevaan testitietokantaan niin tekisi mieli heittää koko kone 6.kerroksen ikkunasta asfalttiin ja käydä vielä hakemassa parkista auto ja ajaa yli. :rage:
Suosittelen ennemmin maarakennustyömään etsimistä ja kysymistä voitko nakata sen telakaivurin telan eteen.
Sillä on hyvä pakata tyhjät säilyketölkitkin.
Sopivasti lomittain asetettuna ne saa "ulos" yhteen prässättynä levynä. ;)
 
Samoin jos tietylle kapasiteetille x tarvittava piiala on SLC:ssä vaikka 1, niin MLC:llä se on siitä 50%
TLC:llä ~33,3%.
QLC:llä 25%
PLC:llä 20%.

Eli sitä piipinta-alaakaan ei edes enää säästy paljoa.
Ainoa mikä kasvaa exponentiaalisti on tekniikan surkeus ja ongelmat.

Nimen omaan. Sitten vielä valmistajien pitää parittaa noita suorituskyvyltään heikkoja flash piirejä DRAM cachettoman ohjaimen kanssa, joka blokkaa kaiken IO:n jos kirjoitus on kesken.. eli edes luku ei onnistu.

Löytyy kotoa perheen koneista SATA ja NVME mallisia ohjaimia ja niistäkin molempaa tyyppiä:
- DRAM cache + SLC-like bufferi
- vain SLC-like bufferi

Pääsääntöisesti nuo cachettomat ei pysty toimimaan ns fullduplexina molempiin suuntiin kun kirjoitus sakkaa.. siinä sitten ihmettelet kun 10-30s mikään softa joka lukee sitä kyseistä levyä ei oikein toimi. :)

Ja nämähän on vielä user experience asioita.. entäs sitten kun joku kakkos/kolmos kone on pitempään virratta ja tuolta PLC paskasta katoaa/korruptoituu dadat.. siinä alkaa 10-40€ säästö vituttaa kummasti. :facepalm:
 
Samalla kärsii kuitenkin solujen kestävyys ja luotettavuus.
Voi helvetti nyt tätä pirkka-ssd -trendiä. Premium-levyjen hinnatkin lähtee varmaan nousuun jos meno jatkuu. En kyllä tiedä mitään ikävämpää teknovempaimien osalta kuin tallennusasemien leviäminen. Luulis etten oo ihan ainoa ja että olis enemmänkin markkinoita laatutavaralle.
 
  • Tykkää
Reactions: prc
Onko tosta noiden hajoamisesta oikeasti mitään faktaa?.Pitääkös tulevaisuudessa alkaa oikeasti pistämään ylös että milloin ssd on ostettu että muistaa ostaa uuden ennen kuin sen takuu loppuu?.
 
Onko tosta noiden hajoamisesta oikeasti mitään faktaa?.Pitääkös tulevaisuudessa alkaa oikeasti pistämään ylös että milloin ssd on ostettu että muistaa ostaa uuden ennen kuin sen takuu loppuu?.
Samsungin 840 oli ensimmäinen TLC-lätty markkinoilla ja aikoinaan niiden lukunopeudet alkoivat laskea, koska niissä yhden muistisolun 3 bittiä säilötään 8 jännitetasona ja varaukset heikkenivät liikaa usemman kuukauden kuluessa, jotta dataa luettaessa piti ilmeisesti ajaa läpi etenevissä määrin virheenkorjauksia.

Tuo vika korjattiin silloin uudella firmwarella, joka uudelleenkirjoittaa levyn datan jonkun kuukauden välein pitäen jännitasot kelvollisina.

Tässä on siis kyseessä perustavanlaatuinen muistitekniikan heikkous, mutta 3D-muisteihin siirtyminen on vähentänyt jännitehäviöitä ja nykyohjainten pitäisi osata uudelleenkirjoittaa datat itsestään.

Toinen ongelma on sitten kirjoituskestävyys, mutta kyllä jonkun QLC-lätynkin pitäisi pystyä uudelleenkirjoittamaan itsensä usemman kerran vuodessa vuosikymmenten ajan, eli käytännössä QLC-aseman pitäisi kelvata varastokäyttöön hyvin, mutta virratta sitä ei kannata muutamaa kuukautta pidemmäksi jättää.
 
Tosin nämä ei käytä NAND flash -muisteja, onko 3D Xpointit SLC-tyyppistä muistia?

Yksi "datasolu" voi säilöä yhden tavun eikun tietenkin bitin verran dataa. Data säilötään tai luetaan sen perusteella paljonko jännitettä "datasoluun" laitetaan.

Ehkä tuota tavallaan voi sanoa SLC:ksi koska datan säilyttämisen suhteen jännitetasoja on vain yksi.
 
Yksi "datasolu" voi säilöä yhden tavun eikun tietenkin bitin verran dataa. Data säilötään tai luetaan sen perusteella paljonko jännitettä "datasoluun" laitetaan.

SLC:nä pitäisin. Mainittakoon vielä, että tässä artikkelissa (PLC:llä) se on viisi bittiä, jolloin solun jännitetasoja on 2^5 = 32 kpl. Ken tietää, vaikka tavun kokoisia soluja SSD-levyjen massatuontoon joskus sikiääkin. Joka tapauksessa levylle pienin tallennettava/luettava tietomäärä on yksittäinen blokki, joka sisältää x-määrän pageja. Sivussa on sitten sektoreita x-kpl ja nämä taas koostuvat tavuista ja lopulta solujen jännitetasoista, joita kontrolleri käsittelee sitten suunnittelijoiden kovokoodaamien algoritmien ja logiikoiden mukaisesti.

Näyttää vähän siltä, että tämä vuosituhat kaipaa kovasti analogisia kasettinauhureita takaisin, hinnalla millä hyvänsä.

Periaatteessa vähän huollestuttaa yli 3-bit MLC-asemien kesto, jos ne eivät ole säännöllisessä käytössä. Vaikka levyä ei ehkä saakaan normikäytöllä ns. puhki, niin levyn kuluminen (solujen wearing level) vaikuttaa myös datan retentioon epäedullisesti ja tämä korostuu silloin, kun aseman aktiivikäytöstä luovutaan ja se pyhitetään arkistointikäyttöön (koneesta kokonaan pois). Tähän jos viellä yhdistää sen, että taltiointi ja säilytys virratta tehdään hyvin epäedullisissa olosuhteissa, niin data saattaa korruptoitua yllättävänkin nopeasti. Tämä siis teoriassa ja aika monen jossittelun ja pahimman skenaarion kautta.

Muistaakseni JEDEC:llä oli myös wearingiin pohjautuva taulukko olemassa, mutta en löydä sitä tähän hätään. Luvut ovat ilman sitäkin yllättävän lyhyitä ja kai nämä ovat jotain worst case -skenaarioita? Vaikka foliohattua en päähän vedä, pidän silti foliorullaa keittiössä ja teen varmuuskopiot mielummin HDD:lle, jos on epävarmaa, että meneekö ko. aseman varmuuskopioiden päivitys vuoden vai kolmen päähän. Toki HDD on tällaiseen käyttöön muutenkin omiaan.
JEDEC SSD endurance.PNG JEDEC Temperatures and data retention.PNG
 
Muistaakseni JEDEC:llä oli myös wearingiin pohjautuva taulukko olemassa, mutta en löydä sitä tähän hätään. Luvut ovat ilman sitäkin yllättävän lyhyitä ja kai nämä ovat jotain worst case -skenaarioita? Vaikka foliohattua en päähän vedä, pidän silti foliorullaa keittiössä ja teen varmuuskopiot mielummin HDD:lle, jos on epävarmaa, että meneekö ko. aseman varmuuskopioiden päivitys vuoden vai kolmen päähän. Toki HDD on tällaiseen käyttöön muutenkin omiaan.
JEDEC SSD endurance.PNG JEDEC Temperatures and data retention.PNG
Nuo ovat vaatimukset datan säilymiselle TBW-arvon tullessa vastaan, eli data saa lähteä noin nopeasti, kun lätylle on ensin kirjoitettu mallista riippuen joitain kymmeniä tai satoja teroja.

The Truth About SSD Data Retention

Koitin etsiä löytyisikö uudelle levylle vastaavia lukuja, mutta "monta vuotta" oli paras löytämäni arvio.

Addressing Data Retention in SSDs
 
Joo ei kyllä ole nämä kökköasemat löytämässä itseään omasta koneesta. Itselleni raja tulee vastaan tämän QLC kanssa, jota en kuitenkaan uskaltaisi laittaa läppäriini joka on joskus montakin kuukautta virroitta. Ehkä nämä sopii esim puhelimiin yms niille jotka vaihtelevat laitteita vuoden välein ja muistin kestävyydellä ei ole väliä.
 
Kyllähän näitä pelikäyttöön ostelee. Vähän kirjoitusta ja kaikki data on sellaista joka ladataan Steamista / Xbox Livestä takaisin jos joskus leviää.
 
Kyllähän näitä pelikäyttöön ostelee. Vähän kirjoitusta ja kaikki data on sellaista joka ladataan Steamista / Xbox Livestä takaisin jos joskus leviää.

Kunhan ei sitten ahista korvien välistä jos/kun tulee isompi kasa pätsejä peleihin tai joutuu lataamana syystä X kaiken uusiksi. Steami nyt onneksi kohtuu järkevästi pätsää pelin teidostoja, mutta Wolrd of *, Warthunder ja MechWarrior online ovat toisesta ääripäästä ja aiheuttavat melkoista kirjoituskuormaa vaikka ladattavan pätsin koko olisi vain 1-2GB.

Nuo kaikki on on tovin päivittämättä ja antaa kerralla alkaa päivittämään niin Sampan QVO hyytyy siihen ~80Mb/s.. PLC asemilla siis mennään jonnekkin vielä tuosta alaspäin... nähtäväksi jää paljonko.

Liekköhän tulevat olemaan niin halpoja, että kannattaa tuota tradeoffia tehdä.

No sitten sen näkee kun testejä tulee, mutta kyllä haisee bittitasojen lisääminen huonolta kompromissilta, tilan lisäys on diminishing returns peliä ja samalla tekniset ongelmat kasvaa.. :F
 
Onhan tuossa kolmaskin tapa, eli kasataan kolmannessa ulottuvuudessa kerroksia, mikä on ollut merkittävä syy muistien halpenemiseen viimeisten viiden vuoden aikana.

Vielä pilkun viilaamisena MLC tuplaa bitit SLC:stä, TLC lisää kolmannen bitin, QLC neljännen ja nyt PLC viidennen, eli tilavuus kasvaa noissa ensin 100 % MLC:llä SLC:stä, sitten 50 % TLC:llä MLC:stä, seuraavaksi 33.3 % QLC:llä TLC:stä ja lopulta PLC:llä 25 % QLC:stä.

1 bitti, yksi varaustaso, kaksi arvoa (päällä, pois)
2 bittiä, kaksi varaustasoa, neljä arvoa 00, 00, 10, 11
3 bittiä, kolme varaustasoa, kahdeksan arvoa 000,001,010,011,100,101,110,111
4 bittiä, neljä varaustasoa, kuusitoista arvoa (jätetään harjoitukseksi lukijalle)
5 bittiä, viisi varaustasoa, 32 arvoa, tästä on kuva ylhäällä

..eli ei kasva lineaarisesti, kasvaa eksponentiaalisesti..

edit: tämä vastaus minulta on virheellinen.
Taitaa tuo varaustaso seurata arvojen määrää eikä bittien määrää. Artikkelissakin todetaan, että 5bitillä tarvitaan 32 varaustasoa.
 
riittääkös joku pikku patteri pitämään sen datan siellä levyllä?.Itse vähän pihalla että miten noi uudet piirit toimii.
 
SLC:nä pitäisin. Mainittakoon vielä, että tässä artikkelissa (PLC:llä) se on viisi bittiä, jolloin solun jännitetasoja on 2^5 = 32 kpl. Ken tietää, vaikka tavun kokoisia soluja SSD-levyjen massatuontoon joskus sikiääkin. Joka tapauksessa levylle pienin tallennettava/luettava tietomäärä on yksittäinen blokki, joka sisältää x-määrän pageja. Sivussa on sitten sektoreita x-kpl ja nämä taas koostuvat tavuista ja lopulta solujen jännitetasoista, joita kontrolleri käsittelee sitten suunnittelijoiden kovokoodaamien algoritmien ja logiikoiden mukaisesti.

Näyttää vähän siltä, että tämä vuosituhat kaipaa kovasti analogisia kasettinauhureita takaisin, hinnalla millä hyvänsä.

Periaatteessa vähän huollestuttaa yli 3-bit MLC-asemien kesto, jos ne eivät ole säännöllisessä käytössä. Vaikka levyä ei ehkä saakaan normikäytöllä ns. puhki, niin levyn kuluminen (solujen wearing level) vaikuttaa myös datan retentioon epäedullisesti ja tämä korostuu silloin, kun aseman aktiivikäytöstä luovutaan ja se pyhitetään arkistointikäyttöön (koneesta kokonaan pois). Tähän jos viellä yhdistää sen, että taltiointi ja säilytys virratta tehdään hyvin epäedullisissa olosuhteissa, niin data saattaa korruptoitua yllättävänkin nopeasti. Tämä siis teoriassa ja aika monen jossittelun ja pahimman skenaarion kautta.

Muistaakseni JEDEC:llä oli myös wearingiin pohjautuva taulukko olemassa, mutta en löydä sitä tähän hätään. Luvut ovat ilman sitäkin yllättävän lyhyitä ja kai nämä ovat jotain worst case -skenaarioita? Vaikka foliohattua en päähän vedä, pidän silti foliorullaa keittiössä ja teen varmuuskopiot mielummin HDD:lle, jos on epävarmaa, että meneekö ko. aseman varmuuskopioiden päivitys vuoden vai kolmen päähän. Toki HDD on tällaiseen käyttöön muutenkin omiaan.
Taitaa mennä vuosia että data katoaa noilta levyiltä eli ei toi nyt niin paha juttu ole.Noi ongelmat taitaa vielä koskea juuri halpisasemia jotka maksaa alle <50€ ja joita todennäköisesti käytetään se pari vuotta ja silloin ollaan voitu jo ostaa isompi ja uudempi levy ja noi menee kaappiin/roskiin.
 
riittääkös joku pikku patteri pitämään sen datan siellä levyllä?.Itse vähän pihalla että miten noi uudet piirit toimii.

Ei. Laite pitää saada käyntiin asti ja sen pitää olla käynnistä tarpeeksi kauan, jotta se voi tarvittaessa kopioida vanhaa dataa jonkun aikamäärän ylittyessä jotta siitä tulee "uutta dataa". Muuten alkaa ensin sama hidastuminen (jännitetasojen lasku) kun Samsung 840 EVO:lla ja jossain vaiheessa dataa ei enää pystytä lukemaan ulos.

Eli jonkun "arkistolevyn" terveenä pitämiseksi ei riitä että se on muutaman minutin USB ketolla kiinni koneessa, sen on oltava esim 0.5-2 vrk. (Riippuu kapasiteetist ja luku & kirjoitusnopeuksista jatkuvassa kirjoituksessa).

Omasta mielestä arkistot kannattavampaa pitää HDD:llä jonkun USB kotelon tai telakan avulla. Harvemmin kun nopeudet haittaa. Ärsyttävät pikkutiedostot voi lätkiä zip tjsp paketteihin, jolloin HDDn luku/kirjoitusnopeus ei sakkaa kun nakkaa paketin talteen tai kaivaa sen ulos.

-- EDIT --

Varoituksen sana USB kotelosita ja telakoista.

Valtaosin 2,5" USB telakat ei kunnioita käyttöjärjestelmän HDD sleep/spindown komentoja ollenkaan, tai antavat suoraan virhettä kun niitä lähetetään. Ja yleensä niiden ohjaimessa on joku oma kiinteä idletimer jota ei voi säätää. Eli et voi taata sen SSD:n pysyvän käynnissä muuten kuin pakottamalla jonkun ohjelman lukemaan sitä jatkuvasti. (Itsellä 2kpl magallyn koteloita, 5min idle ja se katkaisee virrat. HDPARM komentoihin ei reagoi mitään, eli itse ei voi pakottaa pysymään käynnisä tai sammuttaa).

Erään suomalaisen kaupan itse brändäämät kiinanpojan USB telakat taas pääsääntöisesti ei suostu spindownaamaan levyjä edes pakottamalla, eli levy/ssd on aina "päällä" kun virtakin on.
 
Viimeksi muokattu:
Kyllähän näitä pelikäyttöön ostelee. Vähän kirjoitusta ja kaikki data on sellaista joka ladataan Steamista / Xbox Livestä takaisin jos joskus leviää.

Kunhan ei sitten ahista korvien välistä jos/kun tulee isompi kasa pätsejä peleihin tai joutuu lataamana syystä X kaiken uusiksi. Steami nyt onneksi kohtuu järkevästi pätsää pelin teidostoja, mutta Wolrd of *, Warthunder ja MechWarrior online ovat toisesta ääripäästä ja aiheuttavat melkoista kirjoituskuormaa vaikka ladattavan pätsin koko olisi vain 1-2GB.

Nuo kaikki on on tovin päivittämättä ja antaa kerralla alkaa päivittämään niin Sampan QVO hyytyy siihen ~80Mb/s.. PLC asemilla siis mennään jonnekkin vielä tuosta alaspäin... nähtäväksi jää paljonko.

Liekköhän tulevat olemaan niin halpoja, että kannattaa tuota tradeoffia tehdä.

No sitten sen näkee kun testejä tulee, mutta kyllä haisee bittitasojen lisääminen huonolta kompromissilta, tilan lisäys on diminishing returns peliä ja samalla tekniset ongelmat kasvaa.. :F
Kyllä se siinä mielessä vaikuttaa että QLC ja nämä PLC asemat halpenevat tulevaisuudessa ja TLC ja MLC asemat kallistuvat. (Because of reasons)
Eli nämä vähentävät tarvetta alentaa parempien ssd asemien hintoja, kun näillä voidaan kattaa se hintakilpailtu segmentti.
 
Kyllä se siinä mielessä vaikuttaa että QLC ja nämä PLC asemat halpenevat tulevaisuudessa ja TLC ja MLC asemat kallistuvat. (Because of reasons)
Eli nämä vähentävät tarvetta alentaa parempien ssd asemien hintoja, kun näillä voidaan kattaa se hintakilpailtu segmentti.

Niinhän siinä käy. Itse tosin arvostan datojani ja aikaani sen verran että äänestän lompakolla ja ostan huonoimmillaan TLC asemia, ja käytitkselle / tärkeälle datalle SLC/MLC kamaa. Ei paljon lämmitä se 50-100€ säästö siinä vaiheessa kun kaivellaan backuppeja arkistoista.

Tosin oma käyttö taitaa poiketa hitusen "normaalista". Erilaista SSD tilaa on ~2TB, sitten arkistoa HDD:lla 16TB jonka lisäksi RAID1 HDD pintaa löytyy atm 4TB. Ja RAID1 pinnasta on luonnollisesti backuppi + offsite & offline backuppi. :)
 

Statistiikka

Viestiketjuista
261 732
Viestejä
4 545 408
Jäsenet
74 839
Uusin jäsen
kalalintu

Hinta.fi

Back
Ylös Bottom