Configurazione di prova, benchmark e metodologia

Configurazione di prova, benchmark e metodologia

Lo Storage Networking Industry Association (SNIA), un gruppo di lavoro composto da produttori di SSD, memoria NAND Flash e chi sviluppa controller, ha prodotto una procedura di test che cerca di controllare quante più variabili possibili inerenti agli SSD. Il Solid State Storage Performance Test Specification (SSS PTS) di SNIA è una grande risorsa per mettere alla prova gli SSD enterprise. La procedura non definisce quali test devono essere realizzati, ma il modo nel quale devono lavorare. Questo flusso di lavoro è suddiviso in quattro parti:

• Purificazione (Purge): pone il disco in una posizione di partenza conosciuta. Per gli SSD questo normalmente significa "Secure Erase", ovvero cancellazione sicura.
• Pre-condizionamento del carico di lavoro indipendente: un compito prescritto che non è correlato al carico di lavoro testato.
• Pre-condizionamento basato sul carico di lavoro: test del carico di lavoro vero e proprio (operazioni 4KB casuali, sequenziali da 128 KB e così via) che spinge il disco verso uno stato di equilibrio.
• Stato di equilibrio: il punto nel quale le prestazioni del disco non cambiano più in base alla variabile monitorata.

Questi passaggi sono critici nella prova di un SSD. È incredibilmente facile sbagliare e non mettere sotto carico l'unità, ottenendo un comportamento da prodotto "nuovo di zecca" e pensare si tratti di prestazioni in stato di equilibro. Inoltre si tratta di passaggi importanti anche nel passaggio tra scritture casuali e sequenziali.

Per tutte le prove sulle prestazioni realizzate in questa recensione, l'SSS PTS è stato seguito per assicurare risultati accurati e ripetibili.

Tutti i test usano dati casuali, se disponibili. Il RealSSD P320h di Micron non effettua nessuna compressione prima della scrittura, quindi non c'è differenza nelle prestazioni basate su modelli di dati.

Note

Siamo incappati in alcuni problemi durante questi test, causati principalmente dai driver di Windows che ci erano stati forniti. Inizialmente il sample inviatoci da Micron aveva solo il supporto Linux. L'azienda ha fatto un grande lavoro per darci driver per Windows in modo che potessimo iniziare i nostri est, ma si trattava di driver non completamente terminati.

Micron è stata molto chiara nel dirci che aveva svolto la maggior parte del lavoro di validazione sui server. Il nostro banco di prova non usava chiaramente un chipset di stampo server e aveva Windows. Durante i test il P320h è entrato per due volte in uno stato in cui ha dovuto "ricostruirsi" durante il POST (Power-on self-test). Non abbiamo perso alcun dato, ma la ricostruzione ha richiesto un po' di tempo.

Per assicurarci che i problemi fossero dovuti alla nostra specifica configurazione, abbiamo eseguito un test di riavvio sotto Linux su un server 1U per due giorni di fila. Il sistema si è riavviato centinaia di volte senza un problema. Poiché si tratta di un bug che non influisce sulle prestazioni, per motivi di coerenza abbiamo completato i nostri test sul nostro banco di prova standard.