Benvenuti nel mondo delle prestazioni degli ssd!
Purtroppo non si può overcloccare un SSD...ancora; quindi non rimane altro che comprarne sempre di più veloci e... fare bench!!
Oltre ad indicare dei benchmark, in questa guida, vorrei spiegare cosa sono i risultati che si ottengono e come interpretarli.
Se volete fare bench "ignoranti" saltate questa parte e mettetevi a scaricare i vari software.
Iniziamo con un benchmark che è strumento interno di Windows.
winsat disk
Tool di Windows che valuta le prestazioni delle unità disco.
Si richiama mediate il prompt dei comandi in modalità "amministratore"
e digitando appunto il seguente comando: " winsat disk -drive c" (al posto di c potete mettere qualsiasi volume tra i vostri ssd) e dando il comando di invio da tastiera
in questo modo vengono enumerati i diversi test che il software sa fare con ognuno la propria sintassi da digitare e al fondo dei valori generali che già possiamo considerare.
Ricordate questo bench di Windows old?
ebbene si, è sempre lui, ed i valori finali li potete vedere dopo la misurazione di ogni singola voce.
Passando appunto alle voci di Winsat abbiamo:
Disk Random 16.0 Read - la velocità casuale dell'SSD in lettura di 1 file da 16KB
Disk Sequential 64.0 Read - la velocità sequenziale di lettura di 1 file da 64KB
Disk Sequential 64.0 Write - la velocità sequenziale di scrittura di 1 file da 64KB
Tempo medio di lettura con scritture sequenziali - il tempo di esecuzione della scrittura sequenziale
Latenza: 95° percentile - il valore del tempo di risposta del 95° percentile è il valore per il quale il 95% dei punti dati è più piccolo e il 5% è più grande. Il valore più alto rimasto è il 95° percentile. E' in pratica il valore più basso ponderato
Latenza: massima - la latenza più grande (sfavorevole) misurata nel test.
Tempo medio di lettura con scritture casuali - il tempo di esecuzione della lettura casuale
Crystaldiskmark
Benchmark sintetico estremamente versatile.
I benchmark sintetici sono però indicativi; il fatto che si possa fare un test in pochi minuti, vuol purtroppo dire che l'analisi è superficiale e non sempre rispecchia la prestazione reale del prodotto.
Crystaldiskmark è il benchmark per storage ad oggi più conosciuto ed usato. Il fatto che si trovino così tanti bench, permette di confrontare i propri risultati con quelli di prodotti simili, capendo al volo se si rientra nella normalità delle performance.
L'interfaccia è semplice ma permette una personalizzazione molto buona.
Per eseguire un bench occorre innanzitutto andare in impostazioni e scegliere "NVMe SSD" se volete testare questo tipo di storage; se lo storage è un hdd, una pendrive o un ssd SATA, questa impostazione non si tocca.
Se la vostra intenzione è di confrontare il test con altri sul web, lasciate tutto di default, in caso contrario potete personalizzare con le impostazioni che andiamo a vedere adesso.
N. di ripetizioni, cioè il numero di volte per tipo di test, ripetuto per trovare un valore medio. Di default 5 rappresenta un buon valore medio che mette al riparo da prestazioni deludenti se proprio in quel momento il controller dovesse essere impegnato.
Cambiarlo in 1, rederà il bench più veloce, ma anche meno preciso.
Set di lavoro, cioè lo spazio (libero) che CDM prende sulla partizione su cui fate il test. 1 GiB Gibibyte corrisponde a 1,074 GB
Per fare un esempio: se voleste assaggiare un piatto di spaghetti al pomodoro, questo spazio rappresenta la quantità di spaghetti che prendete e arrotolate sulla vostra forchetta.
Quindi si testa un file da 1GiB??
No.
Come vedete nel profilo predefinito il file che viene scritto/letto ammonta a 1MiB (circa 1MB) per i test sequenziali e a 4KiB (circa 4096 byte), per il bench casuale I/0 (RND). Nell'esempio fatto, di quella forchettata di pasta, si assaggia infatti uno spaghetto per vedere se è buono: buono uno, buono tutto! 😅
Cosa succede se riduco o aumento il Set di lavoro?
Dai 16 MiB a 64 GiB si ha una grande possibilità in effetti specie per valori molto maggiori ad 1GiB.
Ad esempio usare 64GiB vuol far fare al controller un lavoro maggiore; dovrà infatti scrivere/leggere (sempre 1MB o 4KB) su uno spazio maggiore crescendo i valori di seek time (tempo di ricerca e quindi latenza del controller).
Cambia qualcosa per i bench?
No, anche qui. Se fosse un hdd certamente, ma gli ssd hanno una velocità che consente una ricerca degli spazi dove scrivere o dei dati da leggere, praticamente istantanea.
Sistema di misura, ovvero come visualizzare i risultati. E' un opzione sempre intercambiabile perchè il software calcola delle equivalenze; quindi i MB/s o GB/s possono esprimersi in IOPS (n. di operazioni al secondo) perchè si conosce la grandezza del file scritto/letto, ma anche in us microsecondi.
Tempo di bench e tempo dell'intervallo, di default CDM utilizza 5 secondi per ogni trasferimento o lettura con una pausa seguente di altri 5 secondi. Il tempo è certamente sufficiente per le operazioni - 4KB ma anche il seq 1MB sono piccoli file - però per una migliore ottimizzazione una buona raccomandazione per il tempo di misurazione è di 30 secondi mentre sull'intervallo di tempo si può inserire 60 secondi. Questo per assicurarsi che ci sia un tempo tranquillo tra i test di scrittura con uno svuotare della cache di scrittura.
Dimensione del file di bench, Coda e Processi, sono tutti opzionabili nelle impostazioni di CDM.
Il bench fà come si vede 4 test, 2 per il sequenziale e 2 per il casuale.
Per la dimensione del file dei test casuali, il 4KiB è perfetto, essendo la dimensione minima dei blocchi del file system.
Convenzionalmente 1MiB è il sequenziale ma ingrandendo questo file ci si avvicina alla realtà del quotidiano.
CrystalDiskMark consente di impostare code e thread (processi).
La quantità di code è la quantità di I/O che ogni processo sta generando contemporaneamente (OIO - Outstanding IO).
Ogni comando di lettura e scrittura viene diviso in blocchi che vanno scritti o letti (solitamente da 4KiB). Windows stesso (o altro os) realizza una coda di questi comandi (divisi per priorità); queste richieste sono inviate al controller dell'ssd che li elabora (cerca o scrive). Questa è detta "coda" dei Comandi.
Entrambi i test I/O casuali predefiniti sono impostati su una dimensione del blocco di 4K. Mentre 4K è una dimensione del blocco che può essere vista a volte, di solito non è una dimensione del blocco comune nella maggior parte dei carichi di lavoro odierni. Quando possibile, la dimensione del blocco nel test deve corrispondere alla dimensione del blocco dell'applicazione. La dimensione del blocco comune sia per Oracle che per MS SQL è di 8 KB e 64 KB. Mentre queste applicazioni hanno dimensioni di blocco variabili dipendenti dal lavoro svolto, 8 KB e 64 KB sono dimensioni di blocco molto comunemente utilizzate sul campo.
Tutti e quattro i test predefiniti sono a thread singolo, il che non mostra un profilo I/O realistico per la stragrande maggioranza dei carichi di lavoro poiché la maggior parte delle applicazioni moderne è multithread. Su hdd e ssd sata il multithread non è elaborato ma un ssd nvme ha le potenzialità, ecco perchè nel profilo nvme i processi di un bench casuale diventano anche 16, misurando la tenuta del parallelismo delle richieste contemporanee.
CONTINUA...
ATTO Disk Benchmark
Benchmark sintetico strutturato con dati incomprimibili sequenziali.
AS SSD
Benchmark sintetico con controllo dell'allineamento ed interfaccia grafica.
Purtroppo non si può overcloccare un SSD...ancora; quindi non rimane altro che comprarne sempre di più veloci e... fare bench!!
Oltre ad indicare dei benchmark, in questa guida, vorrei spiegare cosa sono i risultati che si ottengono e come interpretarli.
Se volete fare bench "ignoranti" saltate questa parte e mettetevi a scaricare i vari software.
Una prima premessa è che un SSD è un dispositivo totalmente elettronico cioè a differenza dell'hard disk non ha un attuatore/testina che meccanicamente si muove a ricercare il data-bit. Tutto avviene elettricamente con tempi molto più rapidi. Rapidamente ma non simultaneamente, perchè il controller che gestisce la ricerca, spostamento celle, controlli, ecc, ha pur sempre una limitata capacità di processazione.
Seconda premessa, i "valori" che un bench ci ritorna dal test sull'ssd sono simulazioni e danno solo l'idea generale delle prestazioni reali dell'SSD, molto meglio ad esempio provare a trasferire un file tra cartelle di ssd diversi con medesime caratteristiche. Una prova reale che non sempre è fattibile. Facendo i benchmark però possiamo avere una base di confronto e scoprire/monitorare eventuali problemi, dell'SSD (fisico) o della sua parte logica.
Terza premessa. Un SSD ha un Controller (cioè una multi CPU di gestione), una memoria rapida dove posizionare una tabella a cui il controller fa sempre riferimento e che viene continuamente modificata (aggiornata), e infine le celle di memoria NAND Flash, ovvero le memorie su cui i nostri dati risiedono fisicamente. Questo è l'hardware. Tutti gli SSD hanno anche un software nel controller che determina come viene usato l'hardware, in particolare l'uso della cache di scrittura.
L'alchimia tra questi tre elementi hardware e del software di gestione, determina prestazioni diverse.
Alcuni esempi: un controller lavora su più canali per inviare e ricevere dati, quindi l'ssd deve essere strutturato in modo da avere più di un chip di memorie NAND corrispondenti ai diversi canali del controller; ecco perchè solitamente SSD di dimensioni piccole (120, 250, 500 GB) hanno prestazioni minori in scrittura, infatti ad un controller multicanale, corrisponde un chip nand con soli 2 canali, mentre gli ssd grandi, avendo più chip integrati hanno sicuramente più di 2 canali per la transizione di dati.
Altro esempio di tipo hardware è la presenza o l'assenza di una memoria fisica dentro l'SSD; quando c'è un chip di memoria DRAM la tabella che serve al controller è messa li, con un vantaggio maggiore in termini di velocità sostenuta e casuale in scrittura; se il chip di memoria non c'è, l'SSD usa la RAM di sistema quindi un processo aggiuntivo che aumenta la latenza complessiva.
Un terzo esempio di tipo hardware si può fare distinguendo il tipo di cella NAND con cui è realizzato l'SSD. Le normali celle 3D TLC hanno prestazioni di lettura e - soprattutto - scrittura, maggiori (più veloci) di celle NAND di tipo QLC. Ma anche celle di uno stesso tipo, come le 3D TLC possono essere di generazione diversa ed essere le più recenti, parecchio più veloci.
Le caratteristiche della cache infine possono velocizzare anche l'SSD più scarso MA ci sono diversi tipi di cache e se è dinamica, allora le prestazioni dell'SSD crolleranno parecchio velocemente.
Quarta e ultima premessa. Questi "valori" sono di tipo diverso e devono essere capiti, PRIMA di eseguire il bench.
Il test misura la velocità in MB/s in lettura e in scrittura. Quando il test misura valori molto piccoli, è possibile che i MB/s siano espressi come IOPS, cioè in numero di operazioni eseguite al secondo. I due valori rappresentano però un equivalenza: preso il valore di IOPS posso trasformarlo in MB/s conoscendo a priori la grandezza del file di test.
Infine un altro dato può essere rilevato con un benchmark, ovvero la latenza; si tratta infatti del valore di tempo - millisecondi (ms) - che passa tra la ricezione del comando da parte dell'host (noi) e il "comando ricevuto" da parte del controller dell'SSD.
La cosiddetta "velocità sequenziale" di un SSD - quella tanto pubblicizzata nei nuovi M.2 NVMe/PCIe, è la velocità di lettura e scrittura di un file di grandi dimensioni (standardizzato a 1MB), dando un comando ripetuto in modo che si crei una coda di comandi relativamente elevata. Perchè la coda dei comandi? Dando 1 comando solitario oltre al tempo tecnico di lettura o scrittura del controller sulle celle aumento anche del tempo di latenza che ci mette il sistema a comunicare con l'ssd e il tempo di ricerca; con comandi ripetuti il tempo di latenza si riduce ad una sola volta mentre tutte le operazioni seguenti alla prima, sono operazione di lettura e scrittura in se più veloci.
La cosiddetta "velocità casuale" dell'SSD in lettura o scrittura è invece quella che simula i comandi di un sistema operativo, quindi più è alta e migliore dovrebbe essere di conseguenza la velocità (reattività) del nostro PC. Viene preso un file di dimensioni piccole (standardizzato 4KB) senza coda di elaborazione in modo che tutto, anche la latenza, abbia il suo peso nel processo di lettura o scrittura.
Seconda premessa, i "valori" che un bench ci ritorna dal test sull'ssd sono simulazioni e danno solo l'idea generale delle prestazioni reali dell'SSD, molto meglio ad esempio provare a trasferire un file tra cartelle di ssd diversi con medesime caratteristiche. Una prova reale che non sempre è fattibile. Facendo i benchmark però possiamo avere una base di confronto e scoprire/monitorare eventuali problemi, dell'SSD (fisico) o della sua parte logica.
Terza premessa. Un SSD ha un Controller (cioè una multi CPU di gestione), una memoria rapida dove posizionare una tabella a cui il controller fa sempre riferimento e che viene continuamente modificata (aggiornata), e infine le celle di memoria NAND Flash, ovvero le memorie su cui i nostri dati risiedono fisicamente. Questo è l'hardware. Tutti gli SSD hanno anche un software nel controller che determina come viene usato l'hardware, in particolare l'uso della cache di scrittura.
L'alchimia tra questi tre elementi hardware e del software di gestione, determina prestazioni diverse.
Alcuni esempi: un controller lavora su più canali per inviare e ricevere dati, quindi l'ssd deve essere strutturato in modo da avere più di un chip di memorie NAND corrispondenti ai diversi canali del controller; ecco perchè solitamente SSD di dimensioni piccole (120, 250, 500 GB) hanno prestazioni minori in scrittura, infatti ad un controller multicanale, corrisponde un chip nand con soli 2 canali, mentre gli ssd grandi, avendo più chip integrati hanno sicuramente più di 2 canali per la transizione di dati.
Altro esempio di tipo hardware è la presenza o l'assenza di una memoria fisica dentro l'SSD; quando c'è un chip di memoria DRAM la tabella che serve al controller è messa li, con un vantaggio maggiore in termini di velocità sostenuta e casuale in scrittura; se il chip di memoria non c'è, l'SSD usa la RAM di sistema quindi un processo aggiuntivo che aumenta la latenza complessiva.
Un terzo esempio di tipo hardware si può fare distinguendo il tipo di cella NAND con cui è realizzato l'SSD. Le normali celle 3D TLC hanno prestazioni di lettura e - soprattutto - scrittura, maggiori (più veloci) di celle NAND di tipo QLC. Ma anche celle di uno stesso tipo, come le 3D TLC possono essere di generazione diversa ed essere le più recenti, parecchio più veloci.
Le caratteristiche della cache infine possono velocizzare anche l'SSD più scarso MA ci sono diversi tipi di cache e se è dinamica, allora le prestazioni dell'SSD crolleranno parecchio velocemente.
Quarta e ultima premessa. Questi "valori" sono di tipo diverso e devono essere capiti, PRIMA di eseguire il bench.
Il test misura la velocità in MB/s in lettura e in scrittura. Quando il test misura valori molto piccoli, è possibile che i MB/s siano espressi come IOPS, cioè in numero di operazioni eseguite al secondo. I due valori rappresentano però un equivalenza: preso il valore di IOPS posso trasformarlo in MB/s conoscendo a priori la grandezza del file di test.
Infine un altro dato può essere rilevato con un benchmark, ovvero la latenza; si tratta infatti del valore di tempo - millisecondi (ms) - che passa tra la ricezione del comando da parte dell'host (noi) e il "comando ricevuto" da parte del controller dell'SSD.
La cosiddetta "velocità sequenziale" di un SSD - quella tanto pubblicizzata nei nuovi M.2 NVMe/PCIe, è la velocità di lettura e scrittura di un file di grandi dimensioni (standardizzato a 1MB), dando un comando ripetuto in modo che si crei una coda di comandi relativamente elevata. Perchè la coda dei comandi? Dando 1 comando solitario oltre al tempo tecnico di lettura o scrittura del controller sulle celle aumento anche del tempo di latenza che ci mette il sistema a comunicare con l'ssd e il tempo di ricerca; con comandi ripetuti il tempo di latenza si riduce ad una sola volta mentre tutte le operazioni seguenti alla prima, sono operazione di lettura e scrittura in se più veloci.
La cosiddetta "velocità casuale" dell'SSD in lettura o scrittura è invece quella che simula i comandi di un sistema operativo, quindi più è alta e migliore dovrebbe essere di conseguenza la velocità (reattività) del nostro PC. Viene preso un file di dimensioni piccole (standardizzato 4KB) senza coda di elaborazione in modo che tutto, anche la latenza, abbia il suo peso nel processo di lettura o scrittura.
Iniziamo con un benchmark che è strumento interno di Windows.
winsat disk
Tool di Windows che valuta le prestazioni delle unità disco.
Si richiama mediate il prompt dei comandi in modalità "amministratore"
e digitando appunto il seguente comando: " winsat disk -drive c" (al posto di c potete mettere qualsiasi volume tra i vostri ssd) e dando il comando di invio da tastiera
in questo modo vengono enumerati i diversi test che il software sa fare con ognuno la propria sintassi da digitare e al fondo dei valori generali che già possiamo considerare.
Ricordate questo bench di Windows old?
ebbene si, è sempre lui, ed i valori finali li potete vedere dopo la misurazione di ogni singola voce.
Passando appunto alle voci di Winsat abbiamo:
Disk Random 16.0 Read - la velocità casuale dell'SSD in lettura di 1 file da 16KB
Disk Sequential 64.0 Read - la velocità sequenziale di lettura di 1 file da 64KB
Disk Sequential 64.0 Write - la velocità sequenziale di scrittura di 1 file da 64KB
Tempo medio di lettura con scritture sequenziali - il tempo di esecuzione della scrittura sequenziale
Latenza: 95° percentile - il valore del tempo di risposta del 95° percentile è il valore per il quale il 95% dei punti dati è più piccolo e il 5% è più grande. Il valore più alto rimasto è il 95° percentile. E' in pratica il valore più basso ponderato
Latenza: massima - la latenza più grande (sfavorevole) misurata nel test.
Tempo medio di lettura con scritture casuali - il tempo di esecuzione della lettura casuale
Crystaldiskmark
Benchmark sintetico estremamente versatile.
I benchmark sintetici sono però indicativi; il fatto che si possa fare un test in pochi minuti, vuol purtroppo dire che l'analisi è superficiale e non sempre rispecchia la prestazione reale del prodotto.
Crystaldiskmark è il benchmark per storage ad oggi più conosciuto ed usato. Il fatto che si trovino così tanti bench, permette di confrontare i propri risultati con quelli di prodotti simili, capendo al volo se si rientra nella normalità delle performance.
L'interfaccia è semplice ma permette una personalizzazione molto buona.
Per eseguire un bench occorre innanzitutto andare in impostazioni e scegliere "NVMe SSD" se volete testare questo tipo di storage; se lo storage è un hdd, una pendrive o un ssd SATA, questa impostazione non si tocca.
Se la vostra intenzione è di confrontare il test con altri sul web, lasciate tutto di default, in caso contrario potete personalizzare con le impostazioni che andiamo a vedere adesso.
N. di ripetizioni, cioè il numero di volte per tipo di test, ripetuto per trovare un valore medio. Di default 5 rappresenta un buon valore medio che mette al riparo da prestazioni deludenti se proprio in quel momento il controller dovesse essere impegnato.
Cambiarlo in 1, rederà il bench più veloce, ma anche meno preciso.
Set di lavoro, cioè lo spazio (libero) che CDM prende sulla partizione su cui fate il test. 1 GiB Gibibyte corrisponde a 1,074 GB
Per fare un esempio: se voleste assaggiare un piatto di spaghetti al pomodoro, questo spazio rappresenta la quantità di spaghetti che prendete e arrotolate sulla vostra forchetta.
Quindi si testa un file da 1GiB??
No.
Come vedete nel profilo predefinito il file che viene scritto/letto ammonta a 1MiB (circa 1MB) per i test sequenziali e a 4KiB (circa 4096 byte), per il bench casuale I/0 (RND). Nell'esempio fatto, di quella forchettata di pasta, si assaggia infatti uno spaghetto per vedere se è buono: buono uno, buono tutto! 😅
Cosa succede se riduco o aumento il Set di lavoro?
Dai 16 MiB a 64 GiB si ha una grande possibilità in effetti specie per valori molto maggiori ad 1GiB.
Ad esempio usare 64GiB vuol far fare al controller un lavoro maggiore; dovrà infatti scrivere/leggere (sempre 1MB o 4KB) su uno spazio maggiore crescendo i valori di seek time (tempo di ricerca e quindi latenza del controller).
Cambia qualcosa per i bench?
No, anche qui. Se fosse un hdd certamente, ma gli ssd hanno una velocità che consente una ricerca degli spazi dove scrivere o dei dati da leggere, praticamente istantanea.
Sistema di misura, ovvero come visualizzare i risultati. E' un opzione sempre intercambiabile perchè il software calcola delle equivalenze; quindi i MB/s o GB/s possono esprimersi in IOPS (n. di operazioni al secondo) perchè si conosce la grandezza del file scritto/letto, ma anche in us microsecondi.
Tempo di bench e tempo dell'intervallo, di default CDM utilizza 5 secondi per ogni trasferimento o lettura con una pausa seguente di altri 5 secondi. Il tempo è certamente sufficiente per le operazioni - 4KB ma anche il seq 1MB sono piccoli file - però per una migliore ottimizzazione una buona raccomandazione per il tempo di misurazione è di 30 secondi mentre sull'intervallo di tempo si può inserire 60 secondi. Questo per assicurarsi che ci sia un tempo tranquillo tra i test di scrittura con uno svuotare della cache di scrittura.
Dimensione del file di bench, Coda e Processi, sono tutti opzionabili nelle impostazioni di CDM.
Il bench fà come si vede 4 test, 2 per il sequenziale e 2 per il casuale.
Per la dimensione del file dei test casuali, il 4KiB è perfetto, essendo la dimensione minima dei blocchi del file system.
Convenzionalmente 1MiB è il sequenziale ma ingrandendo questo file ci si avvicina alla realtà del quotidiano.
CrystalDiskMark consente di impostare code e thread (processi).
La quantità di code è la quantità di I/O che ogni processo sta generando contemporaneamente (OIO - Outstanding IO).
Ogni comando di lettura e scrittura viene diviso in blocchi che vanno scritti o letti (solitamente da 4KiB). Windows stesso (o altro os) realizza una coda di questi comandi (divisi per priorità); queste richieste sono inviate al controller dell'ssd che li elabora (cerca o scrive). Questa è detta "coda" dei Comandi.
Entrambi i test I/O casuali predefiniti sono impostati su una dimensione del blocco di 4K. Mentre 4K è una dimensione del blocco che può essere vista a volte, di solito non è una dimensione del blocco comune nella maggior parte dei carichi di lavoro odierni. Quando possibile, la dimensione del blocco nel test deve corrispondere alla dimensione del blocco dell'applicazione. La dimensione del blocco comune sia per Oracle che per MS SQL è di 8 KB e 64 KB. Mentre queste applicazioni hanno dimensioni di blocco variabili dipendenti dal lavoro svolto, 8 KB e 64 KB sono dimensioni di blocco molto comunemente utilizzate sul campo.
Tutti e quattro i test predefiniti sono a thread singolo, il che non mostra un profilo I/O realistico per la stragrande maggioranza dei carichi di lavoro poiché la maggior parte delle applicazioni moderne è multithread. Su hdd e ssd sata il multithread non è elaborato ma un ssd nvme ha le potenzialità, ecco perchè nel profilo nvme i processi di un bench casuale diventano anche 16, misurando la tenuta del parallelismo delle richieste contemporanee.
CONTINUA...
ATTO Disk Benchmark
Benchmark sintetico strutturato con dati incomprimibili sequenziali.
AS SSD
Benchmark sintetico con controllo dell'allineamento ed interfaccia grafica.
Ultima modifica:
