SSD: thread generale e consigli per gli acquisti

[unnilennium]

Mah penso che si potrebbe usare un PIN in gomma, come su alcuni box USB, facile da mettere e da togliere, anche se continuo a non capire che senso abbia rispetto alla vite, parliamo di una scheda madre, per arrivarci devi aprire il case, e usare un cacciavite non sarà molto diverso... Tralasciando il prezzo della Asus proart che per quella cifra deve anche avere un omino che ti smonta il disco e te lo passa da dentro il case, altro che sgancio

Inviato dal mio 23127PN0CG utilizzando Tapatalk

[Black (Wooden Law)]

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

Mi sono appena reso conto di aver risposto a tutto tranne che alla tua domanda, scusami Sbaffo.

Sul perché alcuni usano 64MB anziché 32MB o anche meno non saprei dirti precisamente, sappiamo entrambi che di certo 32MB/64MB non bastano per l’intera mappa L2P perché l’aveva detto un po’ di tempo fa Liupen in questo thread, però penso che all’inizio di incertezza su questa tecnologia e su come funzionasse con gli SSD e quindi usassero 64MB di default per sicurezza. Poi magari mi sbaglio ma non so, non credo ci sia molta differenza tra 64MB e 100MB (attuale limite su Windows).

[sbaffo]

@ black
certo, per i dram immaginavo che ci fosse un calcolo del genere alla base, è naturale che ci sia proporzionalità. La domanda era perché invece sugli hmb sembra non esserci rapporto con la dimensione della cache hmb, per cui 32 o 64 sembrano indifferenti (dicevi tu sopra).
EDIT: mi hai preceduto mentre scrivevo.

@ gio69
il q-latch sappiamo cos'è, quello che non sappiamo è se una cosa del genere viene venduta separatamente...
se asus vendesse i ricambi... o chiederli a qualcuno che non li usa... o a sapere come si chiamano magari su aliexpress si trovano.

[Black (Wooden Law)]

Originariamente inviato da sbaffo

@ black
certo, per i dram immaginavo che ci fosse un calcolo del genere alla base, è naturale che ci sia proporzionalità. La domanda era perché invece sugli hmb sembra non esserci rapporto con la dimensione della cache hmb, per cui 32 o 64 sembrano indifferenti (dicevi tu sopra).

Questo paper è abbastanza interessante Sbaffo, guarda la Figura 8, essa in (a) mette in relazione la latenza in ns del FWB con la dimensione dell'HMB e nell'average puoi notare come la differenza si assottigli man mano che la dimensione dell'HMB aumenta da 32MB in su. Certo, c'è comunque differenza e sembra essere di qualche centinaio di ns, però è comunque poca/di meno rispetto a non avere l'HMB. Certo che c'è anche poca differenza tra 8MB e 32MB...

Gli autori oltretutto affermano che "quando lo spazio dell'HMB è di 512MB, quasi tutte le richieste di scrittura da tutti i carichi di lavoro possono essere "bufferizzate"", quindi un HMB con più di 512MB risulterebbe pressoché inutile.

[aled1974]

Originariamente inviato da sbaffo

il q-latch sappiamo cos'è, quello che non sappiamo è se una cosa del genere viene venduta separatamente...
se asus vendesse i ricambi... o chiederli a qualcuno che non li usa... o a sapere come si chiamano magari su aliexpress si trovano.

scrivete su google: "asus q-latch spare parts"


però come detto da unnilennium non vedo perchè complicarsi la vita, se la proprio mobo ha la vite IMHO va benissimo quella

ciao ciao

[sbaffo]

Originariamente inviato da Black (Wooden Law)

Questo paper è abbastanza interessante Sbaffo, guarda la Figura 8, essa in (a) mette in relazione la latenza in ns del FWB con la dimensione dell'HMB e nell'average puoi notare come la differenza si assottigli man mano che la dimensione dell'HMB aumenta da 32MB in su. Certo, c'è comunque differenza e sembra essere di qualche centinaio di ns, però è comunque poca/di meno rispetto a non avere l'HMB. Certo che c'è anche poca differenza tra 8MB e 32MB...

Gli autori oltretutto affermano che "quando lo spazio dell'HMB è di 512MB, quasi tutte le richieste di scrittura da tutti i carichi di lavoro possono essere "bufferizzate"", quindi un HMB con più di 512MB risulterebbe pressoché inutile.

visto grazie, peccato che passi da 32 a 128 saltando i 64, c'è maggior salto tra 32 e 128 che tra 8 e 32, sia nell'average ma soprattutto in alcuni test singoli.
Non l'ho letto tutto, non dicono che dimensione di SSD hanno simulato?

[sbaffo]

Originariamente inviato da aled1974

scrivete su google: "asus q-latch spare parts"

però come detto da unnilennium non vedo perchè complicarsi la vita, se la proprio mobo ha la vite IMHO va benissimo quella

ciao ciao

in effetti si trovano anche su ebay (da chissadove) a circa 5 euro l'uno che rapina! più spedizione...

però c'è anche gente che vuole tornare indietro perchè col dissipatore non vanno d'accordo: https://www.reddit.com/r/ASUS/commen..._it_with_a_m2/
https://www.ebay.co.uk/itm/126701087887

concordo che non è quello il problema degli M2, il problema è smontare mezzo pc e infilare le mani tra schede grafiche/varie e dissipatori, anzi un cacciavitino con punta magnetica mi sa che è più comodo del Q-latch.

Nikklaus sta provando le "prolunghe", come questa: https://www.amazon.it/Cablecc-Prolun...EDV&gQT=1&th=1
ma nelle recensioni qualcuno si lamenta di errori di scrittura dovuti ai cavi non schermati... ci vorrebbero dei cavi schermati, o tanta carta stagnola fai-da-te

[Black (Wooden Law)]

Originariamente inviato da sbaffo

Non l'ho letto tutto, non dicono che dimensione di SSD hanno simulato?

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.

[giovanni69]

@aled1974: grazie, farò quel tipo di ricerca

Il problema però potrebbe essere una questione di compatibilità con altre mobo nei 'buchi', altezza del rivetto?.. Leggo anche di chi vuole invece liberarsene...

Originariamente inviato da unnilennium

Mah penso che si potrebbe usare un PIN in gomma, come su alcuni box USB, facile da mettere e da togliere, anche se continuo a non capire che senso abbia rispetto alla vite, parliamo di una scheda madre, per arrivarci devi aprire il case, e usare un cacciavite non sarà molto diverso...

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.

Originariamente inviato da sbaffo

concordo che non è quello il problema degli M2, il problema è smontare mezzo pc e infilare le mani tra schede grafiche/varie e dissipatori, anzi un cacciavitino con punta magnetica mi sa che è più comodo del Q-latch.

Tu dici? Se ti cade la piccola vite nel casino di cavi ecc...mah

[@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.

[sbaffo]

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.

azzh, 36GB è proprio poco, i primi ssd erano 64, ora almeno 256, potrebbe falsare le grandezze delle tabelle... oltre a essere del tutto teorico come dice liupen.

@ liupen
mi sono perso ma mi fido.

Originariamente inviato da giovanni69

@aled1974: grazie, farò quel tipo di ricerca

Il problema però potrebbe essere una questione di compatibilità con altre mobo nei 'buchi', altezza del rivetto?.. Leggo anche di chi vuole invece liberarsene...

non credo ci siano differenze tra mobo, gli ssd sono tutti uguali e devono starci su tutte, è quello che conta.
Discorso diverso i dissipatori degli ssd che possono interferire, ma dipende dal dissi.

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.

Ok con un banchetto la situazione cambia un po, ma se sono infognati tra dissi e schede video/varie non è comunque comodo infilarci le mani.

Tu dici? Se ti cade la piccola vite nel casino di cavi ecc...mah

perciò ho scritto e sottolineato con punta magnetica , ma nel caso scuoti finchè esce.

ovviamente spero che tu stacchi corrente all'ali prima di metterci le mani, altrimenti con la vitina metallica in giro il problema non è trovarla ma le scintille e il successivo incendio stile L.A.

[HSH]

https://ibb.co/RgXQb1F

eccolo arrivato! come sono le prestazioni? in linea?

[megthebest]

Originariamente inviato da HSH

https://ibb.co/RgXQb1F

eccolo arrivato! come sono le prestazioni? in linea?

in linea con la Gen4.
Ovviamente essendo vuoto e con un test del genere da il meglio di se.
Nelle impostazioni di CrystalDiskmark, seleziona NVME
Questo il mio Kingston Fury Renegade 1Tb di novembre 2022, unità di sistema con il 32% di spazio occupato

[Black (Wooden Law)]

Originariamente inviato da sbaffo

@ liupen
mi sono perso ma mi fido.

Sì, devo ammettere anche anch'io ho dovuto rileggerlo qualche volta il commento essendo abbastanza complesso e articolato.

Originariamente inviato da @Liupen

Perchè? La lettura dei riferimenti di mappatura da RAM o da DRAM hanno una latenza trascurabile in entrambe i casi.

Se ho capito bene qui stai dicendo che c'è poca differenza tra leggere i dati di mappatura sulla RAM del sistema e la DRAM, giusto?

Originariamente inviato da @Liupen

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.

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).

Qui molto semplicemente ho capito che non ha senso avere più spazio HMB se alla fine i dati da leggere sono sempre quelli e non aumentano, mentre ha più senso avere più spazio HMB per le scritture visto che si possono così scrivere più dati e quindi aumentare le performance, giusto?

[sbaffo]

Vabbè, ho lanciato io il sasso sull'HMB ma ora me ne pento .

Riassumendo:
diciamo che nel random 4k circa equivale ai dram, come sembra anche dalle prove:

Originariamente inviato da Black (Wooden Law)

Beh, sei fai conto che nella recensione di THW l’NM790 (HMB ndr) da 4TB in lettura 4 kB QD1 fa 21.000 IOPS mentre il T700 che è PCIe 5.0 DRAM-based ne fa 23.000 di IOPS… poi fai conto che dipende sempre dall’SSD e altri fattori quindi fare un discorso generale è abbastanza superficiale IMHO.

quindi per uso Windows generale/cazzeggio/basico va bene anche un hmb. Invece per utilizzo più tosto/sequenziale/grandi quantità di dati mossi la differenza si vede e i dram staccano gli hmb.
Poi ci sarebbe il vantaggio delle minori scritture su celle quindi maggiore durata per i dram rispetto agli hmb, ma ormai è abbastanza marginale, e soprattutto è secondario rispetto al target: per l'utilizzo basico (hmb) non ci si pone neanche il problema, per l'utilizzo intenso si va già sui dram.
giusto?

[Eddie666]

questi sono i miei due EDILOCA EN870, uno da 1tb e l'altro da 4tb, entrambi montati su slot 4.0

[HSH]

azz come mai tutta sta differenza col mio?

[Black (Wooden Law)]

Originariamente inviato da sbaffo

quindi per uso Windows generale/cazzeggio/basico va bene anche un hmb. Invece per utilizzo più tosto/sequenziale/grandi quantità di dati mossi la differenza si vede e i dram staccano gli hmb.
Poi ci sarebbe il vantaggio delle minori scritture su celle quindi maggiore durata per i dram rispetto agli hmb, ma ormai è abbastanza marginale, e soprattutto è secondario rispetto al target: per l'utilizzo basico (hmb) non ci si pone neanche il problema, per l'utilizzo intenso si va già sui dram.
giusto?

Sì, esatto, tutto giusto. SSD con HMB vanno benissimo per Windows finché vengono affiancati buoni controller (MAP1602, E27T, ecc.) e buone NAND flash (per esempio tutte le TLC).

Per quanto riguarda la durata mi permetto di dire che è tutta teoria quella che un DRAM-based è migliore di un DRAM-less: prima di tutto bisogna esser sicuri che i dati che vengano scritti, letti e cancellati siano nella piccola cache, altrimenti se si fanno queste operazioni nelle NAND flash siamo punto a capo, secondo la DRAM diminuisce il WAF facendo Defer-Write, ossia più indirizzi piccoli vengono "fusi" in un unico grande. Qui però non c'è alcuna testimonianza accademica e neanche divulgativa da parte dei recensori quindi se il tuo SSD con HMB ha un WAF basso penso che non ci sia alcun vantaggio, anche perché il WAF non dipende solo dalla presenza della DRAM.

Originariamente inviato da HSH

azz come mai tutta sta differenza col mio?

Quanto fa il tuo? Se fa meno delle specifiche non è normale.

[megthebest]

Originariamente inviato da HSH

azz come mai tutta sta differenza col mio?

Come dicevo devi impostare nvme nell'app crystaldiskmark

Inviato dal mio Xiaomi 14 utilizzando Tapatalk

[@Liupen]

Originariamente inviato da sbaffo

azzh, 36GB è proprio poco, i primi ssd erano 64, ora almeno 256, potrebbe falsare le grandezze delle tabelle... oltre a essere del tutto teorico come dice liupen.

@ liupen
mi sono perso ma mi fido.

Ma scritto mentre faccio pausa caffèèèè al lavoro, mi devo interrompere spesso.
si non ho brillato per "esposizione chiara"

Volevo dire che riguardo il testo linkato da Black sull'ssd da 36GB, che si tratta proprio letteralmente di una simulazione.
E' interessante. Tutto lo è se ti piace capire il funzionamento degli ssd.

Si tratta di utilizzare un software chiamato FEMU, che emula un ssd dalle caratteristiche che imposti.
https://github.com/MoatLab/FEMU

Originariamente inviato da Black (Wooden Law)

Se ho capito bene qui stai dicendo che c'è poca differenza tra leggere i dati di mappatura sulla RAM del sistema e la DRAM, giusto?

Qui molto semplicemente ho capito che non ha senso avere più spazio HMB se alla fine i dati da leggere sono sempre quelli e non aumentano, mentre ha più senso avere più spazio HMB per le scritture visto che si possono così scrivere più dati e quindi aumentare le performance, giusto?

Si e si.
Ho ripetuto (mi sa anche troppo spesso il mio errore) entrato nell'ottica che la mappatura è una bufferizzazione, è facile poi capire i meccanismi.

La differenza in lettura tra un ssd con DRAM ed uno senza ma con HMB, è che il controller nel primo caso recupera la mappatura (e non il dato... sottile ma determinante differenza), dalla DRAM (velocità del controller in MT/s = xxx), mentre HMB per lo più sulle NAND Flash (idem velocità del controller in MT/s = xxx) e poco o niente dalla RAM di sistema (per quella parte che è fortunatamente bufferizzata).

Questo è quindi un pareggio prestazionale.
Gli accessi casuali vengono spesso bufferizzati sia dal vero che ad esempio nei benchmark (vedi Crystadiskmark). Si possono anche vedere i leggeri vantaggi.
Per richiamare un dato sequenziale, la lettura HMB o meno, ha un acceso uguale.

Detto questo, per massimizzare la velocità di lettura anche in sequenziale, basterebbe avere un grande spazio di bufferizzazione, tipo 1GB per un ssd da 1TB come i DRAM based.

Ma c'è un problema che si evidenzia, quello definito round trip latency.
La CPU cerca la mappatura (attivato HMB la cerca su due dispositivi), la trova su RAM, ne fa richiesta al Controller dell'ssd che mette a disposizione su RAM il dato.
La latenza complessiva non è molto diversa da un ssd DRAM based: la CPU cerca la mappatura, passa dal controller SSD, il controller la trova sulla DRAM, il controller la trasferisce alla RAM.

Vediamo la riprova di questa affermazione. Prendiamo lo studio di Pradeep SR Ranjith T https://www.snia.org/sites/default/f...-NVMe-SSDs.pdf

Nelle ultime pagine, come hai detto Black, si prova a vedere velocità di trasferimenti in rapporto all'aumento delle dimensioni del buffer HMB (da 16 a 64 MB).
Guardiamo la situazione "normal" per semplicità.

Workloads: Sequential Read (128K-T1-QD32) - il caso in evidenza in cui in buffer HMB non può esserci tutto
Workloads: Random Read (4K-T1-QD32) - nel buffer c'è la mappatura che serve ma i risultati positivi rispecchiano quanto detto. Scrivono: Prestazioni migliori per l'allocazione Max HMB nella maggior parte dei casi.
Workloads: Random Read (4K-T16-QD32) - qui si "martella" l'ssd usando più thread casuali (multitasking). In questo caso la mappatura richiesta è molta e le prestazioni scendono (rispetto al test casuale singolo) evidenziando il round trip.


Invece per la scrittura, sono breve, perchè hai colto in pieno.
Più buffer HMB mette a disposizione, più mappatura ci stà, più veloce risulta la traduzione della mappatura (blocco logico - blocco fisico).
Questo elemento, che permette agli ssd con HMB di evitare che la traduzione avvenga sulle NAND Flash massimizzando la latenza, funziona meglio quando si tratta di trasferimenti sequenziali, i dati vengono letti o scritti in blocchi contigui, riducendo il numero di operazioni di mappatura. In tali scenari, l'HMB è sufficiente per ottimizzare il flusso dei dati.

L'importante è non confondere le prestazioni dovute all'uso della mappatura bufferizzata (HMB) dalle prestazioni in scrittura dovute a controller, Nand, tipi di carichi tipi di file, ecc. Due cose diverse con effetti diversi.

Infine la risposta alla domanda di sbaffo, che ho un po generalizzato: ma se un HMB funziona meglio con un buffer più grande (in scrittura) perchè non gli viene assegnato dal controller ad es. 1000 MB per un ssd da 1 TB come nei DRAM based?

E quì la soluzione l'hai già detta qualche passaggio sopra, Black.

I produttori fanno il minimo indispensabile (oltre a risultare 1 o 2 GB di RAM occupata... abbastanza ingombrante e impattante per un utente).

Maxio non è l'unica a considerare 32MB anche WD sostiene una dimensione di 32MB, sufficiente per i carichi di lavoro attuali.
Ciò non toglie che probabilmente si arriverà, con ssd di taglio maggiore, ad avere buffer anche da 100MB.

Una nota: tutti gli studi pubblicati hanno in oggetto trasferimenti di dati piccoli che ovviamente stanno nel buffer di HMB
Semplicemente quando dicono: con buffer HMB maggiore di 64MB non ottengo miglioramenti prestazionali, vuol dire che in quei 64MB sta tutta la L2P di cui c'è bisogno, corrispondendo ad ben 64 GB di trasferimenti.
Questi studi sono fatti per mettere in evidenza cosa fà HMB quindi non considerano le prestazione oversize.

Edit. oppure come nel caso dell'ssd da 36 GB, riducono la dimensione dell'ssd in modo che stia la mappatura nel buffer.

Originariamente inviato da HSH

azz come mai tutta sta differenza col mio?

Pubblica che vediamo.