SSD: thread generale e consigli per gli acquisti

[mieto]

Originariamente inviato da TonyVe

Si sono adeguati.
97€.

In questo momento se metto a carrello il 2Tb EN870 mi da 88.95 euro -10% di sconto = 80.05 euro spedito

[TonyVe]

@mieto




Se me lo sai spiegare ti ringrazio!
Sia da loggato sia da non loggato.
Spedizione non in posto particolare.

Il puntino di domanda dice: The final tax and total will be confirmed by email or text after you place your order

[mieto]

Originariamente inviato da TonyVe

@mieto

Se me lo sai spiegare ti ringrazio!
Sia da loggato sia da non loggato.
Spedizione non in posto particolare.

Il puntino di domanda dice: The final tax and total will be confirmed by email or text after you place your order

'azzarola adesso esce anche a me la voce "Estimated taxes"

Non capisco perchè se la destinazione è ad es: in Austria le tasse vanno a zero, se invece è Germania o Italia compaiono le tasse...

Peccato...

[Black (Wooden Law)]

Recensione cinese del Kingston Fury Renegade G5: https://youtu.be/6yjRG_1jzx8?si=v-MQuwkungKov_ta.

Confermato l’SM2508 con NAND flash Kioxia BiCS8 (non capisco perché hanno implementato queste NAND flash che sono “vecchie” e peggiori rispetto alle B68S o alle YMTC 267L). Al minuto 1:13 le performance su CDM, dove sono peggiori rispetto agli SM2508 con B58R come il BIWIN X570 Pro, peggiori rispetto agli SM2508 con YMTC 267L e sul livello dei MAP1806 con EET1A e del 9100 PRO. In cache SLC dimostra essere un full-drive SLC con ~645GB di cache SLC, una velocità direct-to-TLC di 2.500 MB/s e uno stato di folding dovuto dall’enorme cache SLC di 1.500 MB/s.

Le performance sono buone (non ottime, ottime lo sono degli SSD che hanno NAND flash più recenti e migliori) ma rimango molto deluso sulla scelta delle NAND flash. Per essere il primo drive Gen5 con BiCS8 che vedo mi aspettavo molto di meglio.

Per ora, tra tutti i Gen5 che abbiamo visto, 4600 > Ti9000 Pro > P51 > Fury Renegade G5 > 9100 PRO > C5000. L’unico motivo per il quale metto il C5000 sotto al 9100 PRO è perché è DRAM-less e ha performance randomiche peggiori (ma forse non dovute per la mancanza della DRAM ma per il firmware mal ottimizzato del controller), d’altronde lo preferisco personalmente. Probabile che in futuro, infatti, ammettendo aggiornamenti del firmware di miglioramento delle performance, lo consiglierò rispetto al 9100 PRO.

Una cosa che trovo davvero interessante è il riferimento dell’articolo scritto sulla cache SLC al minuto 4:07. Nell’articolo i punti secondo me più importanti sono:
1) WD dice che la cache SLC (da loro chiamata “nCache”) all’inizio era fatta per ospitare soltanto la mappa L2P delle NAND flash e le scritture di piccole dimensioni (meno di 4kB), poi con nCache 2.0 la cache SLC ha incominciato ad ospitare qualsiasi scrittura di qualsiasi dimensione e soprattutto è aumentata di capacità, passando da 5GB a 120GB. Qui è stato introdotto anche il folding. Altro punto interessante è che con nCache 2.0 qualsiasi scrittura veniva mandata in cache SLC comportando a del folding obbligatorio dopo l’esaurimento del buffer SLC e a poche scritture sulle NAND flash TLC. Poi, con le NAND flash TLC 3D che hanno visto miglioramenti sia in performance che durata, han deciso di introdurre (con nCache 3.0) le scritture “direct-to-TLC” in modo tale da indirizzare le scritture su NAND flash TLC dopo l’esaurimento del buffer SLC; così facendo non si fa per forza del folding;
2) una cache SLC “virtuale” fatta in questa maniera è sicuramente migliore rispetto ad una cache SLC “fisica”, questo perché quella fisica richiederebbe un’espansione del numero di blocchi fisici e quindi una struttura FTL “peggiore”;
3) HOMOLAB ci conferma che finché le scritture vengono effettuate in cache SLC la durata aumenta.

[Black (Wooden Law)]

Segnalo Seagate FireCuda 530R da 1TB a 87 euro. La componentistica è Phison E18 con NAND flash Kioxia BiCS6 (162L), è sicuramente una versione migliore del FireCuda 530 e di tanti altri PCIe 4.0 come l'SN850X, Fury Renegade, ecc.

[@Liupen]

Originariamente inviato da Black (Wooden Law)

In cache SLC dimostra essere un full-drive SLC con ~645GB di cache SLC, una velocità direct-to-TLC di 2.500 MB/s e uno stato di folding dovuto dall’enorme cache SLC di 1.500 MB/s.

Mumble...mumble....

E' un po strana la situazione: di solito prima il controller utilizza la scrittura diretta (nel test l'ssd è VUOTO) e poi, diciamo, "va in crisi" gestendo il folding (writeback).
In stato di folding si osservano quelli che sono i pregi e difetti del firmware nello scrivere assiduamente (condizione limite quanto non troppo lontana dalla realtà se si ha a che fare con un ssd normalmente usato e "normalmente" pienotto).

Tornando però al Renegade G5 in questa versione da 2TB, dopo aver scritto oltre 600 GB in cache emulata SLC, invece di scrivere al termine della cache sulle celle (TLC nello specifico), cerca di ripristinare la cache, quindi writeback SLC---> TLC + TLC direct-to. Molto stupido.

Sono andato a prendere la recensione di THW del Micron 4600 2TB. per capire un comportamento base del SM2508 (controller).
La cache SLC risulta della metà e l'ssd procede giustamente in direct-to write su celle TLC (in questo caso le Micron) a poco meno 4 GB/s (che è buono).

Se come scelta è voluta è quantomeno interessante... al netto del firmware che ha comunque bisogno di un aggiustatina perchè si parla di un problema di recupero.

Cerchiamo di capire, Black, le conseguenze di questo approccio.

Immaginando un ssd nvme Renegade G5 pieno a oltre il 70% ed usato continuamente da un paio d'anni con dati statici/dinamici che hanno previsto cancellazioni e riscritture, questa programmazione, porta effettivamente qualche vantaggio per un utente domestico?

Originariamente inviato da Black (Wooden Law)

Una cosa che trovo davvero interessante è il riferimento dell’articolo scritto sulla cache SLC al minuto 4:07. Nell’articolo i punti secondo me più importanti sono:
1) WD dice che la cache SLC (da loro chiamata “nCache”) all’inizio era fatta per ospitare soltanto la mappa L2P delle NAND flash e le scritture di piccole dimensioni (meno di 4kB), poi con nCache 2.0 la cache SLC ha incominciato ad ospitare qualsiasi scrittura di qualsiasi dimensione e soprattutto è aumentata di capacità, passando da 5GB a 120GB. Qui è stato introdotto anche il folding. Altro punto interessante è che con nCache 2.0 qualsiasi scrittura veniva mandata in cache SLC comportando a del folding obbligatorio dopo l’esaurimento del buffer SLC e a poche scritture sulle NAND flash TLC. Poi, con le NAND flash TLC 3D che hanno visto miglioramenti sia in performance che durata, han deciso di introdurre (con nCache 3.0) le scritture “direct-to-TLC” in modo tale da indirizzare le scritture su NAND flash TLC dopo l’esaurimento del buffer SLC; così facendo non si fa per forza del folding;
2) una cache SLC “virtuale” fatta in questa maniera è sicuramente migliore rispetto ad una cache SLC “fisica”, questo perché quella fisica richiederebbe un’espansione del numero di blocchi fisici e quindi una struttura FTL “peggiore”;
3) HOMOLAB ci conferma che finché le scritture vengono effettuate in cache SLC la durata aumenta.

Cosa hai scovato di bello?
leggo... caspita che tono... davvero si da dell'imbecille a qualcuno?
I Like It!
Ahahaha!

[@Liupen]

Gli ssd aziendali utilizzano la cache emulata, ci mancherebbe!
La nuova generazione di ssd aziendali li rende un'alternativa economicamente vantaggiosa alla soluzione enterprise classica.
Anzi siamo ora al punto che celle TLC vengono emulate SLC totalmente per permettere all'ssd U2 Pcie di avere una reattività e velocità migliore ad un costo decisamente più basso.

Già come affermazioni iniziali, non so se il cogl***e può essere il tizio che scrive e non quello a cui si riferisce...


Punto 1) Black
Io c'ero.. e qualcun altro quì c'era quando è nata negli ssd la nCache di Sandisk.
Poi partì anche il turbowrite di Samsung ma Sandisk fu la prima, già quando cercava buone prestazioni con gli ssd sata MLC.

Ah, tra l'altro si tratta di Sansisk... S A N D I S K non certo WD come scrive il tipo.
Sandisk quella originale, vera, partner di Toshiba e nel gota degli ssd con poche altre: OCZ, Samsung, Micron/Crucial. Stiamo parlando del 2011-2012.

Non mi risulta che la prima forma di nCache fosse stata creata per la mappatura. Che cosa stupida... gli ssd MLC avevano un bella DRAM che serviva solo a quello, e i TLC non sono diversi.
Mi spiega il tipo perchè comprimere in SLC una mappatura che stà bella bella su DRAM che è decine e decine di volte veloce e con meno latenza?
La versione perfezionata nCache 2.0 si trova schematizzata ancora in alcuni siti
https://www.legitreviews.com/sandisk...-review_150395
https://www.computerbase.de/artikel/....53025/seite-2
https://www.thessdreview.com/our-rev...-review-240gb/

E si, uno dei motivi per la creazione della cache emulata (nonostante il pensiero dell'autore) e che questa permette di mantenere le prestazioni degli ssd TLC (sata ovviamente... gli nvme non esistevano proprio) come quelli MLC (che saturavano la banda del sata stesso... oltre sarebbe stato assurdo fare).

Mo parto con lo spiegone...

Se si vuole proprio proprio fare una storia chiara sulla nCache, che NON E' proprio uguale alla pSLC a cui siamo ora abituati, si deve partire dal perchè viene "inventata".

Nascono gli ssd (sata) TLC e si nota che la scrittura ha prestazioni inferiori agli MLC.
Quindi non sarebbero ssd molto apprezzati, oltre al fatto che non è che costassero poi tanto meno degli ormai affermati MLC. Bisognava trovare il modo di "accelerare".
La causa della lentezza delle scritture su TLC è dovuta alla velocità minore di programmazione delle TLC, ma c'è un grosso, grosso problema che occorre affrontare: la maggiore amplificazione in scrittura che è concausa della durata inferiore dei dispositivi TLC.

L'idea della cache emulata già c'era ed è ulteriormente sviluppata. E' fantastica: Avere a bordo un po' di SLC per memorizzare i dati nella cache prima di scaricarli nella TLC riduce notevolmente l'amplificazione in scrittura e quindi la durata del disco risulta migliorata.

Ora il come: il processo nCache garantisce che tutti i dati vengano inizialmente scritti nei blocchi SLC prima di essere trasferiti alla TLC. Sandisk parla di "On Chip Copy" perchè si tratta di una porzione di celle/pagine/blocchi gestite dal die che vengono utilizzate in modo speciale.
Il "folded" cioè la piega, è la seconda fase del meccanismo di nCache (termine poi esteso a tutti gli effetti dell pSLC), cioè la copia su chip, da SLC a TLC. I blocchi TLC vengono quindi scritti in sequenza per ottimizzare l'amplificazione in scrittura. L'operazione di copia viene eseguita interamente all'interno della NAND, senza la necessità di utilizzare il controller o la DRAM.

Ricapitolando:
nCache è nato per le performance
nCache ha l'effetto di mitigare la WA
nCache utilizza blocchi specificatamente emultati e la gestione è a livello di die (quindi di chip)
nCache ha lo stato di folding come seconda fase del processo di cache emultata.

Vediamoquindi quando dici: "con nCache 2.0 qualsiasi scrittura veniva mandata in cache SLC comportando a del folding obbligatorio dopo l’esaurimento del buffer SLC e a poche scritture sulle NAND flash TLC. Poi, con le NAND flash TLC 3D che hanno visto miglioramenti sia in performance che durata, han deciso di introdurre (con nCache 3.0) le scritture “direct-to-TLC” in modo tale da indirizzare le scritture su NAND flash TLC dopo l’esaurimento del buffer SLC; così facendo non si fa per forza del folding".

La prima frase si matcha con il ricapitoliamo... anche se il folding, meglio dirlo, risulta sempre necessario nella nCache, perchè è la fase due del processo: Scrivo SLC --> copio in TLC

Ora stò leggendo quanto scritto dal tipo: "Oltre alle prestazioni di scrittura a 128K, è anche estremamente ovvio ottimizzare la struttura FTL: il semplice mantenimento della mappatura della cache SLC è molto più semplice dell'espansione completa del blocco fisico. Per quanto riguarda le prestazioni utente, la cache SLC può spesso ottenere il mapping a livello di blocco o addirittura di pagina senza la necessità di espandere nuovamente la tabella, e il miglioramento delle prestazioni che ne risulta è molto evidente: questo vale sia per le tecnologie dramless che per quelle drambased. A causa della mancanza di strategie di risparmio energetico e di protezione contro lo spegnimento, anche il modello di punta configurato a 1:1000 non riesce a ottenere lo stesso effetto di quello aziendale."

Penso che il tipo si sia pippato qualche cosa. Perchè farla così complicata?
Mappatura.. espansione.. ecc ecc.

Ma è semplice!
https://pics.computerbase.de/6/9/7/7....824971055.jpg
nCache funziona a livello di die... di chip.
Tutto ciò che entra nell'ssd nella maniera più grezza possibile, viene prima scritto in SLC e poi ricopiato sullo stesso die nella controparte di celle TLC.
In automatico, non serve il controller (occhio a questo che è il motivo per cui nCache ≠ pSLC).
E la mappatura - su DRAM - che fà?
Viene aggiornata di conseguenza.
Fold-set, il controller rimappa, raggruppando i dati memorizzati in 3 blocchi SLC “da svuotare” e li associa insieme in un unico blocco TLC già cancellato. Il controller invia poi il comando Erase sui 3 blocchi SLC originari, che tornano liberi per future scritture rapide.

Semplice, lineare, vincente...


Quando leggo dopo: "Per questo motivo, la cache SLC non è ottimizzata per 128K, come molti autodidatti incompetenti credono. ", mi viene solo da sorridere, perchè l'autore confondo la nCache 2.0 con la "nostra" pSLC.

Ripeto, nCache è "ignorante". Anche se entrasse un treno nell'ssd (tanto per dire un dato sequenziale da 1MiB, questo viene preso, scritto in SLC. Dopodichè... On‑Chip Copy - È una logica integrata direttamente all’interno del die NAND che permette di:
A) Leggere una word‑line (una pagina) e tenerla in latch interni
B) Riprogrommarla in un’altra pagina di destinazione sulla stessa die
il tutto senza passare dal bus verso il controller SSD né dalla DRAM del controller.
[Cit. Sandisk]


Ora, dopo aver smesso di ridere in faccia al tipo che dà degli incompetenti agli altri, ciccando il parallelo tra due cose diverse che hanno in comune la parola "cache", tornando alla sua dissertazione... intanto posto questo e poi domani continuo a leggermi da:

PARTE II Algoritmi SLC

2.1 Nella cache

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Mumble...mumble....

Cerchiamo di capire, Black, le conseguenze di questo approccio.

Immaginando un ssd nvme Renegade G5 pieno a oltre il 70% ed usato continuamente da un paio d'anni con dati statici/dinamici che hanno previsto cancellazioni e riscritture, questa programmazione, porta effettivamente qualche vantaggio per un utente domestico?

Questo approccio di cui parli l'ho notato già tempo fa con le sue recensioni sul PM9E1 (OEM del 9100 PRO), PCB01 (OEM del P51) e del 990 EVO Plus, semplicemente l'ho sempre ignorato perché non combacia con quello mostrato nelle recensioni degli altri recensori. Nel senso che Tom's Hardware non mostra alcun folding per il 9100 PRO e per il 990 EVO Plus, se HOMOLAB lo fa mi viene da pensare che abbia una configurazione di test molto diversa rispetto ai recensori a cui noi siamo abituati a consultare oppure che lui sbaglia qualcosa con i test stessi. In ogni caso, rispondendo a "porta effettivamente qualche vantaggio per un utente domestico?", io penso che fare del folding prima delle scritture direct-to-TLC porti a un minor WAF. Due motivi per questo:
1) il folding in sé è la compressione di 3 blocchi SLC in 1 TLC e questa è un'operazione sequenziale [1]. Tante scritture di questo tipo (ossia sequenziali) riempiono sequenzialmente un blocco e un blocco sequenziale non necessita di tutte le operazioni di lettura, cancellatura, modifica e scritture che fa il GC con un blocco scritto randomicamente [2], quindi le scritture e i blocchi sequenziali hanno un WAF più basso rispetto a quelle/i randomiche;
2) se ci pensi, per arrivare a fare delle scritture direct-to-TLC dopo il folding devi consumare in primo step tutta la cache SLC che tipicamente è di 200+GB (è un numero generale, poi ci sono SSD e SSD) e poi devi superare tutto lo stadio di folding che non so di quanti GB è fatto (sicuro non di pochi). Penso che l'utente debba trasferire una quantità di dati ingente per arrivare alle scritture direct-to-TLC dopo tutto questo e visto il vantaggio del WAF più basso tanto vale far consumare il meno possibile le celle NAND flash.

Tu dopo questo ragionamento potrai dirmi "sì ma così hai performance più basse", vero e non ti do contro, non c'è alcuna positività per la velocità dell'SSD, ma non mi vengono in mente altri motivi per i quali fare folding prima di scritture in direct-to-TLC.

Originariamente inviato da @Liupen

Ora, dopo aver smesso di ridere in faccia al tipo che dà degli incompetenti agli altri, ciccando il parallelo tra due cose diverse che hanno in comune la parola "cache", tornando alla sua dissertazione...

Beh non ho molto da dire Liupen, alla fine hai spiegato in modo molto più esteso e dettagliato la parte sopra del mio messaggio (che l'ho scritta prima di leggere il tuo ultimo commento) e ovviamente son d'accordo su tutto. Folding alla fine è una scrittura on-die e on-chip-copy, quindi i blocchi SLC sono catalogati in un foldset, poi questi blocchi SLC vengono compressi in TLC nel foldset dei blocchi TLC.

Son d'accordo anche su quanto hai detto a riguardo di "Mappatura.. espansione.. ecc ecc.". Quando lessi la prima volta quel pezzo di testo dissi "deve aver sbagliato qualcosa la traduzione, non ha senso sta roba. Fammi provare a tradurre in italiano..."... e indovina? Anche lì non aveva senso, quindi ho pensato "o fa schifo la traduzione dal cinese oppure lui ha messo in mezzo cose che non c'entrano nulla, o che perlomeno non sono documentate da nessuno", quindi ho provato a prendere il buono e buttarlo giù come punto interessante (secondo punto del post originario).

Unica cosa, questo:

Originariamente inviato da @Liupen

Non mi risulta che la prima forma di nCache fosse stata creata per la mappatura.

Proviene da qui, dalla prima recensione dell'SN750 di AnandTech. Di AnandTech mi fidavo molto, quindi non son sicuro che sia una cavolata quello scritto da loro/HOMOLAB, magari la fonte è vecchia e ora le cose son cambiate, non so.

[pitx]

Black, ma allo stato attuale S-Ata con controller Marvell, che cosa c'è?

E per un 512GB o 1TB sempre S-Ata, che consigliate?

[Black (Wooden Law)]

Originariamente inviato da pitx

Black, ma allo stato attuale S-Ata con controller Marvell, che cosa c'è?

E per un 512GB o 1TB sempre S-Ata, che consigliate?

Ti interessa un SSD con controller Marvell per qualche motivo specifico? Con controller Marvell mi viene in mente soltanto l'NS100 (che comunque soffre di bait-and-switch ed è stato avvistato con controller MAS1102B) che usa l'88NV1120 (fascia bassa), altrimenti nessuno se non i vecchi SATA WD: WD Blue 3D, SA500, ecc. Loro usano l'antichissimo (ma buono) 88SS1074 che comunque è sempre stato un buon rivale dell'eccellente SM2258 dell'MX500.

Generalizzando su modelli che consiglio rimangono gli stessi della prima pagina: MX500, 870 EVO e A55. Magari anche il BX500 ma con quest'ultimo corri maggiormente il rischio che ti capiti QLC secondo me.

[pitx]

Originariamente inviato da Black (Wooden Law)

un buon rivale dell'eccellente SM2258 dell'MX500.

Generalizzando su modelli che consiglio rimangono gli stessi della prima pagina: MX500, 870 EVO e A55. Magari anche il BX500 ma con quest'ultimo corri maggiormente il rischio che ti capiti QLC secondo me.

Più per sfizio il marvell... doveva averlo il Sandisk SSD PLUS(con SN2256S), doveva averlo il Lexar NS100 (ho 2x 128GB, 2x 256GB e tutti col Maxio)
Un SM2258 ce l'ho sul Drevo X1 Pro da 64GB

A55?

[Black (Wooden Law)]

Originariamente inviato da pitx

A55?

Ha più versioni di controller e NAND flash, io come controller ho visto S11, SM2259XT e MAS1102 mentre come NAND flash di tutto di più, sia TLC che QLC e dalle 64L alle 232L.

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Questo approccio di cui parli l'ho notato già tempo fa con le sue recensioni sul PM9E1 (OEM del 9100 PRO), PCB01 (OEM del P51) e del 990 EVO Plus, semplicemente l'ho sempre ignorato perché non combacia con quello mostrato nelle recensioni degli altri recensori. Nel senso che Tom's Hardware non mostra alcun folding per il 9100 PRO e per il 990 EVO Plus, se HOMOLAB lo fa mi viene da pensare che abbia una configurazione di test molto diversa rispetto ai recensori a cui noi siamo abituati a consultare oppure che lui sbaglia qualcosa con i test stessi. In ogni caso, rispondendo a "porta effettivamente qualche vantaggio per un utente domestico?", io penso che fare del folding prima delle scritture direct-to-TLC porti a un minor WAF. Due motivi per questo:
1) il folding in sé è la compressione di 3 blocchi SLC in 1 TLC e questa è un'operazione sequenziale [1]. Tante scritture di questo tipo (ossia sequenziali) riempiono sequenzialmente un blocco e un blocco sequenziale non necessita di tutte le operazioni di lettura, cancellatura, modifica e scritture che fa il GC con un blocco scritto randomicamente [2], quindi le scritture e i blocchi sequenziali hanno un WAF più basso rispetto a quelle/i randomiche;
2) se ci pensi, per arrivare a fare delle scritture direct-to-TLC dopo il folding devi consumare in primo step tutta la cache SLC che tipicamente è di 200+GB (è un numero generale, poi ci sono SSD e SSD) e poi devi superare tutto lo stadio di folding che non so di quanti GB è fatto (sicuro non di pochi). Penso che l'utente debba trasferire una quantità di dati ingente per arrivare alle scritture direct-to-TLC dopo tutto questo e visto il vantaggio del WAF più basso tanto vale far consumare il meno possibile le celle NAND flash.

Tu dopo questo ragionamento potrai dirmi "sì ma così hai performance più basse", vero e non ti do contro, non c'è alcuna positività per la velocità dell'SSD, ma non mi vengono in mente altri motivi per i quali fare folding prima di scritture in direct-to-TLC.

Ah ecco, è una cosa legata al suo test.. si, magari le impostazioni fio usate possono determinare comportamenti diversi. Aspetteremo dunque l'analisi di THW.
Se riesci linka la recensione di questo recensore cinese del 9100 PRO così mi faccio un idea delle differenze dello stato stazionario trovato rispetto a https://www.tomshardware.com/pc-comp...o-ssd-review/2

L'analisi che hai fatto mi piace, la condivido (il punto 2, perchè l'1 è comunque comune ad entrambe le modalità di gestione).
Penso che sia un ssd che giochi molto sulla grandezza della cache pSLC...anzi che dia tutto per la cache pSLC, dopodichè il crollo. Dai, vediamo che diranno le future recensioni.

Originariamente inviato da Black (Wooden Law)

Beh non ho molto da dire Liupen, alla fine hai spiegato in modo molto più esteso e dettagliato la parte sopra del mio messaggio (che l'ho scritta prima di leggere il tuo ultimo commento) e ovviamente son d'accordo su tutto. Folding alla fine è una scrittura on-die e on-chip-copy, quindi i blocchi SLC sono catalogati in un foldset, poi questi blocchi SLC vengono compressi in TLC nel foldset dei blocchi TLC.

Son d'accordo anche su quanto hai detto a riguardo di "Mappatura.. espansione.. ecc ecc.". Quando lessi la prima volta quel pezzo di testo dissi "deve aver sbagliato qualcosa la traduzione, non ha senso sta roba. Fammi provare a tradurre in italiano..."... e indovina? Anche lì non aveva senso, quindi ho pensato "o fa schifo la traduzione dal cinese oppure lui ha messo in mezzo cose che non c'entrano nulla, o che perlomeno non sono documentate da nessuno", quindi ho provato a prendere il buono e buttarlo giù come punto interessante (secondo punto del post originario).

Unica cosa, questo:

Proviene da qui, dalla prima recensione dell'SN750 di AnandTech. Di AnandTech mi fidavo molto, quindi non son sicuro che sia una cavolata quello scritto da loro/HOMOLAB, magari la fonte è vecchia e ora le cose son cambiate, non so.

Come la nCache è simile ma non la stessa cosa della pSLC, anche il folding ha assunto poi connotazioni diverse.

Inizialmente era la riscrittura dalla porzione di celle emulate SLC a TLC, stop, non avveniva direct-to write, ora è un insieme di cose, ecco perchè spesso si definisce: "stato di folding".

Il controller dell'ssd (nvme) attuale, in scrittura assidua e spazio libero ristretto (praticamente la normalità se si usa un ssd con qualche scrittura pesante), finita la cache pSLC disponibile, inizia a fare diverse cose in contemporanea:
- scrive in direct-to per continuare la scrittura ordinata dall'host
- sposta le pagine per liberare blocchi e predisporsi alla scrittura (GC)
- copia (sequenzialmente come scrivi su) il contenuto delle celle SLC in formato TLC (su ovviamente nuove celle che sono ovviamente ancora diverse da quelle del punto precedente)
- erase sulle celle emulate SLC
- creazione di nuovo spazio pSLC

Questo è lo stato di folding, che coincide con il massimo impegno del controller e dunque le prestazioni più basse dell'ssd in scrittura.

In seguito, continuando a scrivere in direct-to, con nuova cache pSLC libera, si vede l'impennata di prestazioni, fino a riempimento cache e così via... in un loop gestito chi meglio, chi peggio dal controller.
Questa fase è quasi sempre definita come "stato stazionario" (steady‑state) perchè è l'equilibrio definito dalla programmazione del controller, in cui c'è sia scrittura diretta, che scrittura su cache pSLC in un continuo riempi/copia/svuota.

Riguardo la mappatura in nCache, hai ragione, ho letto Anandtech... riporta proprio quello, parola per parola come hai scritto.

Dovendo capire, quindi, sono andato a prendere una scheda di un vecchio ssd Sandisk 2010 SSD Sandisk P4 sata II (300) https://datasheet.octopart.com/SDSA4...t-10977758.pdf in cui è implementata la nCache originale.

Spoiler:

La terza generazione di SSD modulari, l'SSD P4, supporta una funzionalità unica per migliorare le prestazioni di scrittura casuale e garantire un'esperienza utente estremamente positiva. Gli studi dimostrano che i sistemi operativi moderni accedono principalmente al dispositivo di archiviazione utilizzando piccoli blocchi di accesso, la maggior parte dei quali da 4 KB. I piccoli blocchi di accesso logico sono in conflitto con la struttura a blocchi fisici (>1 MB) della tecnologia di memoria flash di nuova generazione. Pertanto, per colmare questa differenza, l'SSD P4 utilizza una cache di scrittura Flash SLC non volatile, nCache™. nCache™ viene utilizzata per accumulare queste piccole scritture (chiamate segmenti) ad alta velocità e quindi scaricarle e consolidarle in background in una sezione MLC più grande della matrice di memoria Flash NAND durante i periodi di inattività. La dimensione della cache dell'SSD P4 è di oltre 500 MB, un ordine di grandezza superiore rispetto ad altre soluzioni concorrenti che utilizzano cache basate su DRAM. La dimensione della cache varia in base alla capacità. Per il prodotto da 32 GB, la dimensione della cache è di oltre 500 MB. Grazie alle sue grandi dimensioni, per la maggior parte dell'attività giornaliera degli utenti, nCache non va mai in overflow e gli utenti finali sperimentano elevate prestazioni SLC burst piuttosto che prestazioni sostenute. Una volta che nCache si riempie, le prestazioni dell'SSD P4 scendono fino a raggiungere la condizione di stato stazionario. Inoltre, nCache è una cache non volatile e quindi non è esposta a perdite di dati. Per evitare qualsiasi perdita di dati durante la rimozione dell'alimentazione (con Host Write Cache disabilitata), il tempo necessario alla tensione di ingresso per scendere dal valore nominale a 2 V deve essere di almeno 5 ms.

Non c'è la DRAM e la FTL per forza è fatta risiedere nella SRAM. Il datasheet dell'ssd NON parla di mappatura presente nella nCache.
Mi tocca bacchettare Anandtech
E' chiaro che sono ssd sperimentali e diversi da quelli moderni costituiti da Controller/DRAM/NAND.

Però grazie Black. Si impara sempre. Tipo non sapevo ci fossero ai tempi ssd privi di DRAM.


Ora proseguo nella lettura di https://freewechat.com/a/MzkzMjYyNDU4Mg==/2247484816/1
Chiaramente se prima mi ha confuso la nCache con la pSLC nel proseguo del testo considererà la cache SLC moderna... vediamo se dice le cose correttamente...

Inizia con il classico grafico dell'andamento della scrittura continuata su tutta la capienza dell'ssd, accompagnata da questa frase: "Parliamo innanzitutto di una situazione estremamente ideale: in questo mondo non esiste la scrittura casuale 4K e tutti i flussi IO sono blocchi sequenziali e di grandi dimensioni. Anche se è ridicolo, credetemi, dobbiamo costruire questo modello scandaloso e ridicolo prima di poter iniziare la discussione. ".

Se lo avessi davanti gli (o Le, magari è una ragazza nerd) direi che si è fermato alla superficie.
Vero che (lo dice anche THW nelle sue recensioni), il riempire con blocchi sequenziali un ssd da cima a fondo NON è un uso comune anzi è proprio stolkerare un ssd, ma
1) serve ovviamente a mettere in evidenza una cache di scrittura che altrimenti non si vedrebbe
ma sopratutto
2) un ssd pieno a 70-75% con buchi da cancellazione come un groviera (quindi un ssd "normale") si comporterebbe proprio così... mettendo sia in evidenza la cache, sia la scrittura diretta e lo stato di folding, quando usato un po più pesantemente.


proseguiamo.. cache SLC fissa VS simulazione del disco pieno (?)

Ah ok. cache fissa vs cache dinamica.
Spiegata discretamente, dai... più che altro perde l'ottica "evolutiva". Nel senso che non è una scelta tra le due... prima nasce la cache statica (nel senso che la pSLC essendo una funzione software, nasce creando un algoritmo che dedica in certo spazio fisso di celle emulabili, proprio come faceva nCache).
Poi (qualche anno dopo) con il progredire della capacità di programmazione, l'idea diventa di progettare e realizzare una pSLC dinamica dove il controller possa decidere la quantità variabile di spazio da dedicare alla cache di scrittura. Questa è la pSLC attuale, quella del concetto di folding esteso.

Una frase: " la cache SLC, troppo piccola, non riesce a coprire lo spazio richiesto dagli scenari applicativi moderni ed è inutile se non per accelerare i punti di esecuzione CDM e ASSSD; non risolve il problema delle perdite extra causate dall'espansione FTL in scenari complessi. Con lo sviluppo e il progresso della tecnologia, il mercato ha gradualmente smesso di riconoscere questo modello, per questo è emerso l'algoritmo full disk. ".

L'espansione della FTL (caro ragazzo o ragazza) è un non problema.
Quando la FTL (cioè la mappatura + tutti gli algoritmi di gestione) si espande oltre un certo limite (32 o 64 MB), si verifica (il parallelo può essere la paginazione di windows) un trasferimento di porzioni di FTL non modificate su Nand e il mantenimento della porzione di FTL variabile in DRAM (o RAM... ecco il perchè dei 32 MB).

Quindi in motivo per cui nel mercato si è affermata poi la pSLC dinamica (full disk viene chiamata da lui), è perchè si è ottimizzato l'algoritmo secondo le necessità degli usi consumer... reali (utilizzo base di nvme) e di marketing (i numeroniiii!!).

Scrive: "Ma l'algoritmo SLC full-disk non è onnipotente. Poiché tutti i blocchi rimanenti vengono convertiti in modalità SLC, dopo il burst del buffer, i dati nella cache SLC devono essere rilasciati durante la scrittura sui blocchi TLC: questa è la penalità di writeback. In questo momento, l'SSD deve affrontare un gran numero di letture e scritture REW, quindi possiamo vedere chiaramente che la velocità è diminuita in modo significativo: la velocità di scrittura diretta TLC dell'SN580 è di 1400 MB/S e la penalità di scrittura inversa è di soli 545 MB/S. Questa strategia rappresenta quindi un compromesso."

Grande verità. Più gli ssd attuali hanno una cache di scrittura dinamica grande, meno sono adatti a carichi di lavoro pesante.

2,2 fuori dalla cache

Ma guarda un po...questo è interessante, lo lascio per domani

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Se riesci linka la recensione di questo recensore cinese del 9100 PRO così mi faccio un idea delle differenze dello stato stazionario trovato rispetto a https://www.tomshardware.com/pc-comp...o-ssd-review/2

È qui la recensione del PM9E1 Liupen. Qui invece tutte le recensioni fatte finora da lui.

Originariamente inviato da @Liupen

Dai, vediamo che diranno le future recensioni.

Sì, alla fine mi piace HOMOLAB per le sue recensioni ma ho scoperto di doverle prendere con le pinze per i risultati tutti unici a sé.

Originariamente inviato da @Liupen

Inizialmente era la riscrittura dalla porzione di celle emulate SLC a TLC, stop, non avveniva direct-to write, ora è un insieme di cose, ecco perchè spesso si definisce: "stato di folding".

Il controller dell'ssd (nvme) attuale, in scrittura assidua e spazio libero ristretto (praticamente la normalità se si usa un ssd con qualche scrittura pesante), finita la cache pSLC disponibile, inizia a fare diverse cose in contemporanea:
- scrive in direct-to per continuare la scrittura ordinata dall'host
- sposta le pagine per liberare blocchi e predisporsi alla scrittura (GC)
- copia (sequenzialmente come scrivi su) il contenuto delle celle SLC in formato TLC (su ovviamente nuove celle che sono ovviamente ancora diverse da quelle del punto precedente)
- erase sulle celle emulate SLC
- creazione di nuovo spazio pSLC

Questo è lo stato di folding, che coincide con il massimo impegno del controller e dunque le prestazioni più basse dell'ssd in scrittura.

Capisco Liupen, quindi tu dici che il folding è soltanto la compressione dei blocchi SLC in TLC ma folding più le scritture su NAND flash TLC, lettura e cancellazione dei blocchi SLC, copia dei foldset da SLC a TLC e quant'altro è stato di folding. Mi verrebbe da dire che sia una distinzione non molto conosciuta, nel senso che non tutti fanno questa differenza ma ha assolutamente senso.

Riguardo la mappatura in nCache, hai ragione, ho letto AnandTech... riporta proprio quello, parola per parola come hai scritto.

Originariamente inviato da @Liupen

Dovendo capire, quindi, sono andato a prendere una scheda di un vecchio ssd Sandisk 2010 SSD Sandisk P4 sata II (300) https://datasheet.octopart.com/SDSA4...t-10977758.pdf in cui è implementata la nCache originale.

Per questa parte penso che il ragionamento di AnandTech sia stato: "nel datasheet c'è scritto che i tipici blocchi di un SO sono da 4kB mentre quelli fisici di un SSD sono da più di 1MB. Data questa incongruenza che porta a un peggioramento di performance SanDisk ha deciso di creare la nCache per ricevere tutte le scritture 4kB" ma no, non ha scritto proprio questo. In realtà io non darei proprio per scontato che nel datasheet si intenda che nCache riceva le scritture 4kB, secondo me SanDisk voleva dire "nCache è fatta per migliorare le performance generali dell'SSD in scrittura viste le basse performance di quelle 4kB". Magari le scritture 4kB non erano "basse", ma sicuramente peggiori rispetto ad avere un rapporto 1:1 di dimensioni LBA-PBA.

Ha senso secondo te? Comunque sì, la mappa L2P non c'entra assolutamente nulla...

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Capisco Liupen, quindi tu dici che il folding è soltanto la compressione dei blocchi SLC in TLC ma folding più le scritture su NAND flash TLC, lettura e cancellazione dei blocchi SLC, copia dei foldset da SLC a TLC e quant'altro è stato di folding. Mi verrebbe da dire che sia una distinzione non molto conosciuta, nel senso che non tutti fanno questa differenza ma ha assolutamente senso.

Per questa parte penso che il ragionamento di AnandTech sia stato: "nel datasheet c'è scritto che i tipici blocchi di un SO sono da 4kB mentre quelli fisici di un SSD sono da più di 1MB. Data questa incongruenza che porta a un peggioramento di performance SanDisk ha deciso di creare la nCache per ricevere tutte le scritture 4kB" ma no, non ha scritto proprio questo. In realtà io non darei proprio per scontato che nel datasheet si intenda che nCache riceva le scritture 4kB, secondo me SanDisk voleva dire "nCache è fatta per migliorare le performance generali dell'SSD in scrittura viste le basse performance di quelle 4kB". Magari le scritture 4kB non erano "basse", ma sicuramente peggiori rispetto ad avere un rapporto 1:1 di dimensioni LBA-PBA.

Ha senso secondo te? Comunque sì, la mappa L2P non c'entra assolutamente nulla...

Beh, non sono io che lo dico, sono terminologie che si usano nelle review.

Write Back, credo sia il termine tecnico corretto dal punto di vista accademico, ma ci hanno abituati a questo:

Official write specifications are only part of the performance picture. Most SSDs implement a write cache, which is a fast area of pseudo-SLC (single-bit) programmed flash that absorbs incoming data. Sustained write speeds can suffer tremendously once the workload spills outside of the cache and into the "native" TLC (three-bit) or QLC (four-bit) flash. Performance can suffer even more if the drive is forced to fold, which is the process of migrating data out of the cache in order to free up space for further incoming data.
We use Iometer to hammer the SSD with sequential writes for over 15 minutes to measure both the size of the write cache and performance after the cache is saturated. We also monitor cache recovery via multiple idle rounds. This process shows the performance of the drive in various states as well as the steady state write performance.
The 2TB CS2150 writes in the single-bit SLC mode at an average of almost 8.9 GB/s for about 50 seconds, indicating a 435GB cache. This is a large cache but by no means as large as it could be given the size of the drive. A smaller cache allows for a higher middle performance state, in this case a three-bit TLC mode that writes at around 2.15 GB/s. Finally, once the cache is completely full and needs to be emptied to allow access to the full drive capacity, that forces the drive to enter the slowest “folding” state. Here the drive writes at an average of 708 MB/s while juggling data.

https://www.tomshardware.com/pc-comp...b-ssd-review/2

Fold: il processo di migrazione dei dati dalla cache per liberare spazio per ulteriori dati in ingresso
folding state: quando la cache è completamente piena e deve essere svuotata per consentire l'accesso all'intera capacità dell'unità, questa entra nello stato di "folding" più lento.

Cioè nel caso del “folding state” degli SSD, il termine non indica solo “piega” (per dire cache piena e copia su cella nativa) ma l’insieme delle attività — direct-to-write, garbage collection, flush pSLC, erase e ricreazione di cache — che il controller porta avanti contemporaneamente, raggiungendo il throughput minimo e segnando la fase di passaggio tra burst di velocità e ritorno allo stato di equilibrio della cache.

Tanto per creare un esempio parallelo sarebbe come dire "stallo" aerodinamico cioè la perdita di portanza e "stato di stallo" cioè gli effetti (perdita di controllo e oscillazioni.).

citazioni degli illustri
https://linustechtips.com/topic/1269...mment-14213987
https://www.techpowerup.com/forums/t...4/post-5393322

--------------

Ha senso secondo me quando dici "nCache è fatta per migliorare le performance generali dell'SSD in scrittura viste le basse performance di quelle 4kB" è un escamotage per la velocità. Chi lo sà, magari all'inizio pensavano (vedi gli hdd) che la sola SRAM del controller fosse sufficiente a tenere la mappatura e la loro base era questa; quindi aveva senso trovare dei "trucchi" per migliorare le prestazioni utilizzando ciò che si aveva a disposizione, cioè le nand. Poi qualcun altro ha introdotto la DRAM nel sistema dell'ssd e allora la nCache è diventata altro. E' un ipotesi, chissà.
L'altra ipotesi, e mi pare più attinente, più giusta, e che la preoccupazione di questi tecnici fosse all'inizio la durata degli ssd. Hai visto che il P4 va da 8GB a 128GB. Figurati con gli algoritmi rudimentali di allora quanti TBW avevano. nCache è stata una trovata geniale per abbassare la WA e far durare più a lungo l'ssd.
Infatti in principio (vuoi per le prestazioni, vuoi per abbassase il WAF) è alla base anche degli ssd attuali.

[Black (Wooden Law)]

Originariamente inviato da @Liupen

nCache è stata una trovata geniale per abbassare la WA e far durare più a lungo l'ssd.
Infatti in principio (vuoi per le prestazioni, vuoi per abbassase il WAF) è alla base anche degli ssd attuali.

Però nCache (mettendo caso che fosse lo stesso della cache SLC dinamica) con folding va in contrasto con l’aumento del WAF dovuta dal fatto che prima si scrive in SLC e poi in MLC. Quindi non so, magari c’è una riduzione ma lieve, boh.

Dynamic write acceleration may contribute to WAF because data may first be written as SLC and later be rewritten as MLC.

(Fonte)

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Però nCache (mettendo caso che fosse lo stesso della cache SLC dinamica) con folding va in contrasto con l’aumento del WAF dovuta dal fatto che prima si scrive in SLC e poi in MLC. Quindi non so, magari c’è una riduzione ma lieve, boh.

(Fonte)

Diciamo che l'aspetto positivo della nCache è anche quello della pSLC pur essendo (ci tengo a dirlo nuovamente) due cose diverse.

Anche quà dice la stessa cosa, cioè che pSLC fà aumentare l'amplificazione di scrittura.
https://en.wikipedia.org/wiki/Write_amplification


Tuttavia non sono convinto, perchè WAF rappresenta un elemento assai importante (endurance ssd); non posso pensare a ssd QLC e PLC che vengono penalizzati nella TBW sull'altare delle prestazioni.
Quindi o la pSLC non influisce (va a pari se non migliora la WAF) oppure la peggiora ma in senso trascurabile.

Ci devo ragionare su...

La prima ipotesi trae spunto dalla nCache
La ri-scrittura o copia o fold avviene sequenzialmente su una porzione di celle corrispettive a quelle emulate ma in maniera organizzata, specie dati casuali (4KB). In questo caso la maggiore scrittura (copia celle SLC in TLC/QLC) viene mitigata o cambia di segno, per merito della migliore organizzazione delle pagine di celle native e dei relativi blocchi.

Proviamo un ragionamento deduttivo diverso.

Visto che maggiore è il fattore di amplificazione in scrittura, maggiore è la larghezza di banda occupata dal traffico in background (e peggiori sono le prestazioni del dell'SSD), la chiave è la riduzione del GC in background.
La pSLC per ridurre la WAF fà questo?

Si ci sono degli elementi ma, non sono in grado di dire che peso hanno

1) come per la nCache i dati casuali 4KB subiscono un fold sequenziale che li compatta. Più i dati sono compatti meno lavoro di CG in background si fà
2) la densità dei dati è migliore anche a livello di blocchi e quando il controller deve fare un erase si trova meno blocchi sparsi. Anche questo elemento migliora la WAF
3) ogni ciclo di GC sposta sia dati “caldi” sia “freddi” (wear-leveling), mentre il flush pSLC sposta solo pagine “hot” con conseguente netta riduzione del traffico totale se il carico è fortemente random

[Black (Wooden Law)]

Notizie su Sandisk: il primo report da quando ha “lasciato” WD è in negativo con i ricavi di 0,6% in meno anno per anno, 21% in meno trimestre per trimestre sul datacenter e 10% in meno (sempre trimestre per trimestre) sui prodotti consumer. Nonostante ciò, il CEO non è assolutamente deluso:

Sono soddisfatto dell'esecuzione del nostro team nel primo trimestre come azienda autonoma. L'innovazione di Sandisk è stata rafforzata con una forte rampa iniziale di BiCS8, la nostra ultima tecnologia progettata per offrire prestazioni leader del settore, efficienza energetica e densità.

Altri punti interessanti dell’articolo sono:

Goeckeler [il CEO] ha detto che la sua BiCS8 218-layer 3D NAND tecnologia sta producendo 2 Tbit QLC chip e questi sono "in qualifica con i migliori fornitori di servizi cloud per l'uso in SSD 128 terabyte e 256 terabyte." Ha menzionato i collegamenti PCIe Gen 5 e 6 per le unità QLC e pensa che il prodotto da 256TB potrebbe arrivare nel corso del prossimo anno, ovvero 2026.

E

C'è anche un nuovo controller SSD in arrivo.
"Abbiamo una nuova architettura in uscita nel prossimo paio di quarti che chiamiamo Stargate, nuovo ASIC [controller], disegno a foglio bianco e poi con BiCS8 QLC ... pensiamo che sarà un progetto dinamico", ha detto Goeckeler.

Fa anche piacere sentir dire che i dazi imposti da Trump non colpiscano esageratamente gli introiti:

Al momento, non ci sono dazi sui nostri prodotti tranne per le spedizioni dalla Cina agli Stati Uniti, che hanno tariffe del 27,5%. Per avere una prospettiva, circa il 20% dei nostri prodotti spediti negli Stati Uniti e oltre il 95% di quel reddito proviene da paesi diversi dalla Cina."

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Diciamo che l'aspetto positivo della nCache è anche quello della pSLC pur essendo (ci tengo a dirlo nuovamente) due cose diverse.

Anche quà dice la stessa cosa, cioè che pSLC fà aumentare l'amplificazione di scrittura.
https://en.wikipedia.org/wiki/Write_amplification


Tuttavia non sono convinto, perchè WAF rappresenta un elemento assai importante (endurance ssd); non posso pensare a ssd QLC e PLC che vengono penalizzati nella TBW sull'altare delle prestazioni.
Quindi o la pSLC non influisce (va a pari se non migliora la WAF) oppure la peggiora ma in senso trascurabile.

Ci devo ragionare su...

La prima ipotesi trae spunto dalla nCache
La ri-scrittura o copia o fold avviene sequenzialmente su una porzione di celle corrispettive a quelle emulate ma in maniera organizzata, specie dati casuali (4KB). In questo caso la maggiore scrittura (copia celle SLC in TLC/QLC) viene mitigata o cambia di segno, per merito della migliore organizzazione delle pagine di celle native e dei relativi blocchi.

Proviamo un ragionamento deduttivo diverso.

Visto che maggiore è il fattore di amplificazione in scrittura, maggiore è la larghezza di banda occupata dal traffico in background (e peggiori sono le prestazioni del dell'SSD), la chiave è la riduzione del GC in background.
La pSLC per ridurre la WAF fà questo?

Si ci sono degli elementi ma, non sono in grado di dire che peso hanno

1) come per la nCache i dati casuali 4KB subiscono un fold sequenziale che li compatta. Più i dati sono compatti meno lavoro di CG in background si fà
2) la densità dei dati è migliore anche a livello di blocchi e quando il controller deve fare un erase si trova meno blocchi sparsi. Anche questo elemento migliora la WAF
3) ogni ciclo di GC sposta sia dati “caldi” sia “freddi” (wear-leveling), mentre il flush pSLC sposta solo pagine “hot” con conseguente netta riduzione del traffico totale se il carico è fortemente random

Diciamo che hai esposto un bel dilemma. Effettivamente non ci avevo pensato, ma c’è un aumento e una riduzione del WAF allo stesso momento poiché vengono effettuate più scritture ma vengono anche organizzati meglio i blocchi di dati. Non ho prove numerate sull’aumento del WAF esposto da Micron nel suo PDF, ricordo solo una volta di un brevetto di Intel che disse che la media è di 0,4 ma che è fortemente dipendente dal workload e dal carico in background del controller. Mi sa che qualcuno con un decennio di esperienza si deve mettere a testare ed elaborare…

Originariamente inviato da @Liupen

non posso pensare a ssd QLC e PLC che vengono penalizzati nella TBW sull'altare delle prestazioni.

Se può rassicurare Intel nel PDF delle 192L PLC ha detto di aver sviluppato un codice Gray che alzava l’endurance della cache SLC statica fino a 250.000 PEC. Ovvio che è cache SLC statica, non la diffusissima dinamica…

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Diciamo che hai esposto un bel dilemma. Effettivamente non ci avevo pensato, ma c’è un aumento e una riduzione del WAF allo stesso momento poiché vengono effettuate più scritture ma vengono anche organizzati meglio i blocchi di dati. Non ho prove numerate sull’aumento del WAF esposto da Micron nel suo PDF, ricordo solo una volta di un brevetto di Intel che disse che la media è di 0,4 ma che è fortemente dipendente dal workload e dal carico in background del controller. Mi sa che qualcuno con un decennio di esperienza si deve mettere a testare ed elaborare…



Se può rassicurare Intel nel PDF delle 192L PLC ha detto di aver sviluppato un codice Gray che alzava l’endurance della cache SLC statica fino a 250.000 PEC. Ovvio che è cache SLC statica, non la diffusissima dinamica…

Che poi nello stesso pdf, frase dopo dice che non è certo dell'aumento

Potrei realizzare un modello grafico anche perchè non saprei come iniziare a inibile la cache di scrittura in un nvme.
Dillo a Gabriel che ste cose le sa fare