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.

[Black (Wooden Law)]

Controller da 16 canali, NAND flash eTLC di SK hynix da 176L e un condensatore da 35 V per il PLP... https://www.techpowerup.com/review/p...pascari-x200e/.
Mi fa ridere questo:

Mentre non è stato in grado di raggiungere i 3,2 milioni di IOPS [in lettura randomica] da specifica è stato in grado di superare i 3,4 milioni di IOPS a queue depth più alte di QD512.

Ma le performance sono comunque ottime e l'SSD non è assolutamente deludente, anzi, in random batte anche il Memblaze PBlaze 7940 che usa 11 core (!) e le B58R da 6 piani.

[NubCake]

Vi segnalo che su Ediloca EN870 e Fanxiang S880 (e probabilmente anche Fikwot FN955) sono state cambiate le NAND.

Ho ricevuto oggi da Amazon un EN870, ordinato come nuovo ma si tratta probabilmente di un reso dato che l'heatspreader era piegato e parzialmente sollevato in corrispondenza della NAND, cosa che mi fa pensare che qualcuno lo abbia fatto per leggere le incisioni e poi abbia deciso di restituirlo.

maxio_nvme_fid non riconosce il controller e la NAND, a giudicare da un post che ho trovato sul S880 pare che il controller sia ancora il MAP1602 ma che non venga riconosciuto perché è stata attivata la crittografia del firmware.

La NAND presenta la seguente incisione:

LELM512G6BCB1E LP2510A186 31501 XF12 T9RM09

Cercando su internet non si trova nulla riguardo questa NAND, ma qualcuno altrove ipotizzava potesse essere X3-6070 quindi QLC.

Penso che farò il reso, peccato.

[Black (Wooden Law)]

Originariamente inviato da NubCake

Vi segnalo che su Ediloca EN870 e Fanxiang S880 (e probabilmente anche Fikwot FN955) sono state cambiate le NAND.

Ho ricevuto oggi da Amazon un EN870, ordinato come nuovo ma si tratta probabilmente di un reso dato che l'heatspreader era piegato e parzialmente sollevato in corrispondenza della NAND, cosa che mi fa pensare che qualcuno lo abbia fatto per leggere le incisioni e poi abbia deciso di restituirlo.

maxio_nvme_fid non riconosce il controller e la NAND, a giudicare da un post che ho trovato sul S880 pare che il controller sia ancora il MAP1602 ma che non venga riconosciuto perché è stata attivata la crittografia del firmware.

La NAND presenta la seguente incisione:

LELM512G6BCB1E LP2510A186 31501 XF12 T9RM09

Cercando su internet non si trova nulla riguardo questa NAND, ma qualcuno altrove ipotizzava potesse essere X3-6070 quindi QLC.

Penso che farò il reso, peccato.

Ciao, ho visto e risposto al tuo commento su Discord (sono io quello che ti ho detto che il MAP1602 fa crittografia dei dati per il FID) ma è corretto dirlo anche qui: non abbiamo certezze al 100% che sia QLC e quindi vedo insensato fare terrorismo mediatico. Gabriel ha detto che secondo lui il flash è QLC solo perché le NAND flash TLC vengono solitamente riconosciuto dal FID ma il problema è che anche per altri SSD che sono TLC non viene mostrato nulla quindi non la trovo una prova concreta al 100%. Servirebbero altre prove, quindi altri EN870 scoperchiati dai quali si può ottenere un S/N “sensato”.

Io, personalmente, non starei lontano all’EN870 visto che non ci sono prove ma al massimo si può consigliare l’S880 o l’FN955. L’S880 è TLC verificato da recensioni anche recenti, non so il perché tu abbia detto sia EN870 che S880.

[NubCake]

Ciao Black (Wooden Law), ti ringrazio per l'aiuto su Discord, non cercavo di fare "terrorismo mediatico" ma solamente di informare sullo scorretto (anche se ormai è la prassi per il settore) cambiamento silente della NAND, per evitare che qualcuno, così come ho fatto anche io, acquistasse quei determinati prodotti con la convinzione di ricevere una determinata combinazione di controller + NAND, spinto dalle informazioni trovate in rete ormai non più corrette.

Infatti ho scritto che non si trovava nulla in rete riguardo le nuove NAND, e ho aggiunto che qualcuno aveva ipotizzato che potesse trattarsi di X3-6070, senza riportare nessuna certezza.

Mi dispiace che il tutto sia stato frainteso e se necessario edito il precedente messaggio.

Però ci tengo anche anche a riportare un mio personalissimo pensiero: se alcuni produttori hanno iniziato a limitare la possibilità di riconoscere il controller e le NAND installate attraverso i noti tool, non lo avranno fatto di certo per scopi benevoli.

Io, personalmente, non starei lontano all’EN870 visto che non ci sono prove ma al massimo si può consigliare l’S880 o l’FN955. L’S880 è TLC verificato da recensioni anche recenti, non so il perché tu abbia detto sia EN870 che S880.

Lo ho scritto perché su altri forum ho trovato utenti che hanno ricevuto SSD con NAND con il medesimo codice o codice simile.

Questo è il link che probabilmente hai già visto, dove un utente ha ricevuto un Fanxiang S880 da 2TB con gli stessi moduli NAND dell'Ediloca EN870 1TB da me ricevuto

Continuando la ricerca stasera ho però trovato altri post:
Link 1 - Un utente ha ricevuto a febbraio la versione da 4TB del s880, con moduli nand da 1TB e codice un po' diverso LTLM01TB5BCB5. Ha anche pubblicato lo screen di AIDA64 che dimostra che dovrebbero essere comunque moduli TLC.
Link 2 - Un altro utente ha ricevuto la versione da 2TB, sempre con gli stessi moduli sconosciuti da 1TB.
Link 3 - Vari commenti riguardanti sia S880 che EN870. #44 segnala di aver ricevuto EN870 4TB con i moduli LTLM01TB5BCB5 LP2434A170, #57 ha pubblicato le foto del PCB, #90 stessa cosa e sui moduli c'è un adesivo che riporta la dicitura B58R, così come #800, #236 ha ricevuto un S880 con i suddetti moduli da 1TB.
Link 4 - #593 EN870 2TB con 3dv4-128L(x3-9060) anzi che x3-9070
Link 5 - #32 EN870 1TB con 3dv4-128L(x3-9060) anzi che x3-9070, #57 EN870 4TB con le NAND B58R già a novembre
Link 6 - #846 Fikwot FN955 2TB con 3dv4-128L(x3-9060)

A questo punto, i misteriosi moduli da 1TB se ci si può fidare degli adesivi, dovrebbero essere dei Micron B58R? Faranno parte della stessa famiglia anche i 512GB?

Grazie ancora per l'aiuto.

Edit: continuo ad aggiungere link alle fonti edittando questo post
Edit2: Ipotesi mia, probabilmente la NAND da 512GB non è una Micron B58R, avendo footprint diversi...

[Black (Wooden Law)]

Non ti preoccupare NubCake, non devi assolutamente editare alcun messaggio anche perché non sono qui per fare il dittatore, semplicemente ho trovato inadatto il tuo “Vi segnalo che su Ediloca EN870 e Fanxiang S880 […] sono state cambiate le NAND” su una base speculativa e fuorviante di Gabriel Ferraz. Provo tanta stima verso quel ragazzo anche perché è diventato recensore e creatore del DB di TPU in poco tempo, però anche lui stesso a volte sbaglia e dire che il tuo ex-EN870 usi NAND flash YMTC X3-6070 solo perché i dati sono criptati lo trovo abbastanza stupido o perlomeno incompleto. Magari ha ragione eh (anche se le fonti che mi hai mandato non provano questo), ma non basta per esserne sicuri al 100%.

Però ci tengo anche anche a riportare un mio personalissimo pensiero: se alcuni produttori hanno iniziato a limitare la possibilità di riconoscere il controller e le NAND installate attraverso i noti tool, non lo avranno fatto di certo per scopi benevoli.

Ragionamento legittimo, il fatto è che ci sono anche produttori “affidabili” come Silicon Power e Lexar che usa la crittografia del MAP1602 per il FID. Questa disponibilità di criptare i dati sembra essere una feature del MAP1602 (che non son sicuro abbiano anche gli altri controller) quindi non varia dal produttore.

Questo è il link che probabilmente hai già visto, dove un utente ha ricevuto un Fanxiang S880 da 2TB con gli stessi moduli NAND dell'Ediloca EN870 1TB da me ricevuto

Continuando la ricerca stasera ho però trovato altri post:
Link 1 - Un utente ha ricevuto a febbraio la versione da 4TB del s880, con moduli nand da 1TB e codice un po' diverso LTLM01TB5BCB5. Ha anche pubblicato lo screen di AIDA64 che dimostra che dovrebbero essere comunque moduli TLC.
Link 2 - Un altro utente ha ricevuto la versione da 2TB, sempre con gli stessi moduli sconosciuti da 1TB.
Link 3 - Vari commenti riguardanti sia S880 che EN870. #44 segnala di aver ricevuto EN870 4TB con i moduli LTLM01TB5BCB5 LP2434A170, #57 ha pubblicato le foto del PCB, #90 stessa cosa e sui moduli c'è un adesivo che riporta la dicitura B58R, così come #800, #236 ha ricevuto un S880 con i suddetti moduli da 1TB.

Disamina molto interessante NubCake, ti ringrazio delle fonti e delle informazioni generali, sono molto preziose. A quanto pare non c’è traccia di NAND flash QLC anche se avrei preferito vedere delle NAND flash EET1A al posto delle B58R per la questione binning.

A questo punto, i misteriosi moduli da 1TB se ci si può fidare degli adesivi, dovrebbero essere dei Micron B58R? Faranno parte della stessa famiglia anche i 512GB?

Impossibile da dire purtroppo ma sui tagli così piccoli sicuramente le NAND flash sono TLC, quelle QLC vengono adottate in tagli più grandi come 4TB (vedere il Patriot Viper VP4300 Lite per esempio)

[sbaffo]

che mi dite dell'Orico D10 ? qui dice TLC:
https://www.amazon.it/dp/B0DLG1S1Q3/...kCode=ogi&th=1
ma su TPU quel modello non c'è, e il prezzo sembra troppo buono per un 2TB (95eu)

[Black (Wooden Law)]

Originariamente inviato da sbaffo

che mi dite dell'Orico D10 ? qui dice TLC:
https://www.amazon.it/dp/B0DLG1S1Q3/...kCode=ogi&th=1
ma su TPU quel modello non c'è, e il prezzo sembra troppo buono per un 2TB (95eu)

In Giappone arriva con due versioni: la prima ha un controller indecente (SM2263XT) e delle NAND flash SK hynix V7 (176L) di scarto, la seconda ha un controller decente (MAP1202) e delle NAND flash SpecTek B58R di scarto (addirittura ci sono delle “cancellazioni” del S/N sul package) mentre in Russia il modello da 256GB arriva con un controller PCIe 3.0 x2 mai sentito (SM2261XT) e delle NAND flash con sopra un S/N totalmente sconosciuto e non identificabile (anche se dalle performance sembrano essere chiaramente delle TLC).

Direi che come SSD fa piuttosto schifo ed è assolutamente da evitare, ma il colpo di grazie ce lo dà la prima recensione giapponese: il package dell’SSD dice “SM2263ENG” non “SM2263XT”, anche perché la versione “ENG” ha il supporto della DRAM, quindi perché il FID lo riconosce come “SM2263XT”? Semplice, è una falsa incisione e la prova ce lo dà il fatto che l’SSD sia DRAM-less nonostante a bordo abbia un controller che dovrebbe supportare la DRAM.

[NubCake]

Originariamente inviato da sbaffo

che mi dite dell'Orico D10 ? qui dice TLC:
https://www.amazon.it/dp/B0DLG1S1Q3/...kCode=ogi&th=1
ma su TPU quel modello non c'è, e il prezzo sembra troppo buono per un 2TB (95eu)

Lo avevo preso in considerazione anche io poi lo ho scartato.

Cerca la parola QLC tra le recensioni su Amazon, e ti mostrerà diverse recensioni della variante da 1TB in cui gli acquirenti su Amazon.jp si lamentano del fatto che le NAND sono state sostituite da QLC Intel nonostante il modello sia venduto dichiarando espressamente l'utilizzo di TLC.

Potrebbe essere solo una questione regionale, ma considerato che ORICO non si pone problemi ad effettuare cambiamenti neanche nei modelli di "fascia alta", se acquisti fallo con la consapevolezza che il prodotto potrebbe non rispettare le caratteristiche dichiarate e verifica appena ti arriva.

[Black (Wooden Law)]

Originariamente inviato da NubCake

Cerca la parola QLC tra le recensioni su Amazon, e ti mostrerà diverse recensioni della variante da 1TB in cui gli acquirenti su Amazon.jp si lamentano del fatto che le NAND sono state sostituite da QLC Intel nonostante il modello sia venduto dichiarando espressamente l'utilizzo di TLC.

Che poi la cosa divertente è che non sono manco NAND flash QLC native ma sono NAND flash QLC emulate dalle Intel 192L PLC, quindi sono delle PLC in pQLC. Performance e durata dovrebbero essere pari alle QLC native ma fa comunque ribrezzo.

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Che poi la cosa divertente è che non sono manco NAND flash QLC native ma sono NAND flash QLC emulate dalle Intel 192L PLC, quindi sono delle PLC in pQLC. Performance e durata dovrebbero essere pari alle QLC native ma fa comunque ribrezzo.

E' antieconomico fare questo più che altro.

[Black (Wooden Law)]

Originariamente inviato da @Liupen

E' antieconomico fare questo più che altro.

Dici questo perché non ha senso prendere delle NAND flash PLC da far operare per tutta la loro vita in pQLC o per altro?

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Dici questo perché non ha senso prendere delle NAND flash PLC da far operare per tutta la loro vita in pQLC o per altro?

Anche, ma non solo; sono celle ancora costose perchè la tecnologia di produzione unica ha richiesto un investimento iniziale ingente (floating gate Solidigm di nuova generazione). Questo costo di know-out di produzione sarebbe ammortizzato dall'uso in PLC (cioè con il 20% di densità in più per bit) e dalla grande quantità di forniture.
Manca l'una e l'altra.
Usandolo QLC significa perdere denaro.
Il problema principale delle PCL, avevo letto, stà essenzialmente che i 32 livelli di tensione richiedono ECC importante ed un calo della velocità di lettura anche, e/o un rischio ancora troppo elevato di perdere dati. QLC o pQLC rimane in "confort zone".