Quote:
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
Quote:
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.
Quote:
Originariamente inviato da HSH
azz come mai tutta sta differenza col mio?
|
Pubblica che vediamo.