SSD: thread generale e consigli per gli acquisti

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Ma questo non è lo stesso di quello che ho scritto io? Forse Q4T4 non è il miglior esempio del mondo visto che può far confusione ma quello che io intendo in prima pagina è 4 richieste I/O in coda per ogni thread. Non potrebbe essere una richiesta I/O in coda per ogni thread, altrimenti casi come Q8T3 non esisterebbero visto che ogni thread avrebbe più richieste I/O in coda.

Per quanto riguarda la definizione in sé di thread, non pensavo ce ne fosse una diversa da quella “canonica” della CPU; sapresti argomentare? Intanto procedo a correggere, ti ringrazio Liupen.

Sono più io che ringrazio te nell'aver modo di poter dialogare di ssd su temi un po più tecnici ma che se acquisiti possono portare il lettore a capire più approfonditamente i numeri che legge ad esempio confrontando due schermate di crystaldiskmark.

Ti parlo di concetti filtrati e semplificati, perchè non sono un informatico.

4 richieste I/O in coda per ogni thread = Q4T4 è ok

Però però...lascia stare le definizioni che leggi, cerca di capire la logica prima (scusa se mi permetto).

La definizione di Thread per il benchmark dell'ssd o comunque per gli I/0 all'ssd non è la definizione generale di Thread di CPU. Ovviamente si parla di significati uguali nel modo dell'informatica, nella sostanza, ma diversi nei modi.

L'esempio classico che si può fare, per il thread dell'ssd, a cui sono legato da sempre, è la biblioteca.
C'è un indice centrale su una scrivania e tanti scaffali attorno. Gli scaffali sono organizzati a zone: astronomia, narrativa, fantasy, geologia, ecc ecc
Altra cosa da immaginare e che tutti gli scaffali a raggiera sono raggiungibile dalle mie braccia.

Una richiesta di input/output (I/O in generale, senza distinguere tra sequenziale e casuale) è "vado a prendere il libro nello scaffale XY" oppure "vado a posare il libro sullo scaffale XY".
Quando (Q4T4) ho Q4 cioè 4 richieste contemporanee di consultare o mettere a posto un libro, ed io son da solo, io mi organizzo una coda di attività. Più mi muovo veloce con le braccia, più velocemente consulto i libri o li rimetto a posto sul relativo scaffale XY.
Passiamo ora dalla definizione di "richieste I/O" a quella di Thread.
Devo ad esempio fare una ricerca su come si è evolvuta la Terra nelle ere.
Mi serve contemporaneamente per la mia ricerca, un libro da scaffale astronomia e uno da scaffale geologia. Gli scaffali in questo caso sono XY e ZW.
Essendo due scaffali diversi, posso usare un braccio per XY e l'altro per ZW ottenendo quello che mi serve (o se "scrivo" rimettendo a posto i due libri).

Le richieste I/0 sono gli elementi grezzi del lavoro (poso libri/prendo libri).
Il Thread è il lavoro che si richiede (la ricerca/la conservazione della ricerca).

Il primo elemento e la coda che ne deriva, non c'è mai da sola, deve essere sempre finalizzata in almeno un Thread.. un lavoro, un obbiettivo.

Ora, capito il senso logico, pensiamo a chi gestisce le richieste e le istruzioni.
Quì scomodi le definizioni più tecniche.

Ogni Thread dell'ssd o che coinvolge la memoria non volatile, non passa dalla CPU di sistema ma viene elaborata mediante Direct Memory Access (DMA).

In generale, senza guardare le differenze di protocollo (AHCI/NVMe), l'host presenta il comando (lettura o scrittura) in Thread che vengono organizzati in varie richieste I/0 mediante DMA.
DMA mette in comunicazione l'host con il controller dell'ssd.
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.
Il controller SSD, senza disturbare la CPU di sistema, legge quella coda (sempre tramite DMA), esegue il trasferimento dati NAND da e per la RAM (DMA dei dati), poi scrive l’esito.
NB. durante questa operazione il controller gestisce come sappiamo anche il GC, il WL ecc oltre ad aggiornare la mappatura su SRAM o RAM di sistema.

Rifacendola semplice, il "lavoro" dell'utente, quindi l'host, gestisce il/i Thread mediante l'interfaccia [AHCI stà per SATA ma è più corretto dire AHCI] AHCI VS NVMe; le singole istruzioni che realizzano il/i Thread sono gestiti solo internamente all'host che ne assegna priorità, ne organizza le QD e tante altre cose molto tecniche che ora si può trascurare.
Il controller dell'ssd non gestisce le code ma può gestire più comandi in parallelo (Thread), in modo più o meno intelligente a seconda del numero di chip nand e dalle caratteristiche computazionali proprie.
Il controller poi ovviamente ha il compito di dare il comando "eseguito" all'host.

Originariamente inviato da Black (Wooden Law)

Sicuramente per le velocità di picco specificate dai produttori c’è di mezzo il fatto di usare benchmark dedicati all’SSD ma il principale motivo, secondo me, è proprio la quantità spropositata di richieste I/O in coda e thread. Lo possiamo notare proprio nelle recensioni che è così, perché sappiamo entrambi che qualsiasi SSD in Q1T1 (per esempio) farà sempre peggio rispetto a Q32T32 o anche peggio (vedi Tom’s Hardware che in alcuni test usa addirittura QD256).

Parlavi però delle prestazioni sequenziali massime pubblicate per un ssd, non di come si comportano al variare del tipo di bench.
Almeno, così mi era parso di capire.

Originariamente inviato da Black (Wooden Law)

Su nCache hai ragione ma io ho scritto che indica la cache SLC ibrida perché parlo di nCache 4.0 che è l’ultimo modello non parlo di nCache, nCache 2.0 o nCache 3.0.
Giusta accortezza, tuttavia, infatti domani correggo scrivendo “nCache 4.0”.

Per quanto concerne TurboWrite, invece, ti cito il PDF di Samsung sull’840 (… purtroppo, è l’unico che ho trovato):


Dynamic Write Acceleration, invece, non c’entra né con la RAM né con la cache SLC ibrida, è semplicemente il nome di Micron per la cache SLC dinamica.

Forse, ma controlla che vado a memoria, la nCache 3.0 è una pSLC con una parte statica e una dinamica, mentre la versione 4.0 per le QLC è poi solo dinamica.

Riguardo le cache di boost di Samsung colpa mia ho confuso il turbowrite con la rapidmode; ma quando ho letto ibride, mi è venuto in mente la forma software di accelerazione.

[Black (Wooden Law)]

Eccomi Liupen. Perdonami, ero fuori casa in questi due giorni.

Originariamente inviato da @Liupen

Rifacendola semplice, il "lavoro" dell'utente, quindi l'host, gestisce il/i Thread mediante l'interfaccia [AHCI stà per SATA ma è più corretto dire AHCI] AHCI VS NVMe; le singole istruzioni che realizzano il/i Thread sono gestiti solo internamente all'host che ne assegna priorità, ne organizza le QD e tante altre cose molto tecniche che ora si può trascurare.
Il controller dell'ssd non gestisce le code ma può gestire più comandi in parallelo (Thread), in modo più o meno intelligente a seconda del numero di chip nand e dalle caratteristiche computazionali proprie.
Il controller poi ovviamente ha il compito di dare il comando "eseguito" all'host.
Bene, ora che hai fornito questa spiegazione direi che ho afferrato il concetto. Facendo un riassunto (dimmi se sbaglio qualcosa):
- QD: profondità di coda ossia quantitativo di richieste I/O richieste dall’applicazione. Più vengono accumulate richieste più la coda aumenta;
- thread: insieme di richieste I/O organizzate in QD;

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).

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.

Originariamente inviato da @Liupen

Parlavi però delle prestazioni sequenziali massime pubblicate per un ssd, non di come si comportano al variare del tipo di bench.
Almeno, così mi era parso di capire.

Sì, esatto. Quello che io voglio dire è: 14,9 GB/s (solo per alcuni SSD ovviamente) sono raggiungibili ma principalmente per le impostazioni del benchmark come alta QD e tanti thread, poi ci sono benchmark specifici e altri fattori.

Originariamente inviato da @Liupen

Forse, ma controlla che vado a memoria, la nCache 3.0 è una pSLC con una parte statica e una dinamica, mentre la versione 4.0 per le QLC è poi solo dinamica.

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).

[@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

[@Liupen]

Vorrei spiegare il collo di bottiglia, ma alla fine scrivo tanto, troppo e mi sembra poi che il concetto non si capisca:

Esempio di prima, i Thread sono le istruzioni per farmi vedere su schermo un file di testo; Windows/host lancia tutte le istruzioni, DMA le ordina per priorità (esempio dice: prima di andare a cercare il file devo lanciare Microsoft Word). Questo a livello ..."alto"? Davvero infatti il DMA ordina una serie di richieste I/0 (dei vari Thread) in modo che: quando sono finiti tutti gli I/O (LBA sempre eh!) che compongono il "lancio Microsoft Word" posso iniziare a processare le richieste I/0 di "cerco e apro il file richiesto".

Detto questo per dire che per l'host/DMA i thread alla fine sono aria fritta e che il tutto è solo un ordine martellante di richieste (ordinate) I/0, il DMA "sente" se è collegato a SATA o NVME. SATA/AHCI ha dei limiti nel tenere delle code dei comandi quindi il DMA frena. Se il limite di queue depth è raggiunto, le ulteriori richieste restano in sospeso finché il controller non libera risorse.
NVMe ha semplicemente più “linee” di comunicazione e le risorse hardware che il controller può effettivamente gestire in parallelo.

[Black (Wooden Law)]

Originariamente inviato da @Liupen

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.

Ok, capisco. Quindi alla fine Windows crea e "organizza" i thread comunicando all'SSD quando sono pronti, e una volta pronti glieli dà da eseguire, giusto?

Originariamente inviato da @Liupen

Comunque, per il numero massimo di QD per thread, TechTarget dice:


queue depth = richieste I/0

E' giusto, perchè idee confuse?

Perché non capisco cosa voglia dire TechTarget con "coda di comando" visto che gli NVMe ne possono supportare migliaia di migliaia mentre i dispositivi SATA e SAS solo una.

Originariamente inviato da @Liupen

Detto questo per dire che per l'host/DMA i thread alla fine sono aria fritta e che il tutto è solo un ordine martellante di richieste (ordinate) I/0, il DMA "sente" se è collegato a SATA o NVME. SATA/AHCI ha dei limiti nel tenere delle code dei comandi quindi il DMA frena. Se il limite di queue depth è raggiunto, le ulteriori richieste restano in sospeso finché il controller non libera risorse.
NVMe ha semplicemente più “linee” di comunicazione e le risorse hardware che il controller può effettivamente gestire in parallelo

Ok, così mi è più chiaro il tuo "L’unità minima di comunicazione fra host (DMA) e controller è il comando I/O". Molto interessante anche questa parte sul perché la QD è più "importante" dei thread.

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Ok, capisco. Quindi alla fine Windows crea e "organizza" i thread comunicando all'SSD quando sono pronti, e una volta pronti glieli dà da eseguire, giusto?

Giustissimo.
Diciamo che la parte che interessa l'ssd è quella finale di un processo complesso.
Con un po di logica è possibile però cercare di capire il meccanismo che porta a concetti come I/0, latenza, ECC.

Se vogliamo dare una sequenza:

1. Comando Host (io che chiedo a Windows di aprire il file di testo PIPPO)
2. CPU di sistema elabora cosa fare in sequenza per ottenere il risultato
3. Istruzioni passate a DMA
4. DMA ha verificato a monte che protocollo usare --> sata/ahci passano "solo" 32 comandi alla volta invece nvme ne può gestire a migliaia.
5. DMA (in forma di pacchetti richieste I/0 LBA) stabilisce le priorità di queste richieste o comandi I/0 [come vedi tutto internamente all'host]
6. DMA comunica con il controller dell'ssd e gli invia la lista delle priorità QD da mettere in RAM oppure da scrivere su NAND (lettura e/o scrittura)
7. Il Controller gestisce i thread (se ce ne più d'uno) a seconda della propria capacità e della larghezza di banda (il famoso collo di bottiglia sata vs nvme) quindi un controller di un ssd nvme può svolgere 2 o più thread assieme ma seguendo il QD creato dal DMA.
8. Finito ogni thread (sequenza richieste I/0 lettura del blocco all'indirizzo dell'LBA cercato nel nostro esempio e trascritto in RAM di sistema) il controller comunica "eseguito" al DMA che può proseguire con le richieste successive.

Normalmente con un utilizzatore si vedono solo richieste I/0 in fila perchè una è propedeutica ad un altra.
Più richieste host creano gruppi di comandi diversi (thread) ed è li che nvme ha il maggiore vantaggio grazie all'elaborazione di più richieste I/0 di trhead eseguite in parallelo.

Originariamente inviato da Black (Wooden Law)

Perché non capisco cosa voglia dire TechTarget con "coda di comando" visto che gli NVMe ne possono supportare migliaia di migliaia mentre i dispositivi SATA e SAS solo una.


Ok, così mi è più chiaro il tuo "L’unità minima di comunicazione fra host (DMA) e controller è il comando I/O". Molto interessante anche questa parte sul perché la QD è più "importante" dei thread.

AHCI: una sola queue, profondità massima 32 comandi pendenti.

L’host può avere al massimo fino a 32 comandi pendenti nella sua unica coda.
Se prova a inviarne il 33esimo prima che uno dei primi 32 sia completato, deve aspettare.

E' la differenza tra sata e pcie: sata gestisce un unica coda alla volta (scrivo oppure leggo) e quella coda può avere "solo" 32 richieste I/0
NVMe è un 5G ha la banda larga... può scrivere e leggere in un solo tempo e ognuna di queste migliaia può essere costituita da migliaia di richieste I/0 accodate (il controller di suo non arriverà mai a fornirgliene così tante, ne avrebbe senso perchè le die nand sono un numero esiguo).

[@Liupen]

Può sorgere la domanda: come mai non è il controller dell'ssd a gestirsi le QD?

Perchè la mente, "l'architetto" è il sistema operativo; la CPU di sistema organizza e muove i dati per realizzare quello che l'host vuole.
C'è un tempo in cui le risorse devono essere organizzate e la sequenza la sà solo l'host che non deve e non può essere in balia di una memoria non volatile che ha caratteristiche varie (hdd PATA, hdd SATA, ssd SATA, ssd NVMe, USB... ecc).
Solo l’host conosce il contesto d’uso complessivo (quali processi, quali file, quali priorità), mentre il controller vede solo singole operazioni di flash.

Il "disco" in generale è solo quindi una rotella dell'ingranaggio, un esecutore che deve essere gestito a monte.

Altro motivo sono i limiti, appunto, delle interfacce varie.
Alcune, come ad esempio quella USB, neanche ai giorni nostri, hanno accesso completo e sono compatibili a tutti i tipi di comandi host (hanno profondità di coda più limitate a causa del protocollo e dell’overhead aggiuntivo).

[Black (Wooden Law)]

Originariamente inviato da @Liupen

AHCI: una sola queue, profondità massima 32 comandi pendenti.

L’host può avere al massimo fino a 32 comandi pendenti nella sua unica coda.
Se prova a inviarne il 33esimo prima che uno dei primi 32 sia completato, deve aspettare.

E' la differenza tra sata e pcie: sata gestisce un unica coda alla volta (scrivo oppure leggo) e quella coda può avere "solo" 32 richieste I/0
NVMe è un 5G ha la banda larga... può scrivere e leggere in un solo tempo e ognuna di queste migliaia può essere costituita da migliaia di richieste I/0 accodate (il controller di suo non arriverà mai a fornirgliene così tante, ne avrebbe senso perchè le die nand sono un numero esiguo).

Ok perfetto, capito, SATA può gestire solo una coda profonda massimo 32 richieste I/O mentre NVMe 65.000 code profonde massimo 65.000 richieste I/O (circa). Ecco il perché NVMe è nettamente più performante (ma fa ridere il fatto di questa enorme capacità quando in uso normale Windows non sfora QD4).

Originariamente inviato da @Liupen

Può sorgere la domanda: come mai non è il controller dell'ssd a gestirsi le QD?

Perchè la mente, "l'architetto" è il sistema operativo; la CPU di sistema organizza e muove i dati per realizzare quello che l'host vuole.
C'è un tempo in cui le risorse devono essere organizzate e la sequenza la sà solo l'host che non deve e non può essere in balia di una memoria non volatile che ha caratteristiche varie (hdd PATA, hdd SATA, ssd SATA, ssd NVMe, USB... ecc).
Solo l’host conosce il contesto d’uso complessivo (quali processi, quali file, quali priorità), mentre il controller vede solo singole operazioni di flash.

Il "disco" in generale è solo quindi una rotella dell'ingranaggio, un esecutore che deve essere gestito a monte.

Altro motivo sono i limiti, appunto, delle interfacce varie.
Alcune, come ad esempio quella USB, neanche ai giorni nostri, hanno accesso completo e sono compatibili a tutti i tipi di comandi host (hanno profondità di coda più limitate a causa del protocollo e dell’overhead aggiuntivo).

Chiaro, alla fine la mente è il SO/l’host e l’SSD il braccio. L’SSD è intelligente ma solo per le sue operazioni (WL, GC, gestione NAND flash, ecc.), rispetto al resto del contesto come SO e CPU è stupido.