SSD: thread generale e consigli per gli acquisti

[Pess]

Originariamente inviato da pulsar68

Mi annovero anche io fra coloro che hanno denigrato le NAND TLC... certo... leggendo il tuo post devo un po' rivedere la mia "avversione" verso tali soluzioni... di nuovo complimenti per le preziose informazioni che ci fornisci

@ Pess
Forse sarebbe utile inserirlo in prima pagina, se ne hai voglia e tempo

Si, si potrebbe fare... A questo punto chiedo ad s12a di riassumere quanto visto in un singolo post, mettendo in evidenza le conclusioni sulla durata delle celle e sull'efficienza degli algoritmi che prevengono la write amplification...
In questo modo lo linko direttamente in prima pagina...

[danieleg.dg]

Originariamente inviato da s12a

Se il sistema è installato da zero, l'allineamento è ok, non ci sono programmi strani preinstallati e la deframmentazione è verificata essere disabilitata (dal registro eventi si può vedere se il servizio Defrag (ID 258) richiama la deframmentazione oppure il "retrim", e quanto spesso questo succede), probabilmente è l'SSD, allora.

Io ho modificato il task di deframmentazione mettendo l'opzione -l

Se è un bug può essere o leggero, e quindi solo di visualizzazione dei dati SMART da parte dell'SSD (a prescindere dal programma usato) oppure più serio nel senso che per qualche motivo il wear leveling non funziona come dovrebbe.

Prova comunque con Samsung Magician. Rileva questo SSD? Dai dati SMART accessibili da lì mediante il pulsante apposito, il wear leveling count raw è sempre così elevato in rapporto alle scritture host? Quello normalizzato indica sempre l'usura già aumentata di qualche punto percentuale?

Ho provato ad installare magician, ma non rileva correttamente il disco. L'unica cosa che riesce a leggere sono i dati SMART e coincidono con quelli di crystaldiskinfo.

[s12a]

Originariamente inviato da Pess

Si, si potrebbe fare... A questo punto chiedo ad s12a di riassumere quanto visto in un singolo post, mettendo in evidenza le conclusioni sulla durata delle celle e sull'efficienza degli algoritmi che prevengono la write amplification...
In questo modo lo linko direttamente in prima pagina...

Originariamente inviato da Pess

Si, si potrebbe fare... A questo punto chiedo ad s12a di riassumere quanto visto in un singolo post, mettendo in evidenza le conclusioni sulla durata delle celle e sull'efficienza degli algoritmi che prevengono la write amplification...
In questo modo lo linko direttamente in prima pagina...

I post erano un po' a titolo generale sull'argomento SSD e memorie NAND in risposta/approfondimento a diverse domande, non ho molta idea di come organizzarli in un unico messaggio. Ho provato a pulirli un po', comunque. Eventuali correzioni sono ben accette [EDITATO in nuovo post]

Originariamente inviato da danieleg.dg

Io ho modificato il task di deframmentazione mettendo l'opzione -l

Sarebbe comunque consigliabile verificare quello che succede effettivamente nel registro eventi (Event Viewer).

Ho provato ad installare magician, ma non rileva correttamente il disco. L'unica cosa che riesce a leggere sono i dati SMART e coincidono con quelli di crystaldiskinfo.

I dati SMART allora sono quelli, non è un problema di CrystalDiskInfo. Rimane da stabilire se sono veritieri oppure no, ma così su due piedi la cosa è difficile.

[_asphalto_]

sono sempre al passo con le ultime pagine ma non ci sto capendo un gran che con questo problema del write amplification
quello che ho capito è che è una cosa di cui tenerne conto perché si potrebbe incorrere in una usura "precoce" dell'ssd
mi dite come sono messo io?


c'è avast che crea problemi qua?

[s12a]

Originariamente inviato da _asphalto_

sono sempre al passo con le ultime pagine ma non ci sto capendo un gran che con questo problema del write amplification
quello che ho capito è che è una cosa di cui tenerne conto perché si potrebbe incorrere in una usura "precoce" dell'ssd
mi dite come sono messo io?

Su alcuni Samsung 840 EVO, incluso il tuo, tempo addietro è stata riscontrata una stranezza opposta: il dato del wear leveling count è troppo basso rispetto a quello delle scritture host. Se la cosa fosse veritiera, vorrebbe dire che la write amplification è minore di 1, e che quindi il drive sarebbe più duraturo del normale.

Il valore grezzo del parametro B1 "livello uso", che indica il numero di cicli di program/erase effettuati in media su tutte le memorie NAND dell'SSD, nel tuo caso è pari a 4; considerando una capienza interna di 119 GiB (dei 128 GiB di memoria NAND fisicamente installati sul tuo drive, 9 GiB dovrebbero essere utilizzati per i 3 GiB di buffer pseudo-SLC del turbowrite, che non partecipano al wear leveling in maniera normale), ciò vorrebbe dire che sulle memorie NAND sono stati movimentati 4 * 119 = 476 GiB, a fronte di 711 GiB di scritture host. Ma dubito che il dato corrisponda al vero. Questo corrisponderebbe ad una write amplification di 476 GiB / 711 GiB = 0.67x. Valori inferiori ad 1 dovrebbero essere possibili solo su SSD che fanno uso di compressione, come quelli con controller Sandforce/LSI.

Comunque siano le cose, al momento non ci sono ragioni per preoccuparsi dell'usura nel tuo caso. Se i dati fossero affidabili, ci sarebbe piuttosto da gioire. Proverei a verificare nuovamente i dati SMART più avanti.


EDIT: nel caso ci fossero dubbi che il parametro B1 (dec: 177) "livello uso / wear leveling count" sui Samsung non corrisponda al numero di cicli di scrittura effettuati:

Pagina 25: http://www.samsung.com/global/busine...Whitepaper.pdf

[CronoX]

Originariamente inviato da s12a

Se il sistema è installato da zero, l'allineamento è ok, non ci sono programmi strani preinstallati e la deframmentazione è verificata essere disabilitata (dal registro eventi si può vedere se il servizio Defrag (ID 258) richiama la deframmentazione oppure il "retrim", e quanto spesso questo succede), probabilmente è l'SSD, allora.


Se è un bug può essere o leggero, e quindi solo di visualizzazione dei dati SMART da parte dell'SSD (a prescindere dal programma usato) oppure più serio nel senso che per qualche motivo il wear leveling non funziona come dovrebbe.

Prova comunque con Samsung Magician. Rileva questo SSD? Dai dati SMART accessibili da lì mediante il pulsante apposito, il wear leveling count raw è sempre così elevato in rapporto alle scritture host? Quello normalizzato indica sempre l'usura già aumentata di qualche punto percentuale?

Originariamente inviato da s12a

Sarebbe comunque consigliabile verificare quello che succede effettivamente nel registro eventi (Event Viewer).

I dati SMART allora sono quelli, non è un problema di CrystalDiskInfo. Rimane da stabilire se sono veritieri oppure no, ma così su due piedi la cosa è difficile.

sono task doppi (ne ho creati 2 per due partizioni diverse), di analisi e riottimizzazione...ce n'è uno intruso del 24 di deframmentazione (non capisco perchè)

intanto ho trovato questo:

"Make sure you turn off idle time optimizer in Norton! (general settings) its defragmentation process which runs automatically. "

e procedo quindi dato che:

Ottimizzazione tempi di inattività
Ottimizzazione tempi di inattività consente di configurare Norton Internet Security per la deframmentazione del volume di avvio o del disco locale che lo contiene, quando il computer è inattivo. Norton Internet Security pianifica automaticamente l'ottimizzazione quando rileva l'installazione di un'applicazione nel computer e quando quest'ultimo è inattivo. Se si ricomincia a utilizzare il computer, Norton Internet Security interrompe l'attività di ottimizzazione e la riavvia quando il computer risulta nuovamente inattivo. Così facendo, l'attività di ottimizzazione, eseguita in background, non ha ripercussioni sulle prestazioni del computer.

L'ottimizzazione riorganizza i frammenti dei file in cluster adiacenti o contigui nel disco rigido. Assicura un miglioramento delle prestazioni del computer poiché i file vengono letti nella memoria più velocemente. L'ottimizzazione consente anche di massimizzare lo spazio libero utilizzabile su un disco raggruppando i file usati più spesso e quelli usati con minor frequenza. Inoltre, accorpa lo spazio libero per evitare di frammentare i file appena aggiunti.

È possibile eseguire l'ottimizzazione manualmente utilizzando l'opzione Ottimizza nella finestra Prestazioni che viene visualizzata quando si fa clic su Prestazioni nella finestra principale. È anche possibile visualizzare le occorrenze dell'ottimizzazione nei tre mesi precedenti consultando il grafico degli eventi nella finestra Prestazioni.

[danieleg.dg]

Originariamente inviato da s12a

Sarebbe comunque consigliabile verificare quello che succede effettivamente nel registro eventi (Event Viewer).


I dati SMART allora sono quelli, non è un problema di CrystalDiskInfo. Rimane da stabilire se sono veritieri oppure no, ma così su due piedi la cosa è difficile.

Sì, ho verificato ed ho lo steso evento postato da CronoX. Per ora ho spostato la cache di Chrome e alcuni altri file su un ramdisk e vedo come si evolve la situazione nelle prossime settimane.

[Pess]

s12a, scrivi il solo quote del tuo post in uno nuovo... Ci devono essere le sole informazioni che hai scritto, in modo che non risulti dispersivo...

[giovanni69]

Originariamente inviato da mtofa

Di nulla, che fai pensi di prenderlo?

No. Non prenderò quell'adattatore SATA -->> PATA

Ho scoperto che il notebook in questione una volta aperto in realtà ha un HD SATA1 da 2.5" da 60 Gb.

Quindi se faccio l'upgrade - se ho ben capito - non dovrei aver alcun problema ad usare un SSD regolare oppure un mSATA con un 'msata to sata adapter', sperando di non aver problemi di spazio.

Tuttavia l'HD SATA attuale viene usato in modalità non nativa SATA quindi immagino IDE; se da BIOS metto la modalità nativa SATA, l'HD va in crash all'avvio poco dopo il boot. Forse dovrò quindi usare il nuovo SSD in modalità IDE...

Come performance su SATA 1 dovrebbe essere simile a questa su youtube:
... /watch?v=bSv0SgwKV-U

Quindi semmai il punto si sposta nel trovare un SSD che stia sui 50 EUR spedito da almeno 60 Gb e che sia affidabile

Mi par di capire che sia il Sandisk Ultra Plus 64 Gb?
Ma non trovo recensioni..

[s12a]

:

Originariamente inviato da s12a

Per l'usura del drive non contano tanto i GB/giorno di scritture host (ossia richieste dal sistema operativo/utente), piuttosto quanto effettivamente essi vanno a movimentare dati nelle sue celle di memoria. Questo dipende dalla write amplification, la quale varia a seconda del proprio utilizzo e tipo di dati con cui si ha a che fare. Per fare un esempio, 25 GB/gg con write amplification di 2x (25 * 2 = 50 GB) sono meno usuranti di 6 GB/gg con write amplification di 20x (6 * 20 = 120 GB).

Poi tocca fare considerazioni pratiche, in ogni caso. Se nonostante tutto pur considerando una write amplification elevata (ad esempio magari con usi "spot" del computer, ossia accenderlo brevemente solo al momento del bisogno - tendono ad aumentarla a prescindere dal tipo di dati movimentati) la prospettiva è comunque di 8-10 anni per arrivare al 100% di usura nominale, non è che ci sia da disperarsi.

Il problema può insorgere quando si hanno contemporaneamente sia write amplification elevata (mettiamo 15x), sia un numero di scritture host giornaliere relativamente elevato, almeno per usi home (esempio 25 GB/giorno. In assoluto sono pochi però). In questo esempio avremmo 25 x 15 = 375 GB al giorno di scritture movimentate effettivamente sulle memorie NAND, che usurerebbero un SSD da 256 GB e memorie MLC (2bit per cella, 3000 cicli P/E) in poco più di 5 anni.

* * *

La write amplification può aumentare in diversi modi. Uno meno noto è che effettuare scritture troppo piccole troppo spesso può in certi casi aumentarla considerevolmente. Negli SSD infatti si può scrivere solo a colpi di "pagine" che hanno una certa dimensione minima e non si possono sovrascrivere se non previa cancellazione. La cancellazione può a sua volta avvenire solo a macro blocchi di pagine. Il controller di gestione dell'SSD si occupa internamente di gestire questa complicazione, per quello che può, e si può immaginare quanto gravoso sia il suo compito, dato che deve evitare di usurare le memorie NAND il più possibile, con questi paletti.

I sistemi operativi moderni vengono fortunatamente parzialmente incontro a queste esigenze (in realtà soprattutto per questioni prestazionali) inglobando le scritture da effettuare in un certo buffer (una sorta di "serbatoio" di dati da scrivere), che viene "scaricato" nel drive ad intervalli regolari o quando si riempe (a meno che i programmi non effettuino bypass esplicito della cosa richiedendo uno "scaricamento" immediato - denominato inglese "flushing" - dei dati scritti).

In generale, più dati contemporaneamente vengono trasferiti per scrittura effettuata, meno spreco avviene nella programmazione delle memorie. Nel caso del popolare Samsung 840 Pro il suo controller può scrivere sulle memorie solo a gruppi di 8 kB per volta, e cancellare a gruppi di 1024 kB.

(implicazione diretta della cosa: se dobbiamo scrivere solo un dato da 400 byte e l'SSD non trova altri dati da agglomerare insieme - situazione difficile comunque con un uso normale del sistema operativo in cui ci sono sempre dati da scrivere il write buffer di sistema menzionato poc'anzi - la write amplification per quella scrittura sarà immediatamente di almeno 8192 byte / 400 byte = 20.5x).

Da me, in questo momento preciso il processo di Firefox (che è singolo, ma il più esoso in termini di scritture fra i processi in lista che ho) ha effettuato 7,895,625,000 byte in 804,718 scritture. Questo equivale a 9811 byte/scrittura in media, quindi dando per assunto che ci sia solo questo programma ad effettuare queste scritture, sarei sopra la dimensione minima dei blocchi di programmazione delle memorie NAND dell'SSD. Ma visto che 9811 byte in un blocco da 8 kB non entrano, richiedono due blocchi, quindi 16 kB, e perciò la write amplification per queste scritture (sempre assumendo un drive vuoto, ossia che non richiedano lo spostamento - quindi cancellazione - di altri dati per liberare blocchi in scrittura) sarebbe in media di 16384 / 9811 = 1.67x. Questo sempre ipotizzando che non ci siano altri dati da scrivere nello stesso periodo di tempo, cosa improbabile, ma non impossibile.

* * *

Analizzare i dati SMART del proprio drive, specie se fornisce indicazioni dirette sulle scritture effettuate sulle memorie NAND può aiutare a capire meglio come funzionano e sono gestiti gli ultimi SSD in generale. Ad esempio io sto scoprendo un po' di cose tecniche interessanti sul Sandisk Extreme II 480GB che ho recentemente preso come upgrade al mio precedente Samsung 840 250GB. Ho provato a monitorarlo per i primi giorni di attività. Osservare in particolar modo l'ultima colonna, rappresentante la write amplification calcolata dall'ultima rilevazione effettuata:


http://i57.tinypic.com/2exui5w.png

Finché il drive era nuovo, con tutte le celle vergini (e probabilmente anche per via dei trasferimenti tendenzialmente sequenziali e random a blocchi di 4kB o superiori), la write amplification è rimasta molto vicina ad 1.0x. Quando ho iniziato ad usarlo normalmente come al solito (browser, giochi, download ecc) e soprattutto, una volta che tutte le celle hanno ricevuto almeno una scrittura, sembra che la write amplification sia aumentata a circa 3.5x.

Il wear leveling su questo drive sembra a prima vista essere abbastanza meno efficiente di quello del Samsung 840 250 GB che usavo in precedenza, che si attestava a circa 1.5x in condizioni di normale utilizzo. Tecnicamente parlando, differenze firmware a parte nella gestione interna, probabilmente incide anche il fatto che sulle memorie NAND MLC 19nm Sandisk di questo drive l'erase block size è di ben 4 MB, mentre sulle Samsung TLC dell'840 è di 1.5 MB. In altre parole per effettuare il wear leveling il Sandisk sarà costretto a spostare più dati insieme. (La cosa sembra avere riscontri nella pratica.

Questo per dire che le memorie TLC (3 bit per cella) montate nei Samsung 840/840 EVO avranno sì una durata sulla carta tre volte inferiore alle normali MLC (2 bit per cella), ma se il wear leveling è almeno il doppio più efficiente a parità di utilizzo, nella pratica la differenza in tal senso è assai più sottile.

La tendenza dei produttori infatti, per diminuire i costi a parità di capienza è oltre quella di rimpicciolire il processo produttivo (ossia fisicamente la dimensione delle celle di memoria) od aumentare il numero di bit per cella, è anche quella di aumentare la dimensione delle pagine di programmazione (in inglese: program page size) ed quella dei blocchi di cancellazione (in inglese: erase block size). Fino a qualche anno fa la maggior parte degli SSD aveva un program page size di 4 kB, mentre un erase block size da 256 kB-1MB. La cosa era controbilanciata dal wear leveling in genere meno efficiente.

Oggi la maggior parte delle memorie degli SSD con processo produttivo a 1x-2x nm ha un page size di 8 kB, incluso il Sandisk Extreme II che ho preso recentemente. L'erase block size è più variabile, ma oramai si va sui 2MB in media. Da notare che più aumenta la dimensione dei blocchi di programmazione e cancellazione, più aumentano anche i tempi fisici per effettuare tali operazioni, cosa che comunque nuove tecniche e miglioramenti in altri aspetti cercano di contenere.

Curiosità: stando ai dati che sono riuscito a reperire in giro, il Crucial M500 ha memorie MLC da pagine da 16 kB ed erase block da ben 8 MB. E' probabilmente anche per questo che costa meno della media nonostante le MLC. Il wear leveling deve essere ben studiato perché altrimenti la write amplification controbilancerebbe la maggiore durata intrinsica rispetto alle memorie TLC (e magari ad un certo punto uscirà fuori che alla fin fine non ci sono vantaggi effettivi rispetto alle TLC Samsung in termini di durata in terabyte scritti).

[Pess]

Prima pagina aggiornata... Ho inserito le info nel primissimo post...

[s12a]

Originariamente inviato da giovanni69

Tuttavia l'HD SATA attuale viene usato in modalità non nativa SATA quindi immagino IDE; se da BIOS metto la modalità nativa SATA, l'HD va in crash all'avvio poco dopo il boot. Forse dovrò quindi usare il nuovo SSD in modalità IDE...

Credo che la modalità "SATA nativa" sia una definizione alternativa per dire "AHCI". Occorrerebbe procedere con la modifica apposita del registro di sistema di Windows per permettergli di fare boot, al momento sicuramente impostato per la modalità IDE. Non ci metterei la mano sul fuoco però.

Originariamente inviato da giovanni69

Mi par di capire che sia il Sandisk Ultra Plus 64 Gb? Ma non trovo recensioni..

L'SSD è valido. Una recensione dove è stato testato anche il modello da 64GB:

http://www.tomshardware.com/reviews/...nand,3502.html

[aled1974]

grazie a Pess per la cura del thread ed a s12a per tutta la mole di informazioni precise e tecniche che ci fornisce

ciao ciao

[Pess]

Originariamente inviato da aled1974

grazie a Pess per la cura del thread ed a s12a per tutta la mole di informazioni precise e tecniche che ci fornisce

ciao ciao

[Tennic]

Pess, per tentare di snellire le risposte (sempre le stesse risposte alle stesse domande, ogni singola pagina), proporrei di mettere alcuni concetti inerenti la velocità in prima pagina.

In particolare, come ben sappiamo, ogni giorno c'è qualche utente che posta i suoi risultati chiedendo se sono normali... Come se ci fosse una "normalità", dato che se io faccio 10 test mi vengono fuori 10 numeri diversi, con una devianza di anche 15-20 MB in più o in meno... Figuriamoci comparare SSD diversi, su schede madri diverse (e relativi controller), cavi diversi, CPU diverse, e RAM diverse... Ma evidentemente, tali concetti, seppur semplici, a volte non sono così immediati

Propongo quindi di mettere in prima pagina un piccolo trafiletto dove:

SATA 1: in caso di utilizzo di questa connessione, valori normali sono max xyz MB/s
Idem SATA 2 e 3...

Quindi, se uno con SATA 2 posta i suoi numerelli, e chiede come mai con un fiammante 840 Pro da 512 GB non supera i 270 MB/s mentre ci si aspettavano 500 MB/s, lo si manda a leggere la prima pagina, anzichè ogni volta spiegare la trafila dei concetti del collo di bottiglia del SATA 2, etc etc etc

Inoltre, è possibile anche mettere valori stimati per modello, i più diffusi ovviamente:

840 Pro: normali 500-550 Mb/s in lettura e 480-520 in scrittura... Ovviamente con SATA 3... Se si usa SATA 2, leggere poco sopra, dove si parla di interfacce SATA

Idem per EVO, Crucial M500, e basta... Giusto i più famosi...

Credo che così si evita di inserire sempre gli stessi post in ogni pagina, dove si spiega perchè un 840 non raggiunge i 500 MB al secondo con SATA 2

Che ne dite?

[s12a]

Per curiosità, ho provato a far partire il benchmark AS-SSD dentro Windows 8.1 virtualizzato con VMWare (Host: Windows 8.1 64bit) con il mio Sandisk Extreme II 480 GB:



Le prestazioni effettive sono quasi paragonabili a quelle native. L'occupazione CPU però è molto elevata nelle operazioni random con alto queue depth.

[Kicco_lsd]

S12a: Ma quindi il "problema" del Sandisk sono le memorie che hanno un erase block grosso oppure è il controller che determina questa dimensione? Per capirci il Samsung840Pro ha così poca Write Amplification grazie alle memorie o grazie al controller?
Certo che in un certo senso ho fatto bene ad aspettare per l'SSD da 480\512Gb

[giovanni69]

Originariamente inviato da s12a

Credo che la modalità "SATA nativa" sia una definizione alternativa per dire "AHCI". Occorrerebbe procedere con la modifica apposita del registro di sistema di Windows per permettergli di fare boot, al momento sicuramente impostato per la modalità IDE. Non ci metterei la mano sul fuoco però.


L'SSD è valido. Una recensione dove è stato testato anche il modello da 64GB:

http://www.tomshardware.com/reviews/...nand,3502.html

s12a, grazie molte per i suggerimenti!

In effetti quei benchmark PCMark 7 & Vantage promettono di far resuscitare il notebook.

Circa la possibilità che la modalità nativa SATA forse = AHCI , proverò con quell'impostazione da BIOS quando effettuerò l'installazione di Windows 7 Pro. Non mi va di rischiare su un Win XP che è prossimo ad essere formattato.

[s12a]

Originariamente inviato da Kicco_lsd

S12a: Ma quindi il "problema" del Sandisk sono le memorie che hanno un erase block grosso oppure è il controller che determina questa dimensione? Per capirci il Samsung840Pro ha così poca Write Amplification grazie alle memorie o grazie al controller?
Certo che in un certo senso ho fatto bene ad aspettare per l'SSD da 480\512Gb

La dimensione dell'erase block delle memorie NAND è determinata fisicamente, non logicamente. E' quindi una scelta di progetto di fabbrica. Sta agli algoritmi di wear leveling/produttori del firmware del controller dell'SSD adeguarsi alla situazione.

Comunque la questione nel mio caso potrebbe non essere finita qui: fra ieri ed oggi dopo aver effettuato un centinaio di GB di scritture (in particolar modo oggi per installare un paio di virtual machine), ho notato che la write amplification per gli ultimi dati scritti è calata notevolmente. Sarà perché era necessario un periodo di adattamento? (magari perché il TRIM - a sistema appena clonato - non aveva agito subito?) Oppure sarà perché ho scritto molti dati insieme (ma questo al limite ridurrebbe le inefficienze del page size di 8kB, non dell'erase block da 4MB) - questa cosa l'ho notata anche sul Samsung 840 - ? Continuerò a monitorare, la cosa è curiosa.



Questo comunque fermo restando che aumentare la dimensione dei blocchi fisici strutturali delle memorie NAND, costi a parte porta principalmente svantaggi per l'utente finale.

[Kicco_lsd]

Originariamente inviato da s12a

Questo comunque fermo restando che aumentare la dimensione dei blocchi fisici strutturali delle memorie NAND, costi a parte porta principalmente svantaggi per l'utente finale.

Grazie per l'ottima reply, detto ciò mi pare evidente che da oggi in poi abbiamo un nuovo parametro su cui basare le nostre scelte. E' una materia complessa questa degli SSD.