PROBLEMA Allungamento tempo spegnimento pc dopo clonazione su SSD

Pubblicità
Naturalmente il Wear Leveling non può far miracoli (i test di endurance non lo mettono in evidenza) ma molto prima del raggiungimento dei 1200Tb che hai scritto ma :look: largamente dopo gli 80Tb della garanzia, la prima cella si spegnerà senza poter essere sostituita e con buona probabilità in breve tempo il sistema operativo darà degli errori fatali....anche a SSD ancora funzionante, sarà inaffidabile.
E poi, tanto per portare allegria, sembra che la parte più delicata dell'SSD sia il controller e non l'end of life delle celle....
D'altronde ragazzi creare un prodotto decennale è, per i produttori, darsi la classica "zappa sui piedi"!
Durano tanto ma non quanto dicono i numeri teorici.

La morale, Giulio, è "non ti preoccupare" della durata del tuo ssd ed usalo come se fosse un normale disco, traendone tutti i vantaggi. :rock:
vedi s12a come ha strapazzato il suo...:D ma scommetto che il suo l'840 basico è ancora vivo e vegeto!!
 
Lo farò :D Solo per il download, ho intenzione di comprarmi una SD da tenere fissa nel portatile, così le cose che scarico (p2p ecc.) finiscono lì (per poi passare all'ssd o su hdd esterno in base alla funzione). Tanto con una connessione 7 mega (o 20 mega che avrò a breve), non ho bisogno di alte velocità di scrittura.
Per tutto il resto, c'è l'ssd :asd:

Grazie ad entrambi per tutti i preziosi consigli e per la vostra chiarezza nelle spiegazioni :birra:
 
Effettivamente il Samsung 840 250GB l'avevo sostituito semplicemente perché mi serviva un SSD più capiente. Quando l'ho cambiato, è arrivato a 59 cicli di scrittura su 1000, con circa 10.9 terabyte di scritture Host in 14 mesi d'uso.

Anche di quello ho tracciato l'andamento del wear leveling count e delle scritture Host nel corso del tempo:

lib.webp
 
Ultima modifica:
...anche di quello?! :lol:

Però mi sembra che gestisca meglio la WA o sbaglio?
PS. non fare l'ultimo aggiornamento firmware.
Curiosità: ti sei fatto un'idea del bug?
 
...anche di quello?! :lol:
È da lì che ho iniziato. Purtroppo non l'ho fatto a fondo per quelli che ho avuto in precedenza (Samsung 830 64GB e Intel X25-E 64GB)

Però mi sembra che gestisca meglio la WA o sbaglio?
Sì, in generale a parità d'uso la mia impressione è che avesse una WA minore, circa la metà rispetto al mio attuale SanDisk Extreme II, cosa che in parte controbilancia la minore durata delle celle da specifiche di progetto.

PS. non fare l'ultimo aggiornamento firmware.
Curiosità: ti sei fatto un'idea del bug?
Purtroppo Samsung non ha ancora emanato un firmware per la correzione del bug dei dati statici vecchi sui Samsung 840 prima serie che io ho. Da quello che ho visto dai resoconti di altri utenti, permane ancora sugli 840 EVO anche dopo l'ultimo firmware. (EDIT: sembra che possa essere una svista da parte loro/sua. In attesa di aggiornamenti a riguardo...)

Sul mio 840 250GB (che ho spostato su un altro PC) ho notato che il bug velocistico si manifesta principalmente con letture sequenziali a blocchi sotto una certa dimensione. Con blocchi da 4 kilobyte o meno, la velocità rimane costante a prescindere dal fatto che un dato settore contenga o meno dati vecchi, e questo può essere il motivo per il quale molta gente non l'ha notato, dato che principalmente il normale uso del sistema operativo e dei programmi comprende in gran parte letture di piccoli blocchi.

Io non sono così convinto che si tratti di un problema intrinseco delle memorie come diversa gente pensa, perché se così fosse con molta probabilità il bug si manifesterebbe anche sulla lettura di piccoli blocchi.

- - - Updated - - -

giulio_splash ha detto:
Se è così però si sprecano proprio i produttori a lasciare garanzie di 80 Tb :S

A proposito, ieri ho provato a spedire a SanDisk una email per sapere se gli 80 TBW sono davvero vincolanti per la garanzia, ed a quanto pare, sembra di no, almeno per noi italiani (dove la garanzia non è denominata "Garanzia Limitata"):


Supporto Tecnico SanDisk ha detto:
Egregio Sig. xxx xxx,
La ringrazio per la Sua mail
Capisco che vorrebbe sapere come calcolare la garanzia considerando sia il tempo che le scritture sulla ssd.
La vorrei informare che il tempo della copertura rimane invariato lo stesso e che il la durata e' di 5 anni.

le invio il link con la garanzia dei nostri prodotti:
garanzie Sandisk

Cliccare quiper registrare il prodotto on-line.
Si prega di fornire il Suo numero di telefono (che sarà utilizzato solo per chiamate di assistenza tecnica)

Rimango a sua disposizione qualora desideri ulteriori informazioni. La ringrazio molto per la sua gentile collaborazione!


Cordiali saluti,

Nikos P.
SanDisk Technical Support
 
Ultima modifica:
È da lì che ho iniziato. Purtroppo non l'ho fatto a fondo per quelli che ho avuto in precedenza (Samsung 830 64GB e Intel X25-E 64GB)

Per me l'840basico è stato l'inizio, ed è nel pc desktop. I notebook un Samsung 840 PRO e Sandisk basico.
Sul lavoro ho piazzato degli EVO... e sono questi che mi preoccupano...anche perchè vengono notevolmente più sfruttati.
La cosa che mi preoccupa non sono i cali di prestazioni (che si vedono solo dai bench appositi) ma il degrado del segnale specie se leggo che bastano alcune settimane di "fermo macchina" per far insorgere evidenti problemi ECC.


Sì, in generale a parità d'uso la mia impressione è che avesse una WA minore, circa la metà rispetto al mio attuale SanDisk Extreme II, cosa che in parte controbilancia la minore durata delle celle da specifiche di progetto.

Purtroppo Samsung non ha ancora emanato un firmware per la correzione del bug dei dati statici vecchi sui Samsung 840 prima serie che io ho. Da quello che ho visto dai resoconti di altri utenti, permane ancora sugli 840 EVO anche dopo l'ultimo firmware.

Sul mio 840 250GB (che ho spostato su un altro PC) ho notato che il bug velocistico si manifesta principalmente con letture sequenziali a blocchi sotto una certa dimensione. Con blocchi da 4 kilobyte o meno, la velocità rimane costante a prescindere dal fatto che un dato settore contenga o meno dati vecchi, e questo può essere il motivo per il quale molta gente non l'ha notato, dato che principalmente il normale uso del sistema operativo e dei programmi comprende in gran parte letture di piccoli blocchi.

Io non sono così convinto che si tratti di un problema intrinseco delle memorie come diversa gente pensa, perché se così fosse con molta probabilità il bug si manifesterebbe anche sulla lettura di piccoli blocchi. Penso ad ogni modo che ci saranno presto aggiornamenti a riguardo, molta gente è comprensibilmente furiosa.


Anche dopo la correzione del firmware, gli EVO continuano ad avere problemi? :muro:

Ho letto invece che hanno appurato, con lo stesso test, che in misura minore, soffre del bug anche il basico; avendo all'inizio sperato che fosse per una versione firmware non ottimizzata, ora sono proprio tra quelli che pensano che dipenda dalle celle TLC.

Ciò che osservi però mi interessa, sembrerebbe spostare la causa altrove...anche se non riesco al momento a trovare una ipotesi logica che possa spiegarlo. Facendo il test di lettura dei file (Mb/sec in relazione al tempo su cui giacciono sull'SSD) sul 840, noto una (lieve) tendenza generale al calo ma non coincide sempre con file grandi (e quindi la sequenzialità).... Mah!

:grat: Ho cercato di essere alla tua altezza e ti propongo, sulla traccia dei tuoi grafici, quelli del mio 840 (l'unico su cui ho fatto un po di monitoraggio serio).
L'uso è prettamente domestico
840.webp

a distanza di più di un anno dall'ultima formattazione... WA in lenta ma "iperbolica" ascesa :(


PS - un'idea mentre scrivo mi è venuta; supponi che il problema si riduca solo alla minore capacità delle celle TLC (Samsung, magari quelle Sandisk sono diverse..) di mantenere gli elettroni nel gate e quindi che, con tre segnali diversi per cella, capiti che sia più frequente un errore ECC (e quindi il tempo per recuperare il dato). Se questo fosse vero allora la lettura di un file grande, costituito da più blocchi, sarebbe più difficoltosa (prestazione giù) di un file piccolo.
Ti convince come ipotesi?

____

Buono! W Sandisk!!
____
 
Per me l'840basico è stato l'inizio, ed è nel pc desktop. I notebook un Samsung 840 PRO e Sandisk basico.
Sul lavoro ho piazzato degli EVO... e sono questi che mi preoccupano...anche perchè vengono notevolmente più sfruttati.
La cosa che mi preoccupa non sono i cali di prestazioni (che si vedono solo dai bench appositi) ma il degrado del segnale specie se leggo che bastano alcune settimane di "fermo macchina" per far insorgere evidenti problemi ECC.
Hai informazioni più dettagliate o link a riguardo di problemi specifici di ECC per gli 840 EVO?


Anche dopo la correzione del firmware, gli EVO continuano ad avere problemi? :muro:
Così sembra, ma è da confermare. Altri non sembrano riscontrare la stessa problematica, dopo aver aggiornato.

Ho letto invece che hanno appurato, con lo stesso test, che in misura minore, soffre del bug anche il basico; avendo all'inizio sperato che fosse per una versione firmware non ottimizzata, ora sono proprio tra quelli che pensano che dipenda dalle celle TLC.
Su un PC ho appunto un 840 "base" con memorie TLC e confermo il problema. Non sono usciti ancora firmware correttivi, a differenza dell'EVO. Io ipotizzo sia una svista da parte degli sviluppatori del firmware, che ha causato un bug che si è "ereditato" anche l'EVO, avendo con tutta probabilità una gestione interna molto simile all modello che sostituisce, turbowrite a parte.

Ciò che osservi però mi interessa, sembrerebbe spostare la causa altrove...anche se non riesco al momento a trovare una ipotesi logica che possa spiegarlo. Facendo il test di lettura dei file (Mb/sec in relazione al tempo su cui giacciono sull'SSD) sul 840, noto una (lieve) tendenza generale al calo ma non coincide sempre con file grandi (e quindi la sequenzialità).... Mah!
Puoi verificare la cosa con HDTune 2.55, facendo il test di velocità in lettura. I settori corrispondenti a file memorizzati da diverso tempo hanno prestazioni ridotte. In teoria, visto che il test fa una grande lettura sequenziale dall'inizio alla fine dei blocchi logici dell'unità, dovrebbe essere una linea continua e stabile.

Dalle opzioni di HDTune puoi impostare la dimensione del blocco in lettura. Con dimensioni dai 4 kB in giù, il problema scompare. Più aumenti la dimensione, più l'effetto è evidente. HDTune di default usa blocchi da 64 kB, con cui la problematica è già piuttosto visibile.

:grat: Ho cercato di essere alla tua altezza e ti propongo, sulla traccia dei tuoi grafici, quelli del mio 840 (l'unico su cui ho fatto un po di monitoraggio serio).
L'uso è prettamente domestico
Visualizza allegato 139088

a distanza di più di un anno dall'ultima formattazione... WA in lenta ma "iperbolica" ascesa :(
840 prima serie, dunque. La WA sarebbe stata meglio metterla su un asse a parte, ma ad occhio pare essere su valori ancora abbastanza bassi (1.25-1.30x). Che aumenti con l'uso normale è naturale; inoltre sugli 840 prima serie non può scendere sotto 1.0x come con gli EVO (apparentemente).

PS - un'idea mentre scrivo mi è venuta; supponi che il problema si riduca solo alla minore capacità delle celle TLC (Samsung, magari quelle Sandisk sono diverse..) di mantenere gli elettroni nel gate e quindi che, con tre segnali diversi per cella, capiti che sia più frequente un errore ECC (e quindi il tempo per recuperare il dato). Se questo fosse vero allora la lettura di un file grande, costituito da più blocchi, sarebbe più difficoltosa (prestazione giù) di un file piccolo.
Ti convince come ipotesi?
Non saprei, ad essere sincero. Considerando che con la lettura di blocchi piccoli il drive lavora al 100% di occupazione la mia idea è che in tale frangente non sia occupato a correggere errori. Se il problema è stato davvero corretto via firmware con l'EVO (dando per assunto che la sua reiterata manifestazione sia una svista da parte dell'utente che ha riportato la cosa), è possibile che il bug sia da qualche parte nelle variabili di adeguamento usate dagli algoritmi dell'ECC; può essere ad esempio che magari adegui eccessivamente in base allla temperatura di esercizio (del controller o delle memorie) le operazioni di lettura di celle contenenti dati vecchi più di tot giorni. Mi sembra proprio di aver letto tempo fa che aumentare la temperatura, anche se non assolutamente a livelli preoccupanti, appariva esercitare un effetto negativo evidente (ed in ogni caso correlato) sulle prestazioni.
 
Ok cerco il link.
Mi é ostica questa cosa della wa inferiore a 1, possibile?
Cioé possibile che un comando inviato dal sistema operativo al controller venga cancellato prima della trascrizione...dando per assunto che la stessa cancellazione è a tutti gli effetti un semplice trim su un blocco di page di celle giá programmate....
 
Ok cerco il link.
Mi é ostica questa cosa della wa inferiore a 1, possibile?
Cioé possibile che un comando inviato dal sistema operativo al controller venga cancellato prima della trascrizione...dando per assunto che la stessa cancellazione è a tutti gli effetti un semplice trim su un blocco di page di celle giá programmate....
Sì, questo è esattamente quello che succede[rebbe], grazie alla cache SLC che si ritrovano. Nella recensione del SanDisk Ultra II di Anandtech, che usa un sistema simile in maniera specifica per far scendere la WA sotto 1.0x, è spiegato chiaramente:

AnandTech | SanDisk Ultra II (240GB) SSD Review

[...] The improved performance is not the only benefit of nCache 2.0. Because everything gets written to the SLC portion first, the data can then be written sequentially to TLC. That minimizes write amplification on the TLC part, which in turn increases endurance because there will be less redundant NAND writes. With sequential writes it is typically possible to achieve write amplification of very close to 1x (i.e. the minimum without compression) and in fact SanDisk claims write amplification of about 0.8x for typical client workloads (for the TLC portion, that is). That is because not all data makes it to the TLC in the first place – some data will be deleted while it is still in the SLC cache and thus will not cause any wear on the TLC. Remember, TLC is generally only good for about 500-1,000 P/E cycles, whereas SLC can easily surpass 30,000 cycles even at 19nm, so utilizing the SLC cache as much as possible is crucial for endurance with TLC at such small lithographies.

Io credo sia assai probabile che i Samsung EVO facciano lo stesso e che dunque i valori di WA inferiore ad 1.0x calcolati per questi drive non siano frutto di errore. Tuttavia servirebbe la conferma da parte di Samsung.
 
Ultima modifica:
Aaaaah!!!
Ora ho capito.
Ma è proprio diverso da come ho scritto.
Grazie per l'articolo che non avevo letto...sará che nelle tlc non ho più molta fiducia.
É una banfata di Sandisk che ha "teorizzato" che per "certi" tipi di dati scrivendo prima sull'emulazione SLC e non trasferendo in TLC non ci sono scritture host.
Si, peccato che l'emulazione SLC, anche se la chiamo n-cache 2.0 ...sempre di programmazione trattasi!! E che le celle emulate non possono prescindere dalle celle non (sempre le stesse sono).
Ció non toglie che sia un buon modo di tendere a 1 la wa.
Penso che nei Samsung non ci sia. La parte emulata é piú piccola e non ci sono i tempi per il "giochetto" del trasferimento sequenziale. Penso sia proprio una buona programmazione del GC.

Comunque interessante sapere che anche Sandisk usi un sistema simile al rain.
 
Ultima modifica:
Pensavo ti riferissi al buffer SLC TurboWrite. Non credo che i dati rimangano nella cache volatile dell'SSD in attesa di essere potenzialmente cancellati prima del riversamento nella memoria flash, sarebbe troppo rischioso per l'integrità degli stessi in caso di mancanza dell'alimentazione.

Alla presentazione dell'840 EVO avevo letto che la parte SLC, anche se ottenuta a partire da memoria TLC, avrebbe una durata piuttosto elevata, di circa 50000 cicli di scrittura, tuttavia non ho più letto conferme della cosa altrove. La cosa però avrebbe senso in quanto con due soli stati (basso/alto) i margini di tolleranza di errore per la lettura dei bit delle celle pseudo-SLC contenenti i dati di passaggio sarebbero molto più elevati.

Samsung 840 Evo SSD review: the entire series tested! - TurboWrite and MEX controller | Hardware.Info United States

The TurboWrite buffer has a permanent spot on the SSD, so specific TLC chips are reserved for and used as SLC. The fact that the buffer is stationary makes you wonder what the impact is on the lifespan. Samsung indicated that TLC memory used as SLC has a lifespan of about 50,000 P/E cycles heeft, a lot more than the 3,000 we achieved in our endurance test of the 840s.


 
Ultima modifica:
@s12a

Ecco quà l'articolo che sono riuscito a recuperare
AnandTech | Samsung Releases Firmware Update to Fix the SSD 840 EVO Read Performance Bug

Ho letto altre cose cercando sull'argomento ma non mi sono rimasti link.


Vero che emulando le celle TLC come SLC gli si fa fare meno scritture (P/E) ma, a differenza della nCache 2.0 di Sandisk, la parte dedicata è meno consistente (da 3 a max 12Gb a seconda del taglio dell'SSD) ed il passaggio deve avvenire immediatamente e non per copia sequenziale.
Facendo un esempio, nel disco da 120Gb solo 3Gb sono emulati SLC, quindi solo una piccolissima parte subisce un consumo minore (10 mila P/E).
Per questo ti dico che penso sia merito dell'ottima programmazione dei Samsung 840 se WA in uso "casalingo" rimane basso.
 
Pubblicità
Pubblicità
Indietro
Top