[@Liupen]

Originariamente inviato da Black (Wooden Law)

Perché se il rapporto è 1:1000 dati gli indirizzi a 32-bit, 1GB di DRAM è necessario per una mappa L2P di 1TB di SSD, 2GB di DRAM per 2TB di SSD e così via. Tu puoi anche mettere 500MB di DRAM in un SSD da 8TB ma non viene fatto perché inefficiente semplicemente.

Facciamo un attimo i calcoli con 1TB di SSD e una dimensione dei settori di 4kB (la dimensione più comune solitamente):
- 1TB = 1.000.000.000 (un miliardo) di kB;
- 1.000.000.000 kB / 4 kB = 250.000.000 (250 milioni) di settori;
Assumendo che 4 byte (32-bit) siano necessari per convertire una pagina logica (LBA) in una fisica (PBA), moltiplicando il numero dei settori per la capacità necessaria di una conversione L2P trovi la capacità necessaria della DRAM per memorizzare la mappa L2P dell’SSD. In questo caso: 250.000.000•4 = 1.000.000.000 (1 miliardo) di byte, ergo 1GB. Adesso capisci quindi che se vuoi rendere la DRAM utile nell’SSD è importante che non sia né sovradimensionata né sottodimensionata perché nel primo caso parte della sua capacità non sarebbe utilizzata e tu come produttore avresti speso più soldi inutilmente mentre nel secondo caso avresti risparmiato soldi facendo più scritture sulle NAND flash dato l’inadeguato rapporto DRAM-mappa L2P.

Tu devi pensare che i produttori non pensano “mettiamo un chip più grande perché così porta a più performance (anche perché non lo fa)” ma “mettiamo un chip più grande perché necessario”.

P.S.: le formule le ho prese da pagina 131 di A Beginner’s Guide to SSD Firmware: Designing, Optimizing, and Maintaining SSD Firmware di Gopi Kuppan Thirumalai

Ottimo!

Originariamente inviato da Black (Wooden Law)

36GB, non so se abbia impattato i risultati questa cosa. Comunque anch'io l'ho letto volo perché ho rispolverato i miei paper salvati nel mio PC stanotte ma oggi me lo rivedo per bene.

si 36GB di ssd
Considera che è una simulazione, per quanto veritiera i risultati sono teorici.


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

Stamattina ho letto un po di cose sul HMB e mi sono chiarito un po di dubbi; in realtà accorgendomi che HMB è quel che è ed era ignoranza mia CONFONDERE la differenza tra buffer e caching.

Due nozioni prese dal documento ufficiale NVME:
- l'uso e la quantità di RAM da utilizzare per l'HMB è stabilita dal controller dell'ssd ed in teoria può essere impostata di interi GB; condizione fondamentale è che si imposti un minimo e un massimo, pena errori (ops! fischiano le orecchie a WD).
- le risorse di memoria RAM non sono persistenti attraverso un evento di reset del controller. Dopo un reset, il sistema operativo riassegna la memoria vuota precedentemente allocata al controller.

L'elemento (algritmo) che in HMB si occupa della scrittura è il Fast Write Buffer (FWB).


Domande e risposte.


1) HMB migliora le prestazioni di lettura casuale rispetto ad un ssd nvme che ha la DRAM?

No, non è possibile; al massimo và alla stessa velocità.
Perchè? La lettura dei riferimenti di mappatura da RAM o da DRAM hanno una latenza trascurabile in entrambe i casi.


2) Quantità maggiore di memoria su RAM di sistema opzionata da HMB rende l'ssd "più veloce"?

La risposta a questa domanda è più articolata, perchè l'ssd legge/scrive e si comporta in maniera diversa se i dati cercati o scritti sono piccoli (casuali) o grandi (sequenziali) e se il carico di lavoro è alto (QD alta) o basso (QD bassa).

Iniziando proprio dal mio errore: HMB è una memoria su cui giace una parte di mappatura (+ algoritmi di gestione).
In particolare la parte di mappatura che "recentemente" per il controller dell'ssd, è stata modificata.
Qundo si citano "metadati" si intendono esclusivamente gli algoritmi e nessun blocco, pezzo o frammento di file utente.

Nota: sul punto 1); solo i dati recentemente modificati possono giovare della velocità di ricerca (letture) poichè gli indirizzi di mappatura perdurano in RAM di sistema. Vuol dire che nell'uso "normale", un ssd HMB leggerà la mappatura nella nand e un ssd con DRAM lo leggera da quest'ultima, MA con un accesso da parte del controller identico.
Sui risultati ottenuti da Pradeep SR e Ranjith T, nel testo Exploring Performance Paradigm of HMB NVMe SSD's, promosso da Samsung, uno dei valori sfalsati a mio giudizio, è che il comando FIO di Iometer utilizzato in unico step, conserva in HMB la mappatura, dando quel gap in più, che nella realtà a pc appena acceso e con ssd nvme DRAM-less HMB inizializzato, non sono più presenti.

Riprendendo il punto 2), non devo confondere, come ho fatto, la L2P (mappatura o porzione di essa) con il caching dei dati o "metadati" come si vede citato e ho scritto io stesso.


Questo vuol dire che mi sono risposto alla mia domanda: perchè se ho 64 MB di HMB invece di 32 MB l'ssd non legge più velocemente o in generale non ho vantaggi prestazionali?

Il fatto che ci sia più memoria HMB disponibile:

in lettura - per il motivo detto sopra - non cambia le performanze. Non c'è una cache di dati da leggere di dimensione maggiore infatti; in realtà sono indirizzi... più indirizzi in memoria.
A questo proposito entra in gioco un ulteriore elemento, a discapito della velocità; la richiesta di lettura viaggia attraverso più livelli (controller dell'SSD → sistema operativo dell'host → RAM host) e poi il dato deve essere inviato indietro al controller per l'elaborazione. Una diminuzione di latenza perchè la mappatura è su RAM (quando c'è) VS aumento latenza per "round trip".

in scrittura si hanno le variazioni più interessanti per l'HMB.
Sempre ricordando bene che la memoria HMB su RAM contiene "solo" (tra virgolette) degli indici di mappatura, le istruzioni di livellamento contingenti o di garbage pre-scrittura (e nessun bit utente), emerge un principio: più il buffer di memoria HMB è grande, più indirizzi ci stanno, più la scrittura random ad alta frequenza (maggiori QD) o i dati sequenziali scritti sono veloci.
Gli indirizzi LBA infatti vengono scritti su RAM (più veloce) e più c'è buffer, più lo fanno a lungo. In particolare le scritture randomiche che sono accompagnati da parecchio overhead (che sono dati pure quelli e che ovviamente hanno i loro indirizzi di mappatura).

Originariamente inviato da giovanni69

Il senso sarebbe che in un open case, in cui ci fosse bisogno di cambiare spesso M.2 si potrebbero evitare cacciaviti ma basterebbe inserimento ed una rotazione e 'click, ed anche evitare eventuali soluzioni tipo la 'prolunga' proposta da sbaffo / Nikklaus.

Su amazon ci sono dei tappini in plastica o gomma con laccetto.