Ciao,
leggendo su vari siti , sia famosi che non e facendo un riassunto di quello che ho capito,
mi risulta che un eseguire benchmark per disco in 4K, significa leggere file di 4K in maniera continua e casuale.
Ok, facciamo un esempio pratico usando CrystalDiskMark V8.0.4 (x64) come riferimento.
Nelle impostazioni del programma vado a configurare ''NVMe SSD''
quindi nella fila dei test al terzo tipo di test mi compare "RND4K - Q32T16"
che sta per
RND=casuale
4K = 4096 Bytes
Q = Queues = Coda = 32
T =Threads = Processi = 16
Dove per Coda si intende la quantità di I/O che ogni thread sta generando.
Lascio perdere il numero dei test e la dimensione del test, che secondo me in questo caso sono relativamente inutili, se non sbaglio.
Se io scrivo sul disco, senza buffer attivo, 16 files da 4K, tutto questo lo faccio 32 volte, generando 512 files da 4K,
finita la scrittura mi faccio i conti e tiro fuori il totale dei MB/s scritti
A questo punto mi trovo sul disco 512 files da 4K, pronti da leggere, 16 files alla volta, quindi 32 volte (vedi coda)
contemporaneamente li leggo file per file , senza buffer e in maniera assolutamente casuale,
finita la lettura mi faccio i conti e tiro fuori il totale dei MB/s letti.
La logica del codice da scrivere appena esposta è corretta ?
Ho dimenticato qualcosa ,bisogna aggiungere qualcosa ?
Grazie
C'è sul web una spiegazione abbastanza esaustiva e se sono fortunato nella ricerca, riesco a linkartela.
Comunque anche a me incuriosiva molto questo aspetto, visto che i benchmark del disco (hdd/ssd) rimangono gli unici mezzi di riferimento o stress test.
Ti faccio un punto della situazione di quello che so su crystaldiskmark (e spero che siano concetti non troppo errati). L'ottica è quella di immaginare che stai integrando il tuo software con un bench per lo storage...magari sbaglio
Lascia stare le impostazioni predefinite nvme, alla fine non ha molta importanza questo tipo di test mirati a definire quanto lavora in carichi paralleli un nvme dato che questi bench hanno in realtà poca attinenza con carichi, modi e tempi di un ambiente server o anche semplicemente "lavorativo".
Un bench come Crystal, ATTO, AS SSD, Anvel; ecc ecc - a mio parere - può esprimere "solo" alcune peculiarità del ssd: la velocità base del sistema controller/cella (latenza) ed è proprio la lettura/scrittura del blocco 4K, e la scrittura di grossi file in forma compressa o meno (sul file compresso il risultato è univoco visto che il controller comprime e decomprime il file a velocità quasi costante, ma una cartella grande di più file deve essere creata ad hoc per un bench se no i risultati sono troppo vari e non confrontabili.
Quindi: bench 4K letti/scritti + Scrittura grande file compresso + Scrittura grossa cartella file vari (3 bench)
Già queste 3 cose rendono una chiara idea dei limiti e pregi del SSD (in particolare si parla di ssd)
La cosa ancora che deve a mio parere essere considerata (peculiarità dei dischi nvme) è la cache SLC (pSLC). Il grande file compresso e la grande cartella di file, occorrerebbe che superassero le dimensioni di una cache SLC dell'SSD nvme... ma una dimensione simile (intorno ai 100-120GB) sarebbe probabilmente esagerata per un bench (ma sarebbe oltremodo utile SE si potesse accompagnare da un grafico.. come già ad esempio si vede fare da Anandtech o Tom - vedi sotto)
Dopo aver un po divagato, entro nella questione del test 4k.
Crystaldiskmark inizia il bench prendendo una parte di volume su C, D, dove vogliamo impostare il bench a seconda del dispositivo "sottostante" che abbiamo. Si crea un file di dati casuali.
Forse in realtà il processo di test inizia dalla scrittura, proprio perchè Crystal utilizza questo per effettuare il test di scrittura (4K piuttosto di sequenziale).
Crystal è impostato di default per un file da:
La grandezza si può cambiare fino a (la vers. 8 che stò guardando) 64GiB (oltre 68 GB)
Il file realizzato ad inizio bench, quindi, viene letto a seconda dei dati da richiamare (4K, sequenziale da 1MiB)
Ricordati che in Impostazioni puoi modificare il setup
ma crystal è molto limitato, perchè ovvimente deve essere un software user-friendly, quindi durare poco e occupare poco spazio. Ecco che allora puoi vedere che il file di bench >che dovrebbe essere la cosa più importante< si limita alla grandezza 4K (per il casuale) e 1 fino massimo a 8MiB per simulare una carico sequenziale ...molto ma MOLTO approssimato, altro che file compresso da 100GB!!
Certo è che, più è grande il file di default di 1GiB (vedi sopra), maggiore è la difficoltà nella ricerca del dato in lettura (seek), maggiore è, o dovrebbe essere, la difficoltà per gli ssd nvme dram-less
Con una lettura 4K e QD1 valuti in pieno la latenza del dispositivo tra: comando host-effettuazione del comando-messa a disposizione su ram
Con la lettura 4K in cui aumenti la coda dei comandi (mettiamo al valore 32 che era il massimo processabile) hai che la velocità di lettura aumenta maggiormente che non come somma dei singoli 4K. Questo fenomeno è dovuto all'ottimizzazione degli algoritmi di ricerca (AHCI mediante NCQ e NVMe che è implementato con un algoritmo molto simile). In pratica la sequenzialità di ricerca dei 4K casuali viene programmata in modo che si trovino i dati contemporaneamente da più canali del controller (ciòè simultaneamente da tutti i chip/pagine cui il controller è collegato). La parallelizzazione rende l'ssd in coda diversa da 1, più veloce.
Aggiungere più di un thread (T) vuol dire far operare il controller in modo ancora più parallelizzato, una caratteristica che fà emergere gli nvme nei confronti degli ssd sata
Infatti la differenza maggiore del preset predefinito da quello NVME
Se io scrivo sul disco, senza buffer attivo, 16 files da 4K, tutto questo lo faccio 32 volte, generando 512 files da 4K,
finita la scrittura mi faccio i conti e tiro fuori il totale dei MB/s scritti
16 file 4K con coda 32 T1? Si, sembra logico, 512 file da 4K.
Nel contempo hai il tempo misurato per il processo e si ottiene un valore sia in mb/s che volendo iops.
A questo punto mi trovo sul disco 512 files da 4K, pronti da leggere, 16 files alla volta, quindi 32 volte (vedi coda)
contemporaneamente li leggo file per file , senza buffer e in maniera assolutamente casuale,
finita la lettura mi faccio i conti e tiro fuori il totale dei MB/s letti.
La logica del codice da scrivere appena esposta è corretta ?
Ho dimenticato qualcosa ,bisogna aggiungere qualcosa ?
Secondo me il fatto che lo spazio / file di dati casuali preso dal bench abbia una certa dimensione, è importante, anche se mi rendo conto che crystaldiskmarck non funziona come dovrebbe (creando uno spazio iniziale di test) ma creando quello spazio proprio in funzione di cosa si testa (un po ovvio visto che i bench si possono far partire singolarmente e non solo mediante "all" e soprattutto i tempi per scrivere 1GiB non mi pare siano congrui...)
non è attendibile, devi usare comandi senza cache/buffer altrimenti sei condizionato/falsato dalla RAM e dalla CPU, devi usare 'da compilatore -> disco".. come fai tu, con i comandi DOS, esegui 'da compilatore -> ram/cpu -> disco'.
---
allora, conti alla mano, considerato che ci sono 512 file e che ogni file ha dimensioni di 4096 byte
sono 4096 * 512 = 2097152 byte
considerato che per eseguire e completare ogni operazione
(con accesso diretto al disco e senza nessun cache/buffer oltre che tutto random)
ci sono voluti 10389 ms
quindi nudi e crudi con un solo passaggio sono 0.19065 MB/s
se non sbaglio...
Potrei lanciare 5 volte il tutto e poi fare una media dividendo per 5
Questo si potrebbe considerare un benchmark più 'realistico' ? (uso reale)
--- View attachment 1695
allora, conti alla mano, considerato che ci sono 512 file e che ogni file ha dimensioni di 4096 byte
sono 4096 * 512 = 2097152 byte
considerato che per eseguire e completare ogni operazione
(con accesso diretto al disco e senza nessun cache/buffer oltre che tutto random)
ci sono voluti 10389 ms
quindi nudi e crudi con un solo passaggio sono 0.19065 MB/s
se non sbaglio...
Potrei lanciare 5 volte il tutto e poi fare una media dividendo per 5
Questo si potrebbe considerare un benchmark più 'realistico' ? (uso reale)
--- View attachment 1695
allora, conti alla mano, considerato che ci sono 512 file e che ogni file ha dimensioni di 4096 byte
sono 4096 * 512 = 2097152 byte
considerato che per eseguire e completare ogni operazione
(con accesso diretto al disco e senza nessun cache/buffer oltre che tutto random)
ci sono voluti 10389 ms
quindi nudi e crudi con un solo passaggio sono 0.19065 MB/s
se non sbaglio...
Potrei lanciare 5 volte il tutto e poi fare una media dividendo per 5
Questo si potrebbe considerare un benchmark più 'realistico' ? (uso reale)
io ho usato una di quelle app che converte... ?♂️
Il tuo test non ho la minima idea se lancia la lettura o scrittura dei 512 file in contemporanea (quindi coda) o no (su questo, ahime! Non avendo fatto informatica ho delle lacune nell'afferrare a fondo).
Prova prima a vedere se il test è allineato: monta un ssd, per un singolo file 4K senza coda dovresti ottenere per la lettura valori superiori a 40MB/s e per la scrittura valori sup. a 100MB/s
Prova senza cache/buffer e con.
Una volta definito che il test è significativo per il 4K, bisogna fare un po di bench per fissare i paletti:
tipo, su hdd sotto quella soglia è male/sopra è bene/sopra una soglia top hai un hdd con i contofiocchi (max punteggio)
stessa cosa per ssd, ma deve riconoscere (il benchmark) se c'è un sata piuttosto di un nvme 3.0 o 4.0
..da un testo di Tim Bray de ''New Oxford English Dictionary Project at the University of Waterloo'' , per calcolare bene servono diversi parametri, tra cui (e non solo):
"....the number of Kilo-bytes processed per elapsed second, and the % CPU usage (sum of user and system)..."
poi ci sta tutta una serie di 'regolette del terrore per squilibrati mentali' del tipo (riporto pari pari):
.....The file creation tests use file names with 7 digits numbers and a random number (from 0 to 12) of random alpha-numeric characters. For the sequential tests the random characters in the file name follow the number. For the random tests the random characters are first.
The sequential tests involve creating the files in numeric order, then stat()ing them in readdir() order (IE the order they are stored in the directory which is very likely to be the same order as which they were created), and deleting them in the same order.
For the random tests we create the files in an order that will appear random to the file system (the last 7 characters are in numeric order on the files). Then ......
@Liupen - Prova questo su qualche drive, se ti va segnalami ...qualsiasi cosa.. abbia senso di essere notata. @Federico83 - solo a livello di valutazione, è solo un dimostrativo, niente di più, niente di meno...
@Liupen - Prova questo su qualche drive, se ti va segnalami ...qualsiasi cosa.. abbia senso di essere notata. @Federico83 - solo a livello di valutazione, è solo un dimostrativo, niente di più, niente di meno...
Secondo me, per come è venuto indovinato il codice si posso creare più di 512 files, molti di più, alla fine è un modo come un altro per assaggiare come risponde il drive in test.
..da un testo di Tim Bray de ''New Oxford English Dictionary Project at the University of Waterloo'' , per calcolare bene servono diversi parametri, tra cui (e non solo):
"....the number of Kilo-bytes processed per elapsed second, and the % CPU usage (sum of user and system)..."
poi ci sta tutta una serie di 'regolette del terrore per squilibrati mentali' del tipo (riporto pari pari):
.....The file creation tests use file names with 7 digits numbers and a random number (from 0 to 12) of random alpha-numeric characters. For the sequential tests the random characters in the file name follow the number. For the random tests the random characters are first.
The sequential tests involve creating the files in numeric order, then stat()ing them in readdir() order (IE the order they are stored in the directory which is very likely to be the same order as which they were created), and deleting them in the same order.
For the random tests we create the files in an order that will appear random to the file system (the last 7 characters are in numeric order on the files). Then ......
quella era una prova, devo rivederla perchè al 95 % ci sono grossolani errori
comunque vorrei fare questi calcoli iniziali: (esempio con tempo impiegato di 13714 millisecondi)
quanti bytes ho scritto per file ?4096 bytes
quanti bit sono 4096 byte ?32768 bit
quanti files ho scritto ?16 files
quante volte ho scritto 16 files ? 32 volte
quanti files devo trovarmi a fine applicazione ? 512 files
quanti bit sono 16 files da 32768 bit ?524288bit
quanti bit sono 16 files da 32768 bit scritti 32 volte ? 16777216 bit
in quanto tempo ho scritto 524288 bit ?13714 millisecondi
correggo cosi perchè non posso correggere il post
****************************************************************** @Liupen
Quindi, sempre prendendo l'esempio di prima,
se in 13714 ms ho scritto 16777216 bit, vuol dire che in 1 ms ho scritto 12233 bit