SSD: thread generale e consigli per gli acquisti

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Che poi nello stesso pdf, frase dopo dice che non è certo dell'aumento

Infatti nel documento scrivono “may” all’inizio che vuol dire “potrebbe” o comunque esprime una possibilità. Comunque dicono che se i dati non vengono toccati prima del folding l’aumento del WAF è di 2 (!) mentre se vengono riscritti o viene fatta qualche altra azione l’aumento del WAF è di 0.

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Infatti nel documento scrivono “may” all’inizio che vuol dire “potrebbe” o comunque esprime una possibilità. Comunque dicono che se i dati non vengono toccati prima del folding l’aumento del WAF è di 2 (!) mentre se vengono riscritti o viene fatta qualche altra azione l’aumento del WAF è di 0.

Sto facendo il modello grafico ma già mi sono scoraggiato dalla quantità di cose da considerare... ahahah!
Ci provo ma ci va un po di tempo.

https://ibb.co/GQYz7g7d

Intanto googolando quà diciamo che molte conclusioni le avete raggiunte: https://www.techpowerup.com/forums/t...0/page-3#posts

il testo dice esattamente

L'accelerazione dinamica della scrittura può contribuire al WAF poiché i dati possono essere prima scritti come SLC e successivamente riscritti come MLC. L'entità della differenza nel WAF è un fattore additivo compreso tra zero e due, a seconda delle condizioni di runtime. A condizione che si verifichino condizioni tali che un dato utente venga scritto come SLC e non venga né tagliato né riscritto prima della successiva migrazione a MLC, il fattore additivo nel WAF per tali dati sarebbe due. Se i dati utente sono stati riscritti o ridotti prima della migrazione da SLC a MLC, o se i dati sono stati originariamente scritti come MLC (come nel caso di carichi di lavoro sostenuti), il fattore additivo per tali dati sarebbe zero.

Compreso tra 0 e 2 (solo impatto WA del pSLC) perchè va da:
scrivo direttamente in celle MLC, quindi è zero
a:
scrivo in SLC e poi copiato/fold in MLC quindi ricopio scrivendo 2 volte il dato.

Esempio: devo scrivere 1GB di dati, quindi

Write host = 1 GB = 1

su ssd con pSLC (cache di scrittura):

Write NAND = 1 GB (su pSLC) + 1 GB (fold su MLC) = 2 GB = 2

WA = Write NAND / Write host = 2 / 1 = 2


Se il dato viene trimmato vuol dire che viene fissato li, rimane in SLC e mappato li. Allora non avvenendo la copia/fold la WA a causa di pSLC rimane zero.
Se il dato viene cancellato/invalidato, prima della mappatura e prima della copi/fold la WA a causa di pSLC rimane zero.

[unnilennium]

segnalo su amaz Fikwot FN955 2TB M.2 a 113.99 dovrebbe essere tra i consigliati se non sbaglio... rispetto al 530r come si comporta?

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Se il dato viene trimmato vuol dire che viene fissato li, rimane in SLC e mappato li. Allora non avvenendo la copia/fold la WA a causa di pSLC rimane zero.
Se il dato viene cancellato/invalidato, prima della mappatura e prima della copi/fold la WA a causa di pSLC rimane zero.

Top, direi tutto interessantissimo e su cui concordo. Poi oggi mi rileggo per bene tutta la discussione visto che ci sono dei punti molto interessanti e che vorrei ricordarmi.

Comunque, per inibire una cache SLC (visto che l’hai scritto in tuo commento prima di questo) dovresti usare un MPTool disattivandola manualmente, proprio come ha fatto Gabriel Ferraz su un Pichau Aldrin Pro (IG5236 con CDT1B):

Selezionando ‘Pure XLC,’ la ‘X’ rappresenta la NAND nella sua forma nativa, come TLC, MLC o QLC nativo.

Il problema è che gli MPTool sono software difficili da ottenere per alcuni controller e se non fai le cose fatte per bene potresti mandare in paradiso l'SSD. O magari anche se fai le cose fatte per bene lo potresti mandare, quindi son cose abbastanza rischiose da fare.

Originariamente inviato da unnilennium

segnalo su amaz Fikwot FN955 2TB M.2 a 113.99 dovrebbe essere tra i consigliati se non sbaglio... rispetto al 530r come si comporta?

Peggio, ovviamente, ma il 530R ha controller migliore, la DRAM e anche un prezzo maggiorato di 57 euro (costa 171 euro nel taglio da 2TB). Ciò non mette in cattiva luce l'FN955, semplicemente lo metto sotto di un gradino.

Personalmente non comprerei il 530R da 2TB neanche sotto tortura, il prezzo è troppo elevato rispetto ai suoi competitor nella stessa fascia di prezzo, guarda per esempio il P41 che ritengo superiore e che costa soltanto 143 euro. Però valuta anche se ti serve effettivamente un SSD DRAM-based: se l'uso è leggero con sopra SO, programmi, giochi, ecc., vai di FN955 altrimenti se l'uso è più impegnativo vai con il P41. Se l'uso è soltanto giochi o secondario neanche sto a dirlo, FN955 tutta la vita.

[Black (Wooden Law)]

Buona notizia (forse) per chi cerca SSD SATA: SK hynix annuncia il Silver S32 (successore del Gold S31) e l’NVMe P42 SSD Gen4 di fascia medio-bassa (5 GB/s in lettura). Qui la notizia.

L’S32 usa come controller l’SM2259XT (lo stesso del BX500) e NAND flash TLC (probabilmente le SK hynix V7 da 176L) mentre il P42 sempre NAND flash TLC V7 ma il controller Phison E21T che abbiamo visto su tanti SSD come il P3 e il P3 Plus, l’NV2, l’UD90, ecc. Non capisco la scelta di chiamare questo SSD “P42” facendolo intendere come successore del P41 ma vabbè.

Gli MSRP sono indecenti, $97/TB il P42 e $93/TB l’S32, ma se dovesse arrivare in Italia l’S32 lo recensirei molto probabilmente. Volevo fare lo stesso l’E55 di Silicon Power ma purtroppo non è spedito in Italia tramite il sito ufficiale (e su Amazon non è presente).

[sbaffo]

Originariamente inviato da Black (Wooden Law)

Buona notizia (forse) per chi cerca SSD SATA: SK hynix annuncia il Silver S32 (successore del Gold S31) e l’NVMe P42 SSD Gen4 di fascia medio-bassa (5 GB/s in lettura). Qui la notizia.

L’S32 usa come controller l’SM2259XT (lo stesso del BX500) e NAND flash TLC (probabilmente le SK hynix V7 da 176L) mentre il P42 sempre NAND flash TLC V7 ma il controller Phison E21T che abbiamo visto su tanti SSD come il P3 e il P3 Plus, l’NV2, l’UD90, ecc. Non capisco la scelta di chiamare questo SSD “P42” facendolo intendere come successore del P41 ma vabbè.

Gli MSRP sono indecenti, $97/TB il P42 e $93/TB l’S32, ma se dovesse arrivare in Italia l’S32 lo recensirei molto probabilmente. Volevo fare lo stesso l’E55 di Silicon Power ma purtroppo non è spedito in Italia tramite il sito ufficiale (e su Amazon non è presente).

Da ciò che dici il p42 sembra inferiore al P41.
Però il marketting insegna che vale tutto pur di fregare i poll... ehm clienti.

[Black (Wooden Law)]

Originariamente inviato da sbaffo

Da ciò che dici il p42 sembra inferiore al P41.

Lo è, infatti io l'avrei chiamato "P41 Lite" piuttosto.
----------------------------------------------------------
Escono le prime recensioni dell'SSD teoricamente più veloce sul mercato: l'SN8100. 14,9 GB/s in sequenziale e 2,3 milioni di IOPS in random...
Stessa configurazione del G5 ovvero SM2508 e NAND flash Kioxia BiCS8 TLC ma con performance migliori. Come mai? John di TweakTown dice:

Il nuovo SanDisk WD Black SN8100 2TB è un altro controller SMI SM2508 con BiCS8, molto simile al Kingston Fury Renegade G5 4TB che abbiamo recensito ieri. [...] Mentre il controller dell'SN8100 è tecnicamente basato sull'SM2508, è differente da tutti gli altri perché è stato modificato da SanDisk eseguendo l'IP SanDisk con feature proprietarie come nCache 4.0 e WD Black Gaming Mode fornendo un gran vantaggio su concorrenti configurati in modo simile. Questo SSD non è come gli altri, è almeno il 20% più potente di qualsiasi altro SSD basato su flash che abbiamo mai visto. Approcciando Optane.

Tralasciando l'ultima parte visto che questo SSD è lontano da Optane e il 20% è assolutamente falso, a quanto pare Sandisk ottimizzando il firmware è in stata in grado di spremere completamente le BiCS8 fornendo performance superiori rispetto anche alle B68S che fanno 95 MB/s per die in più (motivo per il quale ho scritto "teoricamente"; aspetto recensioni "migliori" come quelle di Tom's Hardware).

[Black (Wooden Law)]

La recensione di ComputerBase (testata tedesca) dell'SN8100 da 2TB mostra che l'SSD è quasi un full-drive pSLC (nel taglio da 2TB ha probabilmente una cache SLC che si aggira sui 600GB) e che in direct-to-TLC fa circa 3.500 MB/s mentre in folding 1.500-2.000 MB/s. Direi degli ottimi numeri paragonandoli al cugino Fury Renegade G5.

Personalmente metto l'SN8100 sopra a tutti gli SSD Gen5 visti finora, sopra anche al re 4600.

[giovanni69]

WD_Black SN8100: è lui l'SSD M.2 più veloce del mondo?

[frafelix]

Bisogna vedere se gli altri gen5 si abbasseranno di prezzo

[Nicodemo Timoteo Taddeo]

Tutti i Gen5 si abbasseranno di prezzo come è sempre stato e sarà. Aumenta la competizione sul prezzo, i prezzi vengono via via segati per restare competitivi.

Il punto semmai è quando succederà? Quanto tempo ci vorrà prima che arrivino a livelli "accettabili" per la gran massa? Ma anche quando questi dispositivi diventeranno veramente utili per quasi tutti? Allo stato attuale posso dire senza tema di smentita che ben poche realtà hanno necessità di tanta velocità, ci sono colli di bottiglia che ne limitano l'influenza nelle prestazioni del computer, direi che tranne rari casi in cui la spesa è effettivamente giustificabile, al momento acquistarli è più un esercizio di celodurismo

E in quest'ottica ben ci stanno i led a bordo del dissipatore...

[Black (Wooden Law)]

Originariamente inviato da Nicodemo Timoteo Taddeo

Ma anche quando questi dispositivi diventeranno veramente utili per quasi tutti? Allo stato attuale posso dire senza tema di smentita che ben poche realtà hanno necessità di tanta velocità, ci sono colli di bottiglia che ne limitano l'influenza nelle prestazioni del computer, direi che tranne rari casi in cui la spesa è effettivamente giustificabile, al momento acquistarli è più un esercizio di celodurismo

Penso che non saranno mai utili per "quasi tutti", quindi anche per l'utente medio o quasi. Alla fine anche i Gen4 e i Gen3 non sono necessari per "quasi tutti" ma semplicemente ci siamo adeguati a comprarli e riempirci di loro per l'abbassamento dei prezzi.

Che i Gen5 piacciano o meno per il calore e tanti altri motivi sono il futuro come lo saranno i Gen6, i Gen7, ecc., quindi ci ritroveremo per forza di cose pieni di questi SSD nei nuovi sistemi.

[@Liupen]

Ho finito la simulazione sulla WA.
Risultato? La cache pSLC AUMENTA la scrittura in background delle celle.
Nel mio esempio con un ssd costituito da 3 soli blocchi e una pSLC totalmente dinamica (come gli nvme ora) il rapporto è stato di ca 1,5; non raddoppia ma sta li in mezzo.
Posso dire che il GC che crea il fold ha versi contrastanti ma chiari: la sequenzialità dei 4KB riduce le pagine occupate e quindi compatta i dati sui blocchi (riduzione leggera WAF) ma la copia totale delle scritture in pSLC non si può trascurare ed aumenta la scritture delle nand.

Quindi alla fine la velocità ci viene fatta pagare, fortunatamente questi nvme durano assai.
I pregi della cache di scrittura sono descritti da Newmaxx molto bene:

La modalità SLC offre numerosi vantaggi, inclusi alcuni elencati in precedenza in questa risposta più ampia. Ad esempio, la modalità SLC è molto meno soggetta a errori di trasferimento dati dovuti a interruzioni di corrente. Garantisce inoltre protezione durante lo spostamento dei dati sulla memoria flash nativa e migliora le prestazioni poiché è possibile bypassare l'ECC con il copyback (folding). L'amplificazione in scrittura è ridotta poiché il copyback è sequenziale, il che è uno dei motivi per cui alcuni brevetti suddividono i carichi di lavoro per tipo, ad esempio le scritture casuali su SLC, che tengono conto dell'ECC anche in base al tipo di dati (se non altro per motivi di efficienza). Questo significa che ci sono molte ragioni per cui i produttori di SSD utilizzano la modalità SLC, non solo per le prestazioni in scrittura, ma anche perché la modalità pSLC è più veloce in tR (e quindi viene spesso utilizzata per i metadati). Ci sono ragioni per preferire la tecnologia direct-to-TLC, come la generazione di calore, ma in realtà sembra che molti produttori limitino artificialmente la velocità nativa del flash, ad esempio con il nuovo SN550 (o TLC SN530), l'870 QVO di Samsung, il P5 Plus, ecc. Il che indica certamente che sono interessati a fare affidamento sulla tecnologia SLC. Le implicazioni sulla durata sono più difficili da descrivere a fondo, anche se non credo che l'usura del flash sia un problema serio in questo caso.


WD_Black SN8100: è lui l'SSD M.2 più veloce del mondo?

Secondo ogni produttore, al lancio, il proprio è meglio degli altri.
Sembra essere confermata la programmazione del SM2508 ad avere una cache enorme che "crolla" letteralmente quando finisce: strategia orientata agli utenti consumer che vedono un ssd brillante con i piccoli trasferimenti e una reattività da numero1. Nei bench lunghi e di scrittura aggressiva, questo crollo, compromette ovviamente tutto quello che di buono si vede prima.

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Ho finito la simulazione sulla WA.
Risultato? La cache pSLC AUMENTA la scrittura in background delle celle.
Nel mio esempio con un ssd costituito da 3 soli blocchi e una pSLC totalmente dinamica (come gli nvme ora) il rapporto è stato di ca 1,5; non raddoppia ma sta li in mezzo.
Posso dire che il GC che crea il fold ha versi contrastanti ma chiari: la sequenzialità dei 4KB riduce le pagine occupate e quindi compatta i dati sui blocchi (riduzione leggera WAF) ma la copia totale delle scritture in pSLC non si può trascurare ed aumenta la scritture delle nand.

Quindi alla fine la velocità ci viene fatta pagare, fortunatamente questi nvme durano assai.

Ottimo e non ottimo a sapere direi, nel senso che adesso abbiamo la conferma che effettivamente la cache SLC dinamica aumenta il WAF. Grazie mille del test Liupen, non posso far altro che aggiungere questo tuo commento in prima pagina.

Originariamente inviato da @Liupen

WD_Black SN8100: è lui l'SSD M.2 più veloce del mondo?

Secondo ogni produttore, al lancio, il proprio è meglio degli altri.
Sembra essere confermata la programmazione del SM2508 ad avere una cache enorme che "crolla" letteralmente quando finisce: strategia orientata agli utenti consumer che vedono un ssd brillante con i piccoli trasferimenti e una reattività da numero1. Nei bench lunghi e di scrittura aggressiva, questo crollo, compromette ovviamente tutto quello che di buono si vede prima.

Nel frattempo Phison ha ascoltato le nostre parole e se n'è uscita con il PCMark10 (test che odio e che trovo superstupido e irrilevante) più alto di sempre con l'E28:

Il punteggio PCMark 10 ha indicato che il Phison E28 ha avuto una performance significativamente superiori ai suoi competitori. è stato approssimativamente più veloce del 18% rispetto al Samsung 9100 Pro e al Micron 4600. Inoltre, il Phison E28 ha sorpassato il Predator GM9000 [SM2508 con B58R) del 32%.

[@Liupen]

Se però il WD ..ops Sandisk SN8100 risultasse in PCMark 10 il 15% più veloce del Samsung 9100 Pro?

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Se però il WD ..ops Sandisk SN8100 risultasse in PCMark 10 il 15% più veloce del Samsung 9100 Pro?

Si elimina quello scempio di PCMark 10 dalle recensioni.
Firmerei una petizione per farlo.

[giovanni69]

Originariamente inviato da @Liupen

WD_Black SN8100: è lui l'SSD M.2 più veloce del mondo?

Secondo ogni produttore, al lancio, il proprio è meglio degli altri.
Sembra essere confermata la programmazione del SM2508 ad avere una cache enorme che "crolla" letteralmente quando finisce: strategia orientata agli utenti consumer che vedono un ssd brillante con i piccoli trasferimenti e una reattività da numero1. Nei bench lunghi e di scrittura aggressiva, questo crollo, compromette ovviamente tutto quello che di buono si vede prima.

...come dire, se intendo bene, che se usato per cercare vantaggi prestazionali nelle clonazioni, potrebbe essere non molto diverso dai migliori Gen4 già esistenti.

[Black (Wooden Law)]

Originariamente inviato da giovanni69

...come dire, se intendo bene, che se usato per cercare vantaggi prestazionali nelle clonazioni, potrebbe essere non molto diverso dai migliori Gen4 già esistenti.

Dipende se la clonazione usa la cache SLC (e quindi fa scritture intensive), ma teoricamente sì, lo fa. Dopo la cache SLC tra il miglior PCIe 4.0 (il P41 secondo me) e un PCIe 5.0 ci passano più di 2 GB/s, anche se c'è da tener conto del taglio degli SSD, eventuale folding, ecc.

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Si elimina quello scempio di PCMark 10 dalle recensioni.
Firmerei una petizione per farlo.

Ecco, togli il bench del momento.. son tutti li a farlo, anche i cinesi l'hanno acquistato

Perchè ho visto la recensione di Techtesters
a far due conti matematici +15-16 ...ci si ritrova sempre con "siamo lì"

Originariamente inviato da giovanni69

...come dire, se intendo bene, che se usato per cercare vantaggi prestazionali nelle clonazioni, potrebbe essere non molto diverso dai migliori Gen4 già esistenti.

Si esatto. Non gli far fare scritture pesanti over cache (che si riduce poi al crescere del riempimento) ed è il numero unissimo.




Black butta un occhio a questo.

Molto semplicemente, la QD è il numero di richieste I/O che possono essere messe in coda contemporaneamente. Se abbiamo quindi una QD di 5 vuol dire che ci sono 5 richieste I/O nello stesso momento. I thread, invece, sono i thread della CPU e la definizione di “thread” è “una suddivisione di un processo in due o più filoni (istanze) o sottoprocessi” [10].
Se dovessi fare un esempio lo farei con delle persone e se il benchmark che stessimo andando ad eseguire fosse Q4T4 (quindi QD di 4 e 4 thread) vorrebbe dire che avremmo 4 persone (thread) che starebbero chiedendo 4 informazioni allo stesso momento (QD).
A maggiore QD e thread abbiamo maggiori performance; ecco svelato il motivo per il quale nelle operazioni “normali” (che per il 90% dei casi non superano una QD di 4 [11, pagina 12]) gli SSD che sono pubblicizzati come 14,9 GB/s ne fanno magari molti meno.
… ne fanno molti meno se i dati che stiamo scrivendo o leggendo sono sequenziali, però, ovvero i blocchi sono contigui uno all’altro al termine e inizio delle operazioni, altrimenti stiamo parlando di operazioni randomiche dove la velocità è molto più bassa. Per esempio, un’operazione sequenziale è costituita dalla fine del blocco 257 (numero completamente a caso) e l’inizio di quello 258, mentre un’operazione randomica è costituita dalla fine del blocco 355 e l’inizio del 122 (ricordandoci comunque che le operazioni di scrittura vengono eseguite a livello di pagina e non di blocco), quindi le operazioni randomiche sono per forza di cosa molto più lente. Il vantaggio per le operazioni sequenziali è ancora più maggiore se si parla di pagine nello stesso blocco: magari non serve passare dal 257 al 258 ma dalla pagina 25 del 257 alla pagina 26 del 257.



QD e Thread sono entrambe comandi (di lettura o scrittura) in I/0 operazioni al secondo verso l'ssd; SSD costituito come modello da controller (che elabora) e pacchetti NAND (che memorizzano il dato).
QD rappresenta la richiesta (comando) di lettura o scrittura contemporanee che il controller deve vagliare una a una, ma non essendo in grado di fare in contemporanea, mette in una coda più o meno organizzata. NCQ di AHCI supporta solo massimo 32 comandi, NVMe supporta migliaia di code parallele e decine di migliaia di comandi per coda.
Thread (la storia della cpu è una cagata che si trova online, bisogna spiegare la pipe PCIe/DMA, ma il concetto può essere molto semplice: i comandi vengono gestiti dal sistema operativo tramite protocollo AHCI e NVME) a differenza del singolo comando I/0, Thread è l'operazione (la stessa differenza dal dire una singola parola ripetuta 10 volte e dire una frase di 10 parole). Thread è un operazione un comando o istruzioni di tanti comandi I/0 quanti si vuole a realizzare una coda o no (se il comando è singolo), e che ha un inizio e un termine a cui il controller risponde alla fine con "eseguito!". Inoltre più thread possono essere sia di lettura che di scrittura contemporaneamente.


Tanto per schematizzare in modo supersintetico :

QD 8 = 1(realtime) + (coda) 0-0-0-0-0-1-1

3 Thread =[1-0-0-0-0-0-1-1](lettura) + [1-1-0-1](scrittura) + [1-0-0-0-0-0-1-1](lettura)

In Seq1M Q8T3 si utilizza un file da 1MiB (1024 KB) da leggere in 3 "pacchetti" ognuno contenete 8 comandi in coda.


Gli effetti di QD e Thread sono indicatori di qualcosa.

QD cioè il tempo, quindi la velocità di svolgimento dell'operazione è diretta conseguenza della capacità di elaborazione del controller dell'ssd.
Inoltre una coda bassa QD 1 ad esempio può essere proporzionalmente più lenta di una coda alta QD 32 ad esempio.
tipo un nvme con QD 1 in lettura di 55 MB/s sviluppa poi un QD 32 di 3000 MB/s, ma 55x32 ≠ 3000; il perchè è legato alla latenza. Coda alta assorbe il rallentamento della latenza iniziale ad eseguire il comando dato.

Thread invece è conseguenza diretta della capacità di controller e chip NAND di leggere o scrivere contemporaneamente (parallelismo).
Quando ho un ssd con un pacchetto di chip di memoria ho almeno 2 canali da sfruttare (in entrata e in uscita anche contemporaneamente). Quindi posso leggere il dato che mi serve o scriverlo come farebbe un array di dischi. Capacità del controller, firmware ben fatto, disponibilità di più pacchetti NAND, offrono un parallelismo maggiore e migliori prestazioni a parità di coda.


Temo che il motivo per cui: gli SSD che sono pubblicizzati come 14,9 GB/s ne fanno magari molti meno, sia perchè sono benchmark fatti su sistemi preparati ad hoc, su ssd secondari e con bench a cui si dà una priorità da OS (insomma le condizioni migliori) e quando normalmente non ci arrivano è per la fuffa da marketing.


Inoltre non è lo spostamento di indirizzo di pagine e blocco che determina la differenza di velocità tra dati casuali e dati sequenziali. E' molto vicino, si intuisce ma non è centrato.
Se si parla di indirizzi di mappatura logica, boh, non c'è differenza perchè cambiare un puntatore su SRAM (o RAM di sistema) di un qualsiasi valore è immediato.
Su SSD concettualmente anche; scrivere un dato su una cella su un altra, ecc, ovunque si trovi, è elettronicamente uguale per un controller.
La differenza di velocità di lettura e scrittura tra, esempio 1024 I/0 da 4K e 4 MB (256x4=4096KB=4MB) sta nella morfologia (grandezza) ma anche nel tipo di comando.

Anche in questo caso per farla molto supersintetica sulla scrittura che è più intuitiva:

Quando arriva 1 comando sequenziale da 4MB dall'host (Windows) il controller dell'ssd cancella 1 blocco NAND e scriverà successivamente il dato sulle pagine dell'intero blocco ad una velocità alta e costante.

Di contro quando arrivano comandi da 4K il controller non sa a priori quanti 4K saranno. Ogni volta che arriva un comando casuale il contoller cerca un blocco libero (se ssd è vergine e ne ha ancora) oppure dovrà fare Garbage Collection per liberare pagine per un numero imprecisato di 4K. Nel nostro esempio dati sequenziali da 1024 x 4K richiederanno più Garbage Collection e blocchi liberi del corrispettivo sequenziale.
Piccoli blocchi (4 KiB) spesso ricadono in pagine diverse e attivano più unità di parallelismo NAND con un overhead ma anche latenza assai maggiore del singolo trasferimento sequenziale.


Leggo anche qui:
- cache SLC ibrida: chiamata anche "TurboWrite" da Samsung e "nCache" da WD, la cache SLC ibrida è formata da una porzione di cache SLC statica e una porzione di cache SLC dinamica fondendo i due tipi insieme. Non ci sono numeri su quanto aumenti la durata questo tipo di cache SLC.

Non credo siano forme ibride di cache sono solo idee di cache diverse da quella che si è affermata poi (per semplicità pSLC).
nCache 2.0 è una cache direttamente sui die, in parte assorbono in SLC e poi trasferiscono in automatico sulla parte MLC (TLC/QLC)
nCache 3 e 4 è una pSLC statica + dinamica o solo dinamica (quella odierna)
Turbo Write è una cache creata via software opzionando la RAM di sistema (ma guarda...proprio l'idea dell' HMB ).
Idem Dynamic Wrtite di Micron..

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Thread (la storia della cpu è una cagata che si trova online, bisogna spiegare la pipe PCIe/DMA, ma il concetto può essere molto semplice: i comandi vengono gestiti dal sistema operativo tramite protocollo AHCI e NVME) a differenza del singolo comando I/0, Thread è l'operazione (la stessa differenza dal dire una singola parola ripetuta 10 volte e dire una frase di 10 parole). Thread è un operazione un comando o istruzioni di tanti comandi I/0 quanti si vuole a realizzare una coda o no (se il comando è singolo), e che ha un inizio e un termine a cui il controller risponde alla fine con "eseguito!". Inoltre più thread possono essere sia di lettura che di scrittura contemporaneamente. […] In Seq1M Q8T3 si utilizza un file da 1MiB (1024 KB) da leggere in 3 "pacchetti" ognuno contenete 8 comandi in coda.

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.

Originariamente inviato da @Liupen

Temo che il motivo per cui: gli SSD che sono pubblicizzati come 14,9 GB/s ne fanno magari molti meno, sia perchè sono benchmark fatti su sistemi preparati ad hoc, su ssd secondari e con bench a cui si dà una priorità da OS (insomma le condizioni migliori) e quando normalmente non ci arrivano è per la fuffa da marketing.

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

Originariamente inviato da @Liupen

Inoltre non è lo spostamento di indirizzo di pagine e blocco che determina la differenza di velocità tra dati casuali e dati sequenziali. E' molto vicino, si intuisce ma non è centrato.
Se si parla di indirizzi di mappatura logica, boh, non c'è differenza perchè cambiare un puntatore su SRAM (o RAM di sistema) di un qualsiasi valore è immediato.
Su SSD concettualmente anche; scrivere un dato su una cella su un altra, ecc, ovunque si trovi, è elettronicamente uguale per un controller.
La differenza di velocità di lettura e scrittura tra, esempio 1024 I/0 da 4K e 4 MB (256x4=4096KB=4MB) sta nella morfologia (grandezza) ma anche nel tipo di comando.

Anche in questo caso per farla molto supersintetica sulla scrittura che è più intuitiva:

Quando arriva 1 comando sequenziale da 4MB dall'host (Windows) il controller dell'ssd cancella 1 blocco NAND e scriverà successivamente il dato sulle pagine dell'intero blocco ad una velocità alta e costante.

Di contro quando arrivano comandi da 4K il controller non sa a priori quanti 4K saranno. Ogni volta che arriva un comando casuale il contoller cerca un blocco libero (se ssd è vergine e ne ha ancora) oppure dovrà fare Garbage Collection per liberare pagine per un numero imprecisato di 4K. Nel nostro esempio dati sequenziali da 1024 x 4K richiederanno più Garbage Collection e blocchi liberi del corrispettivo sequenziale.
Piccoli blocchi (4 KiB) spesso ricadono in pagine diverse e attivano più unità di parallelismo NAND con un overhead ma anche latenza assai maggiore del singolo trasferimento sequenziale.

Su questo hai completamente ragione al 100%, purtroppo sono rimasto che gli HDD sono più lenti con gli I/O randomici rispetto agli I/O sequenziali e ho applicato lo stesso concetto agli SSD, ma a seguito della stesura della prima pagina ho letto questo articolo di Code Capsule (che nonostante sia del 2014 dovrebbe essere ancora buono visto che non penso sia cambiato il pattern degli I/O randomici e sequenziali) che mi ha confermato il contrario: le scritture randomiche sono più lente di quelle sequenziali se hanno una dimensione piccola, altrimenti performano come le scritture sequenziali.

Originariamente inviato da @Liupen

Non credo siano forme ibride di cache sono solo idee di cache diverse da quella che si è affermata poi (per semplicità pSLC).
nCache 2.0 è una cache direttamente sui die, in parte assorbono in SLC e poi trasferiscono in automatico sulla parte MLC (TLC/QLC)
nCache 3 e 4 è una pSLC statica + dinamica o solo dinamica (quella odierna)
Turbo Write è una cache creata via software opzionando la RAM di sistema (ma guarda...proprio l'idea dell' HMB ).
Idem Dynamic Wrtite di Micron..

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

TurboWrite Technology creates a high-performance write buffer area within the drive that simulates high-performance SLC.

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.

Acceleration is achieved using on-the-fly mode, switching between SLC and MLC in the firmware to create a dynamic pool of high-speed SLC NAND blocks.