[@Liupen]

Originariamente inviato da Black (Wooden Law)

Per fare un esempio con un’applicazione: l’applicazione esegue più richieste I/O -> queste richieste I/O formano una coda “profonda” -> più code vengono raggruppate in un thread -> l’host (o meglio, il SO) comunica al controller dell’SSD che ci sono dei thread da gestire ma lo fa tramite DMA, ossia con CPU dormiente () -> l’SSD sempre tramite DMA prende i thread -> l’SSD “risolve” i thread per i fatti suoi (o in caso di SSD DRAM-less con HMB risolve i thread con un po’ di RAM).

Si l'applicazione è il Thread che a sua volta è formato da 1 o più di una richieste I/0 (di lettura o scrittura) che possono formare una coda.



L'host tramite DMA, lancia una serie di letture o scritture.. "lavori" come li ho definiti su -> che sono spacchettabili in richieste I/0 da mettere in fila (richieste I/O formano una coda “profonda”) -> per essere poi composte sulla RAM se ho delle letture oppure poi trasmesse al controller se ho delle scritture.

Mmm...vediamo una riflessione. Considera che l'host, il sistema operativo, non sa che hardware c'è sotto di lui. Quindi opera sempre in astratto con la sua mappatura di LBA. Quindi per fare un esempio molto concreto, se io gli dico di aprirmi un file di testo in Windows e ho un ssd, Windows cerca nella mappatura: le istruzioni per aprire i software, il file di testo, attinge al driver per visualizzarlo e infine me lo propone.
Ognuna di queste operazioni sono Thread...molti thread che windows trasmette all'ssd mediante il pipe DMA.
Attento ora:
1) I thread sono richieste a livello logico (mappatura LBA) non fisica.
2) Il Thread è un entità astratta fatto da una o più richieste (o comandi) I/0

Quando scrivi: l’SSD sempre tramite DMA prende i thread -> l’SSD “risolve” i thread per i fatti suoi
è concettualmente falso

L'host sempre tramite DMA prende i thread -> l'host “risolve” i thread per i fatti suoi

perchè l'elaborazione dell'applicazione ovvero nell'esempio l'apertura del file di testo, è un lavoro tutto a livello logico non fisico (sull'ssd).

DMA su host vede tutte le operazioni da fare (istruzioni per aprire i software, il file di testo, attinge al driver per visualizzarlo) quindi tutti i Thread sotto forma di richieste I/0 (LBA) le organizza per priorità, le accoda e le richiede al Controller dell'ssd, che, poverino, esegue solo (partendo dalla traduzione della mappatura LBA-> blocco fisico).
Ecco il perchè del possibile limite della coda dei comandi (sata 32 vs nvme migliaia). L’unità minima di comunicazione fra host (DMA) e controller è il comando I/O, non il thread che lo origina. Ecco perché si “limita” il numero di comandi pendenti, non i thread. Un protocollo ha più banda passante dell'altro.

Questo invece: "(o in caso di SSD DRAM-less con HMB risolve i thread con un po’ di RAM)" riguarda l'aggiornamento della mappatura o FTL più in generale. Altro discorso.



[quote=Black (Wooden Law);48789878]
Comunque, per il numero massimo di QD per thread, TechTarget dice:

• I dispositivi Serial ATA o SATA possono supportare una coda di comando con una profondità di coda di 32 comandi.
• I dispositivi Serial-attached SCSI o SAS possono supportare una coda di comando con una profondità di coda di 256 comandi.
• I dispositivi Nonvolatile memory express o NVMe possono supportare un numero massimo di 65.535 code di comando con una profondità di coda fino a 65.536 comandi per coda.

Da qui presumo:
1) TechTarget ha le idee abbastanza confuse;
2) TechTarget ha fatto confusione con i termini per gli SSD NVMe;
3) TechTarget con “coda di comando” non intende i thread ma altro di cui non so. Secondo me sbaglia e la verità è che (penso) ci sia un numero “illimitato”¹ di thread ma non ovviamente di richieste I/O, quindi NVMe può creare massimo 65.536 di richieste I/O per thread, SAS 256 richieste I/O per thread, ecc.
————————————————-
¹: ovviamente non sono illimitati, penso che dipenda dall’applicazione, dalle capacità del controller dell’SSD, dal SO, ecc.

queue depth = richieste I/0

E' giusto, perchè idee confuse?

Originariamente inviato da @Liupen

Il numero di comandi I/O pendenti che l’host può mettere in coda verso il controller sono massimo 32 par AHCI e di miglioia per nvme che inoltra supporta anche comandi di lettura e scrittura contemporanei.

A parte gli errori di battitura

Si tratta del principale motivo per cui appena è stato possibile si è passati da sata (ahci) a nvme
Come dice il testo, i I/0 limitati fanno da collo di bottiglia.

"Solid-state drives (SSDs), based on NVMe technology, with its larger queue depth, have faster response times".
Questo non è vero, infatti purtroppo la reattività di un ssd sata e di uno nvme è quasi la stessa. Il PRO è che con nvme "passa" più roba e può essere elaborata parallelamente.

Originariamente inviato da Black (Wooden Law)

No Liupen, teoricamente nCache, nCache 2.0 e nCache 3.0 son tutte e tre cache SLC statiche, semplicemente perché su tutti i modelli di SSD a cui sono state implementate è così, anche per l’SN750 dove la cache SLC è di ~45GB. nCache 4.0, invece, è una cache SLC ibrida visto l’SN850 (primo modello su cui è stata implementata se ricordo bene). Non so darti molte fonti su quest’ultima semplicemente perché WD non lo dice ma se cerchi “nCache 4.0 hybrid SLC” su Google vedi che trovi “hybrid SLC” come parole chiave negli articoli (mentre con nCache 3.0 no).

Ok.
nCache 2.0 la conosco bene è statica.
Ma vabbeh! Ormai roba vecchia.
nCache 3.0 e 4.0 non ho approfondito. Tanto tutti i produttori danno nomi diversi allo stesso tipo di cache: anche ora Samsung Turbo Write originale è diventata Turbo Write 2.0