SSD: thread generale e consigli per gli acquisti

[giovanni69]

Originariamente inviato da @Liupen

ma alla fine saranno poche celle usurate che determineranno il primo settore riallocato e di conseguenza la dismissione dell'SSD per inaffidabilità

Non sono sicuro che il tuo sia il ragionamento corretto: da un lato hai quei Used Reserved Block Count che sono ancora a 0 e dunque tutti disponibile per sopperire una cella usurata. Dall'altro hai ancora un health del 95% per cui quel wearing level count non sta per niente mettendo in crisi l'aspettativa di vita del tuo Samsung.

Qui ho un altro modello di Samsung, 51 TB scritti in 4 anni, pieno in media all 90% almeno, con un wearing leveling count di 297 con un threshold di 5 ed un Valore / Valori peggiori di entrambi di 98. Anch'esso ha 0 Used Reserved Block count. Ed ha 10496 Unused Reserved Block Count. Health è a 98%.

Nel tuo SSD non c'è quel parametro 180 di 'Unused', d'accordo, ma in ogni caso non sta usando alcun 'Used' .

E tutto questo non ha a che fare con gli eventi 'Reallocated Sector Count'.

[@Liupen]

Grazie Giovanni,
ho letto del tuo Samsung, non conoscendo quel modello di SSD sono andato a guardare le specifiche non sapendo che lo tieni pieno a ca il 90% (un 480GB vero?) è un buon esempio, anche se hai più celle a disposizione, l'usura delle celle è regolare, penso che per il tipo di celle e vocazione PRO dell'SSD sia impostato per essere massimamente affidabile e conservativo. Forse un caso particolare?
Il mio Samsung 850 evo 250GB è consumer, ma magari è lui ad essere un caso particolare
Diciamo Gio che non ho paura che l'SSD mi pianti in asso ora, anzi sono sicuro che lo farà non per blocchi riallocati quanto perchè un bel giorno qualche componente sul pcb non me lo farà più riconoscere dal bios/uefi, trovo strano che non avvenga un livellamento più... come dire "aggressivo"
Ho osservato in poco tempo il wear leveling salire di molto a SSD pieno (veramente pochi GB a disposizione). So che quì ne avete parlato tante volte.
Ho fatto delle ipotesi (chiedo scusa se mi dilungo troppo):

• il Wear Leveling non funziona (quindi è marketing)
• Il Wear Leveling agisce solo sui dati non statici (quindi è limitato)
• Il Wear Leveling funziona (ma l'algoritmo è impostato per preferire il mantenimento delle prestazioni dell'SSD)

C'è anche un altra opzione che si può considerare, ed è diametralmente opposta al ragionamento fino a quì fatto.

Sopra infatti ipotizzo che la causa dell'innalzamento tasso di usura (medio o massimo non è dato sapere) delle celle sia dovuto all'algoritmo di Wear Leveling (o meglio al suo non funzionamento), ma se invece centrasse la Write Amplification?

In un meccanismo che riesco solo a pensare a grandi linee:
potrebbe succedere che la condizione di poco spazio libero per la scrittura, determini un grande spostamento (riscrittura dei blocchi) di cui non percepisco l'esistenza (non vedo un rallentamento delle prestazioni ad occhio e il bench, essendo basato su pochi MB di scrittura, non mi fornisce certezze). Le riscritture che aumentano - dovute al Garbage Collection in una situazione di SSD pieno - aprono alla prospettiva di un SSD con un gran lavoro del controller, il mantenimento delle prestazioni, ed una totale impotenza da parte dell'algoritmo di Wear Leveling.
In questa prospettiva si avrebbe un consumo delle celle reale e non limitato a poche celle scritte già 87 volte.

Anche questa rimane un ipotesi.

[s12a]

Con i Samsung ho solo esperienza con i più vecchi 830 (non molto) ed 840 con celle TLC, ma la mia impressione con il loro uso ed in particolare l'840, è che il wear leveling con essi lavori molto poco in condizioni normali, probabilmente perché il firmware preferisce diminuire scritture in background che livellare l'usura delle celle, e conseguentemente sostituire le celle più usurate mano a mano che appaiono invece che tutte insieme come potrebbe succedere se si usurassero tutte più o meno allo stesso modo.

Se a parità d'uso, con poco spazio occupato il contatore delle scritture inizia ad aumentare più velocemente vuol dire che il firmware sta mescolando in background in maniera più intensiva le celle di memoria per bilanciarne l'usura e che quindi il wear leveling sta funzionando. Questo implica che più dati vengono internamente scritti nell'SSD di quelli che fa l'utente (= alta write amplification).

Viceversa, se l'aumento del numero di scritture dell'SSD è praticamente pari a quelle che effettua l'utente (= bassa write amplifiction), vuol dire che il wear leveling sta lavorando poco o per nulla. Questo è il normale comportamento che ho osservato con l'840 ed in misura minore l'830.

Almeno questo secondo la mia opinione. Non ho particolari competenze o conoscenze da insider in merito, ho semplicemente usato SSD dal 2009.

Gli 840 avevano/hanno anche il problema che le prestazioni in lettura sui dati statici non fanno altro che diminuire nel tempo con un uso tipico, segno che i dati non vengono praticamente mai toccati dagli algoritmi di wear leveling dopo essere stati scritti. Il Crucial MX500 che uso al momento invece sembra sempre effettuare scritture in background anche senza fare nulla. Nella pratica durerà comunque 10 anni o giù di lì; forse è un accorgimento per evitare rallentamenti come con altri SSD (non era prerogativa degli 840/840 EVO TLC, ma era particolarmente visibile con questi).

È anche possibile che i Samsung 850 siano più attivi dal punto di vista del wear leveling per evitare i rallentamenti dei precedenti 840.

[giovanni69]

Originariamente inviato da @Liupen

(un 480GB vero?)

Corretto.

Originariamente inviato da s12a

Gli 840 avevano/hanno anche il problema che le prestazioni in lettura sui dati statici non fanno altro che diminuire nel tempo con un uso tipico, segno che i dati non vengono praticamente mai toccati dagli algoritmi di wear leveling dopo essere stati scritti.

Con il mio SM843T ho la stessa impressione: le performance sono peggiorate solo in lettura di circa il 20% e non in scrittura, usando lo stessa versione di Crystal Disk Mark di 4 anni fa.
A me la velocità in lettura bassa sia dovuta al poco spazio su disco.

EDIT: 20% recuperato con deframmentazione tranne decadimento sui 4K:

[s12a]

Originariamente inviato da giovanni69

Con il mio SM843T ho la stessa impressione: le performance sono peggiorate solo in lettura di circa il 20% e non in scrittura, usando lo stessa versione di Crystal Disk Mark di 4 anni fa.
A me la velocità in lettura bassa sia dovuta al poco spazio su disco.

Il test del degrado in lettura è possibile farlo in maniera affidabile solo leggendo l'unità sequenzialmente in modalità raw ad esempio con il tipico test di HDTune.

CrystalDiskMark crea un file temporaneo soggetto alla frammentazione del file system, e per quanto la frammentazione incida relativamente poco con gli SSD rispetto agli hard disk, ha comunque una incidenza sulle prestazioni massime ottenibili, dato che un numero maggiore di operazioni di input/output deve essere scambiato fra sistema operativo e SSD per leggere un certo range di settori logici. In altre parole quello che dovrebbe essere un'operazione sequenziale tende al random mano a mano che la frammentazione del file system aumenta, o magari operazioni che normalmente richiedono un numero n di comandi di I/O per essere svolte nei benchmark, con il file system frammentato possono richiedere n+x.

[ICER]

Ciao a tutti

Tra questi due modelli qual'e' migliore in termini di velocità e sopratutto affidabilità?

Crucial BX500 CT480BX500SSD1 480GB

Kingston SSD A400 480GB

Poi qualcuno sa dirmi la differenza sostanziale tra il Crucial BX500 e MX500?

Saluti

[Nicodemo Timoteo Taddeo]

Originariamente inviato da ICER

Ciao a tutti

Tra questi due modelli qual'e' migliore in termini di velocità e sopratutto affidabilità?

Crucial BX500 CT480BX500SSD1 480GB

Kingston SSD A400 480GB

In quanto a velocità dichiarate¹ il Crucial è leggermente migliore:

Sequenziale: lettura 540 scrittura 500 [Crucial BX500]

Sequenziale: lettura 500 scrittura 450 [Kingston A400]

ovviamente MB/s

Ma nell'uso poi dubito che noteresti differenze. Affidabilità? Non credo qualcuno possa dirti con sicurezza quel dei due è migliore, forse più che altro per il valore TBW il Kingston (160 contro 120). Ma si tratta di pura teoria.

Poi qualcuno sa dirmi la differenza sostanziale tra il Crucial BX500 e MX500?

In due parole? Velocità ed affidabilità :-)


Alla fine se puoi fare uno sforzicino e prendere l'MX500 è molto meglio.



¹ https://www.kingston.com/datasheets/sa400_it.pdf
https://content.crucial.com/content/...lyer-a4-it.pdf

[Arrow0309]

Salve gente, ho appena acquistato dalla baia inglese un ssd "particolare" in "offerta".
Si tratta di un Intel DC 4500 nvme (U2) da 2Tb, che userò come drive secondario (gaming, download freq, oc tests e utility) dopo aver pensionato il mio 860 Evo 1Tb.

Il prezzo attraente (190 sterline) per un drive del genere (Enterprise) nuovo mi ha portato subito all'acquisto (seppur dalla Cina ma sono fiducioso) visto che costano 3-4 volte di più.
Pere poi scoprire che (dalla foto) sembrano dei Engineering Samples quindi magari anche nuovi ma senza garanzia Intel. Il venditore non menziona questo quindi mi aspetto di avere almeno una garanzia paypal da 180 giorni.




Inoltre ho scoperto che non eccellano come prestazioni ma visto l'utilizzo destinato credo che possa bastare e durare anche diversi anni (con una endurance sopra la media).

Come alternativa avevo considerato un M2 Intel 660p da 2Tb ma veniva di più inoltre lo volevo in formato pcie (ho il terzo slot 16x/8x libero) quindi ho preso anche un adattatore pcie U2:




Ho sbagliato?
Pareri, consigli, opinioni?

[aled1974]

Originariamente inviato da Arrow0309

Si tratta di un Intel DC 4500 nvme (U2) da 2Tb, che userò come drive secondario (gaming, download freq, oc tests e utility) dopo aver pensionato il mio 860 Evo 1Tb.

spazio a parte in cosa ti limitava l'ssd sataIII?

Pere poi scoprire che (dalla foto) sembrano dei Engineering Samples quindi magari anche nuovi ma senza garanzia Intel. Il venditore non menziona questo quindi mi aspetto di avere almeno una garanzia paypal da 180 giorni.

Inoltre ho scoperto che non eccellano come prestazioni ma visto l'utilizzo destinato credo che possa bastare e durare anche diversi anni (con una endurance sopra la media).

per l'uso era del tutto sprecato anche il samsung IMHO

Ho sbagliato?
Pareri, consigli, opinioni?

mah, aspettiamo le tue

ciao ciao

[@Liupen]

Originariamente inviato da s12a

Con i Samsung ho solo esperienza con i più vecchi 830 (non molto) ed 840 con celle TLC, ma la mia impressione con il loro uso ed in particolare l'840, è che il wear leveling con essi lavori molto poco in condizioni normali, probabilmente perché il firmware preferisce diminuire scritture in background che livellare l'usura delle celle, e conseguentemente sostituire le celle più usurate mano a mano che appaiono invece che tutte insieme come potrebbe succedere se si usurassero tutte più o meno allo stesso modo.

Ho proprio l'impressione che sia così... cioè una scelta di programmazione che non un algoritmo limitato.

Originariamente inviato da s12a

Se a parità d'uso, con poco spazio occupato il contatore delle scritture inizia ad aumentare più velocemente vuol dire che il firmware sta mescolando in background in maniera più intensiva le celle di memoria per bilanciarne l'usura e che quindi il wear leveling sta funzionando. Questo implica che più dati vengono internamente scritti nell'SSD di quelli che fa l'utente (= alta write amplification).

Viceversa, se l'aumento del numero di scritture dell'SSD è praticamente pari a quelle che effettua l'utente (= bassa write amplifiction), vuol dire che il wear leveling sta lavorando poco o per nulla. Questo è il normale comportamento che ho osservato con l'840 ed in misura minore l'830.

Almeno questo secondo la mia opinione. Non ho particolari competenze o conoscenze da insider in merito, ho semplicemente usato SSD dal 2009.

Purtroppo ho dovuto reinstallare varie volte su questo pc, perdendo il monitoraggio di tutto compreso i parziali della Write Amplification. Quindi, nella mia condizione di SSD pieno, non ho idea se la WA stà anche aumentando. Riuscissi a capirlo potrei confutare o no l'ultima mia ipotesi, cioè che il Garbage Collection stà spostando continuamente celle, precedentemente occupate da dati statici) per far spazio alle nuove scritture in una situazione limite (ma appunto, niente rallentamenti...sembra di no).

Originariamente inviato da s12a

Gli 840 avevano/hanno anche il problema che le prestazioni in lettura sui dati statici non fanno altro che diminuire nel tempo con un uso tipico, segno che i dati non vengono praticamente mai toccati dagli algoritmi di wear leveling dopo essere stati scritti. Il Crucial MX500 che uso al momento invece sembra sempre effettuare scritture in background anche senza fare nulla. Nella pratica durerà comunque 10 anni o giù di lì; forse è un accorgimento per evitare rallentamenti come con altri SSD (non era prerogativa degli 840/840 EVO TLC, ma era particolarmente visibile con questi).

È anche possibile che i Samsung 850 siano più attivi dal punto di vista del wear leveling per evitare i rallentamenti dei precedenti 840.

Ricordo il problema degli 840 e 840evo, facevo un test al giorno
Probabilmente si pagava con Samsung lo scotto del pionerismo con le celle TLC su cui il segnale decadeva presto. Comunque ha fatto bene al settore, sia poi come miglioramento delle celle in genere sia come miglioramento degli algoritmi di programmazione.
Mi interessa l'osservazione che fai in merito al lavoro di background del Crucial, come riesci a misurarlo?
Vorrei farlo anch'io, ma un semplice stato del disco è impossibile, sopratutto Windows10 mi tiene impegnati i dischi continuamente!
Controllando l'attività dell'ssd in background (idle o attivo) forse riuscirei a capire se dietro c'è un lavoro di spostamento incredibile o appunto è uno scrivere (e riscrivere) i pochi GB disponibili senza badare al wear leveling.

Originariamente inviato da giovanni69

Corretto.

Con il mio SM843T ho la stessa impressione: le performance sono peggiorate solo in lettura di circa il 20% e non in scrittura, usando lo stessa versione di Crystal Disk Mark di 4 anni fa.
A me la velocità in lettura bassa sia dovuta al poco spazio su disco.

Originariamente inviato da s12a

Il test del degrado in lettura è possibile farlo in maniera affidabile solo leggendo l'unità sequenzialmente in modalità raw ad esempio con il tipico test di HDTune.

CrystalDiskMark crea un file temporaneo soggetto alla frammentazione del file system, e per quanto la frammentazione incida relativamente poco con gli SSD rispetto agli hard disk, ha comunque una incidenza sulle prestazioni massime ottenibili, dato che un numero maggiore di operazioni di input/output deve essere scambiato fra sistema operativo e SSD per leggere un certo range di settori logici. In altre parole quello che dovrebbe essere un'operazione sequenziale tende al random mano a mano che la frammentazione del file system aumenta, o magari operazioni che normalmente richiedono un numero n di comandi di I/O per essere svolte nei benchmark, con il file system frammentato possono richiedere n+x.

s12a ho osservato che usando HDTach o HDTune in modalità lettura raw, i Samsung sono sempre ineccepibili mentre SSD meno validi hanno una fortissima variazione con picchi al ribasso. Che ne pensi?
Riguardo il calo di lettura che hai Giovanni, rassegnati. Più che la deframmentazione (che comunque fa la sua) penso sia il normale deterioramento delle celle. L'eccessiva ossidazione crea una difficoltà sempre maggiore dell'ECC.

[Arrow0309]

Originariamente inviato da aled1974

spazio a parte in cosa ti limitava l'ssd sataIII?







per l'uso era del tutto sprecato anche il samsung IMHO



mah, aspettiamo le tue

ciao ciao

Vabbè se la metti così non aggiorniamo mai l'hw
Ammesso che l'ho fatto anche per scimmia un po, i motivi sono vari, a quanto già detto aggiungo il riutilizzo del 860 Evo come ssd esterno veloce, le linee pcie della mia cpu e l'utilizzo altamente in lettura del drive (gaming, altro).

https://gzhls.at/blob/ldb/c/8/0/7/5e...599060233e.pdf

Certo che sto ssd l'hanno subito rimpiazzato con il 4510 credo per scarse prestazioni in scrittura, cmq si trova abbastanza poco a riguardo (come utilizzo desktop ovv) credo anche per il prezzo fino a poco fa inaccessibile.
L'unico articolo per "paragonarlo" ad un 660p M2 della stessa capacità qui sotto:

https://forums.guru3d.com/threads/is...n-2019.428270/

Speriamo bene, vi terrò aggiornati

[giovanni69]

Originariamente inviato da @Liupen

Riguardo il calo di lettura che hai Giovanni, rassegnati. Più che la deframmentazione (che comunque fa la sua) penso sia il normale deterioramento delle celle. L'eccessiva ossidazione crea una difficoltà sempre maggiore dell'ECC.

Ma a che serve allora avere un numero di blocchi riservati se poi non vengono utilizzati? Il parametro #179 Used Reserved Block Count (Total) è ancora a 0.
Il #180 Unused Reserved Block Count (Total) è a 10496.
Il Runtime Bad Block (Total) è a zero.
Gli Uncorrectable Error Count è a zero; pure #195 ECC Rate, quindi tutto perfetto e dunque tutto questo... sprecato o semplicemente la diagnostica interna non si rende conto che le performance sono degradate?

Quanto alla deframmentazione ho installato SSDkeeper trial da qualche giorno...vedremo.



EDIT: risultati QUI.

[s12a]

Originariamente inviato da @Liupen

Mi interessa l'osservazione che fai in merito al lavoro di background del Crucial, come riesci a misurarlo?

I Crucial MX500 hanno il contatore delle scritture effettuate sulle memorie NAND. È possibile osservare che aumenta, spesso e tendenzialmente a caso, esattamente a colpi di 1 gigabyte anche senza particolari operazioni effettuate dal sistema operativo/utente. Dopo vari test e anche sistemi operativi diversi, ho constatato che il comportamento è dell'SSD stesso.

Con i Samsung non c'è questo contatore delle scritture NAND. Si può osservare indirettamente ciclo per ciclo di scrittura, dando per assunto che ogni volta che aumenta il contatore relativo è stato effettuato un numero di scritture sulle celle di memoria pari alla capienza fisica delle memorie installate nell'SSD, includendo anche lo spazio di overprovisioning. Quindi se ci sono 256 GB di memoria NAND fisicamente, ma utilizzabili sono ad esempio solo 230 o giù di lì, contano 256 GB.

s12a ho osservato che usando HDTach o HDTune in modalità lettura raw, i Samsung sono sempre ineccepibili mentre SSD meno validi hanno una fortissima variazione con picchi al ribasso. Che ne pensi?

Il test di HDTune va fatto con i blocchi in lettura di massima dimensione impostabile (1 MB mi sembra, di più sulla versione pro) e nella modalità più lenta/accurata possibile.

Questo è l'SSD in condizioni parzialmente degradate: https://i.imgur.com/sZt6xnF.png

Questo dopo aver riscritto le celle in un modo o nell'altro, o con lo spazio completamente vuoto: https://i.imgur.com/Uxlw9Ed.png

[giovanni69]

Originariamente inviato da s12a

Con i Samsung non c'è questo contatore delle scritture NAND.

E poi c'è sempre l'incognita che sia proprio quello....

[s12a]

Quel contatore sembra che sia assente sui Samsung di fascia consumer, od almeno la maggior parte di essi, per quanto abbia avuto modo di osservare tempo fa da vari screenshot dei parametri SMART visibili in rete di questi SSD.

[giovanni69]

Ammesso che sia poi un contatore riferibile alle NAND; Crystal Disk Info mostra ancora un 'Specifico del produttore'. Se ha quel nome su HD Sentinel lo sai bene...

[@Liupen]

Originariamente inviato da s12a

I Crucial MX500 hanno il contatore delle scritture effettuate sulle memorie NAND. È possibile osservare che aumenta, spesso e tendenzialmente a caso, esattamente a colpi di 1 gigabyte anche senza particolari operazioni effettuate dal sistema operativo/utente. Dopo vari test e anche sistemi operativi diversi, ho constatato che il comportamento è dell'SSD stesso.

Con i Samsung non c'è questo contatore delle scritture NAND. Si può osservare indirettamente ciclo per ciclo di scrittura, dando per assunto che ogni volta che aumenta il contatore relativo è stato effettuato un numero di scritture sulle celle di memoria pari alla capienza fisica delle memorie installate nell'SSD, includendo anche lo spazio di overprovisioning. Quindi se ci sono 256 GB di memoria NAND fisicamente, ma utilizzabili sono ad esempio solo 230 o giù di lì, contano 256 GB.

Originariamente inviato da s12a

Quel contatore sembra che sia assente sui Samsung di fascia consumer, od almeno la maggior parte di essi, per quanto abbia avuto modo di osservare tempo fa da vari screenshot dei parametri SMART visibili in rete di questi SSD.

Giusto, ho capito, tenendo d'occhio la scrittura su celle anche in condizione di assenza di imput LBA, un monitoraggio utile. Grazie.

Mmm...niente dato puro di scrittura delle celle nello smart, ma neanche quello indiretto che suggerisci perchè appunto le programmazioni aumentano di quasi 1 al giorno in questo SSD quasi pieno a fronte di qualche decina di GB host scritti.
Stavo cercando dei modi partendo dai dati RAW di CDInfo, ma con soli due dati (scritture host/LBA e ciclo di P/E) non si riesce a far nulla.

Originariamente inviato da s12a

Il test di HDTune va fatto con i blocchi in lettura di massima dimensione impostabile (1 MB mi sembra, di più sulla versione pro) e nella modalità più lenta/accurata possibile.

Questo è l'SSD in condizioni parzialmente degradate: https://i.imgur.com/sZt6xnF.png

Questo dopo aver riscritto le celle in un modo o nell'altro, o con lo spazio completamente vuoto: https://i.imgur.com/Uxlw9Ed.png

Ok, per il futuro utilizzerò HDTune e i parametri che mi hai indicato
Per quanto riguarda la lettura grezza con HDTach (usa blocchi da 8MB) è questo che osservo
https://imgur.com/DrwItxJ
KingDian 250GB appena formattato*.

EDIT: *SSD nuovo appena formattato

Originariamente inviato da giovanni69

Ma a che serve allora avere un numero di blocchi riservati se poi non vengono utilizzati? Il parametro #179 Used Reserved Block Count (Total) è ancora a 0.
Il #180 Unused Reserved Block Count (Total) è a 10496.
Il Runtime Bad Block (Total) è a zero.
Gli Uncorrectable Error Count è a zero; pure #195 ECC Rate, quindi tutto perfetto e dunque tutto questo... sprecato o semplicemente la diagnostica interna non si rende conto che le performance sono degradate?

Quanto alla deframmentazione ho installato SSDkeeper trial da qualche giorno...vedremo.

So che prima di essere segnalato come vero e proprio errore di lettura, gli algoritmi ECC usano una ri-lettura relativamente più lenta (un secondo livello di lettura). Quella successiva è la ricostruzione del dato (RAIN, parità, o forme complesse dii ECC) in questo caso hai poi la segnalazione nello SMART ma anche, a seconda del dato perso , un rallentamento, blocco, o BSoD.
Magari esagero, Giovanni, effettivamente non hai usato il tuo SSD già da avere il 20% di lettura in meno di velocità di lettura, ma prima o poi questo avviene a causa degli elettroni dispersi sul gate che rendono la lettura della carica sempre più difficoltosa.
Vedi se effettivamente un defrag forzato ti porta dei benefici; ho motivo di ritenere di si, visto quanto analizzato nel passato da s12a.

[@Liupen]

Non vedo neanche su Magician il tool proprietario, nello SMART, il parametro 243

[RobbyBtheOriginal]

questi comportamenti li rilevate anche su SSD nvme samsung della linea 970 evo? O per i modelli successivi a quelli da voi citati hanno risolto il "problema"?

[@Liupen]

Originariamente inviato da RobbyBtheOriginal

questi comportamenti li rilevate anche su SSD nvme samsung della linea 970 evo? O per i modelli successivi a quelli da voi citati hanno risolto il "problema"?

Diciamo che se è un vero problema, è anche in una condizione limite.
Poi potrebbe essere associato al modello di SSD e non riguardare altri controller o produttori.