SSD: thread generale e consigli per gli acquisti

[tomahawk]

Per il benchmark degli SSD va ancora bene il vecchio AS benchmark?

[makka]

@giovanni69:
io non vedo gli stessi dati che hai tu su CrystalDiskInfo,
le voci che ti sembrano strane io non le ho proprio (oppure si chiamano in maniera totalmente differente).
La mia è la versione 8.2.4 x64.

[giovanni69]

@makka; anch'io ho usato quella versione.
E' possibile che voci SMART possano essere diverse da modello (Asenno) a modello (Crucial); per questo chiedevo lumi ...

[makka]

Originariamente inviato da giovanni69

@makka; anch'io ho usato quella versione.
E' possibile che voci SMART possano essere diverse da modello (Asenno) a modello (Crucial); per questo chiedevo lumi ...

Io ho tutti crucial e un Trascend, in effetti è come dici tu, ogni produttore
fa quello che vuole, ecco un screenshot del trascend, molto diverso (e molto meno utile) rispetto al crucial:

[RobbyBtheOriginal]

Io ho esperienza su HD di marche differenti e confermo che lì la diversità delle voci c'è (ho solo un SSD)

by Tapaparla®©

[giovanni69]

Capisco che ci possano essere parametri SMART diversi, compresi quelli specifici del produttore (@makka prova anche HD Sentinel, magari ti regala qualche info in più) ma la mia preoccupazione era questa:

Codice PHP:

Cosa sono quei 193 'Blocchi errati totali'?

E quegli "accessi non allineati"? Ho effettuato una clonazione key USB bootable di MiniTool 11.5. 


Sono normali quei blocchi e quegli accessi?

[@Liupen]

Per un certo periodo ho dovuto tenere l'SSD pieno a oltre il 90% della capienza (dai 12 ai 7GB liberi), utilizzandolo normalmente ossia con circa 5-10 GB di dati scritti al giorno, che poi ovviamente dovevo trasferire su un HDD portable, visto la scarsità di memoria...
Subito è avvenuta una impennata del livello generale di usura delle celle.

https://ibb.co/XF9sndy

Normalmente, con un SSD pieno al 60% (ma è stato ovviamente uno riempirsi progressivo) in questi 4 anni è cresciuto con una media - come si può vedere - di 70 cicli, ovvero 17,5 cicli di scrittura da 250GB l'anno. Nel giro di 6 mesi i cicli d'uso medi sono saliti a 87, con un incremento del 90%.

E' possibile, anzi sicuro che nell'SSD siano presenti celle che hanno subito pochissime scritture (o cicli), ma alla fine saranno poche celle usurate che determineranno il primo settore riallocato e di conseguenza la dismissione dell'SSD per inaffidabilità, detto questo, ecco perchè preoccuparsene.. anche se è più voglia di sapere il meccanismo di programmazione del Wear leveling.

Chiedo secondo voi se avete avuto modo di osservare l'algoritmo in condizioni estreme e che idea vi siete fatti.
Grazie.

[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