SSD: thread generale e consigli per gli acquisti

[Black (Wooden Law)]

Originariamente inviato da sbaffo

Ma se non cambia nulla raddoppiando la cache HMB allora perchè la aumentano? dici che essendo "gratis" (per i produttori di ssd, tanto è ram di sistema) il marketing la fa da padrone?

Però nei dram-based ne mettono circa 1GB per ogni TB di nand, ci sarà un motivo se aumenta... e lì non è gratis.

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

[giovanni69]

Originariamente inviato da giovanni69

Pongo un quesito per chi virtualmente potrebbe aver bisogno di swappare spesso un SSD NVMe pur usando i relativi slot M.2 (ovvero senza uso di box).

Esiste qualcosa di universale ed equivalente al meccanismo 'Q-Latch' di Asus che permette di fissare un NVme M.2 con una procedura ad incastro/clip invece che con la solita vite?

Oppure: il rivetto a femmina delle mobo (o come si chiama) che ospita la vite potrebbe essere utilizzato agganciargli una clip in grado di bloccare l'NVMe al posto della vite stessa, replicando un meccanismo simile?

(Il nuovo M.2 Q-Latch nella ProArt X870E è una clip flessibile invece che essere una sorta kit ad incastro rotante facente perno sul rivetto di fissaggio).

Fonte: https://itigic.com/it/asus-q-latch-h...without-tools/

UP!
(avevo postato a fine 2024).

[deltazor]

Originariamente inviato da giovanni69

Fonte: https://itigic.com/it/asus-q-latch-h...without-tools/

UP!
(avevo postato a fine 2024).

Seguo con attenzione, bella domanda

[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?