Le letture 4K saranno la cosa più difficile che l'unità può fare. Sono tra le dimensioni di blocco più piccole che l'unità sarà in grado di gestire, e non c'è modo per l'unità di precaricare grandi quantità di dati, in realtà sono probabilmente abbastanza inefficienti se la logica di caricamento del disco dell'unità intende leggere qualcosa più grande di 4kb.
Le letture di unità "normali" hanno una probabilità maggiore di 4kb in quanto vi sono pochissimi file di dimensioni così ridotte e anche il file di paging potrebbe essere letto in blocchi di grandi dimensioni in quanto sarebbe strano che un programma avesse "solo" 4KB di memoria paginata. Ciò significa che qualsiasi precarico che l'unità tenta di fare penalizzerà effettivamente il rendimento dell'unità.
Le letture 4K potrebbero passare attraverso il buffer dell'unità, ma la parte "casuale" del test le rende del tutto imprevedibili. Il controller non saprà quando l'unità potrebbe aver bisogno delle letture "grandi" più comuni.
D'altra parte, le scritture 4K possono essere memorizzate, messe in coda e scritte in sequenza in modo efficiente. Il buffer dell'unità può svolgere gran parte del lavoro catch-and-write per cui è stato progettato e il livellatore di usura potrebbe persino allocare tutte quelle scritture 4K sullo stesso blocco di cancellazione dell'unità, trasformando occasionalmente ciò che è una scrittura 4K "casuale" in qualcosa di più vicino a una scrittura sequenziale.
In effetti sospetto che questo sia ciò che sta accadendo nelle scritture "4K-64Thrd", il "64-Thrd" sta apparentemente usando una grande profondità di coda , segnalando così all'unità che ha una grande quantità di dati da leggere o scrivere . Ciò innesca un sacco di clustering di scritture e quindi si avvicina alla velocità di scrittura sequenziale dell'unità. Esiste ancora un sovraccarico per l'esecuzione di una scrittura 4K, ma ora stai esponendo completamente il potenziale del buffer. Nella versione Read del test, il controller dell'unità, ora riconoscendo che è sotto carico molto costante, interrompe il precaricamento dei dati, probabilmente evita il buffer e passa invece a una modalità di lettura "grezza", avvicinandosi nuovamente alla velocità di lettura sequenziale.
Fondamentalmente il controller di unità può fare qualcosa per rendere più efficiente una scrittura 4K, specialmente se un cluster arriva in un momento simile, mentre non può fare nulla per rendere più efficiente una singola lettura 4K, soprattutto se sta cercando di ottimizzare flusso di dati pre-caricando i dati nella cache.
(Questo grafico non è immediatamente visibile nella recensione, è il 5 ° nella prima galleria, devi fare clic su di esso)
la velocità di scrittura è in linea con la tua, ma qui l'unità è ancora più lento a leggere. Il risultato è che il rapporto è cinque a uno, non tre a uno.