- Messaggi
- 84,591
- Reazioni
- 38,334
- Punteggio
- 253
il bello di chat GPT è che se non conosce una risposta se la inventa di sana pianta, oppure come dici te può essere "piegata" a dire quello che vuoi sentire
Pubblicità
DOMANDA Consiglio acquisto ssd M.2
- Autore discussione MidNight_
- Data d'inizio
Pubblicità
- Messaggi
- 32,110
- Reazioni
- 15,888
- Punteggio
- 254
beh anche se non ufficialmente vietate sarebbe il caso di postare quando le cose si sanno...
- Messaggi
- 12,184
- Reazioni
- 6,238
- Punteggio
- 208
Si, purtroppo è vero. Usa (l'AI) l'accondiscendenza ai propositi dell'interlocutore partendo da nozioni base giuste (come in questo caso il fatto che la lettura 4K 1QD ha la sua importanza nella rapidità o latenza di un OS) per generalizzare in ragionamenti generalisti e conclusioni che perdono il senso della misura (...allora l'ssd con il 4K in lettura più alto è il migliore).
Se @aluking ti fossi fermato al primo post
ti avrei detto: si in un certo senso hai ragione, anche se
1) confronti un ssd mediocre (Samsung 9100) con uno dei migliori ssd in circolazione (WD SN8100) anzi stiamo parlando di ssd che fanno la differenza.
2) trascuri i limiti tecnologici delle celle ma soprattutto i pareri di chi questi ssd li ha confrontati realmente per cui al di la dei numeri, le prestazioni reali non sono un "abisso" anzi, molti ssd mediocri poi hanno prestazioni reali indistinguibili (per altri aspetti).
Io ho sempre sostenuto che le prestazioni 4K a QD basse sono molto importanti per un ssd.
Non me lo sono potuto permettere ma avrei volentieri preso un ssd Optane giusto perchè massimizzando questo aspetto rende un sistema operativo installato sopra, parecchio più veloce.
L'errore più grande è però stato affidarti alla AI e non sviluppare quello che è stata un opinione di "uso" non di prestazioni, che ti ha contrapposto Black.
Tu hai detto che in un ssd bisogna non guardare le prestazioni sequenziali (che sono marketing, scrivi) e di guardare le prestazioni
perchè il 90% delle operazioni reali su un PC" sono queste.
Ma Black non ti stà dicendo che sbagli, ti dice (in contrapposizione al tuo "parere"...non dati), che l'utente medio noterà poco o niente il vantaggio dato dal 4K ramdonico, perchè le differenze di velocità reali, colte da un utente, in latenza, sono trascurabili (e lo dice chi li ha provati realmente), MENTRE la differenza di velocità sequenziale tra questi ssd, specie di diversa generazione pcie, si colgono eccome nei trasferimenti sequenziali. Allora, ti scrive che, considerare migliore un ssd nvme che fà 95MB/S in casuale rispetto ad uno che ne fà 70(MB/s) non sarebbe poi un punto di preferenza assoluta nel mondo d'uso reale.
Tutto quì ciò che ti è stato detto... ripeto, come PARERE (ancorché espresso, se segui THW, da una persona che di ssd se ne intende).
In seguito ti sei proprio letteralmente "fatto prendere in giro" dall'intelligenza artificiale che ti ha propinato nozioni corrette e conclusioni sbagliate.
Sei sicuro che un sistema operativo, nel suo uso, nell'aprire software, nell'uso di giochi, usi singoli comandi random da 4KB (QD1-2)?
Questo è realmente così, o è come ce l'hanno semplificata un po troppo i recensori?
Vedi ti mancano le basi che ti avrebbero permesso di mettere in forse quello che ti stava dicendo ChatGPT.
Si vede da questa frase:
L'accesso casuale 4KiB crea una coda o QD che già da dei risultati parecchio più veloci del bench sul singolo comando casuale da 4KiB.
Inoltre il cosiddetto sequenziale classico, pensa che è un file da soli 128 KiB, alcuni software propongono un sequenziale da 1024 KiB, ma se andiamo a vedere il DirectStorage su cui si basa l'accelerazione di caricamento dei giochi fatta per i ssd che hanno prestazioni sequenziali alte, le linee guida raccomandano che le richieste di lettura usino blocchi di almeno 32 KiB.
Capito! 32KiB sono già file sequenziali per Windows.
La frase “4K QD1/QD2 rappresenta lo scenario reale di Windows” è vera… ma solo in parte.
È una semplificazione che i recensori usano per rendere comprensibile un concetto giusto ma più sfumato.
Per capire: Windows genera tantissime operazioni casuali di piccole dimensioni (4–16 KiB).
La maggior parte di queste richieste è fatta da app e servizi che non mettono in coda molte operazioni, quindi QD1–QD4 molto bassa.
Ma In realtà l'imput I/0 reale è molto più vario nell'uso (tolto Windows in quanto OS) e oltre il 50% dei file trasferiti su RAM (letti) dai software utente sono più grandi di 32KiB.
In buona sostanza: dati di partenza giusti / tua conclusione troppo "netta" (non so se mi sono spiegato)
E' quello (importanza del 4K QD1-2) ma... non solo quello, c'è di più e più cose da considerare.
Altra cosa:
Invece il collo di bottiglia è proprio la linea pcie, perchè (MT/s delle celle permettendo) un controller sarebbe molto più veloce per ogni generazione di pcie.
Optane NON è confrontabile (per ovvi motivi).
Chi ha un sistema operativo su nvme forse, e dico forse, lo trova più veloce di un ssa sata ma di sicuro non distinguerebbe un ssd DRAM-less o no, e QLC o no.
L'ssd poi non è un auto soggetta ai limiti di velocità, con gli ssd puoi comprarti il più performante (il Porsche SN8100) ed essere sicuri di avere i trasferimenti più veloci sempre (anche se il costo non vale il tempo guadagnato).
In fondo hai ragione, tanti piccoli file impiegano più tempo a caricarsi di uno solo della stessa dimensione, ma questo non vuol dire che se il 4K di un ssd è più veloce, lo è l'ssd in assoluto.
Come dici, dipende da che uso se ne fà.
Un SN8100 è più veloce nel 4K di tutti gli altri?
Certo!
MA se con un SN850X o un Samsung 990 PRO si spende meno e si ottiene QUASI prestazioni indistinguibili, cosa è meglio consigliare?
Ultima modifica:
aluking
Nuovo Utente
- Messaggi
- 20
- Reazioni
- 2
- Punteggio
- 29
MA se con un SN850X o un Samsung 990 PRO si spende meno e si ottiene QUASI prestazioni indistinguibili, cosa è meglio consigliare?
in questo caso si quello piu economico io intendevo dire e da guarda re il 4k random
ADATA XPG Gammix S70 Blade 2TB o Western Digital WD_BLACK SN7100 2TB
consiglio questo se non ne ha gia comperato uno. che rientrano nel budget
premetto non avevo palle e tempo di scrivere questo pomeriggio e ho fatto scrivere..... cmq mi era piu rapido.
complimenti tu per aver scritto a mano ora lo faccio anche io.
intendevo che i 14000 MB o i 7000 MB sono marketing perche non li raggiungi a casa. in realta vai molto di meno. in questo senso e marketing.
e lo è vuoi dirmi che tu a casa col tuo m.2 nmve fai 14000 MB o 7000 col gen4? forse fai 9000 forse quando prendi un file e lo sposti non crystal disk mark e col 7000 fai 4000 forse 5000 in questo senso intendo che quei numeri sono marketing.
Invece il collo di bottiglia è proprio la linea pcie, perchè (MT/s delle celle permettendo) un controller sarebbe molto più veloce per ogni generazione di pcie.
SI E NO, NON è vero che il collo di bottiglia è la linea PCIe nelle operazioni reali (4K/32K/128K).
specifica ulteriormente SÌ, la banda PCIe diventa un collo di bottiglia SOLO nelle operazioni SEQUENZIALI pure, non nella reattività. quindi ma qui non ho mai testato un ssd 5.0 piu reattivo con 100mb in 4k li fa anche in pcie 4.0 secondo la teoria quindi e piu reattivo.
il collo di bottiglia e la cazz... di NAND che non ce la fa comunque, La micro-architettura del controller, il numero di canali paralleli, la DRAM.
la nand schifosa
80–150 µs (microsecondi) di latenza in lettura
200–800 µs in scrittura
la pcie invece
decine di nanosecondi (letteralmente 1000 volte più veloce)
mentre se devi spostare ogni giorno qualche tb all ora aspettiamo la pcie 6.0 o 7.0 e siamo tutti piu felici
Ultima modifica:
Real Black
Utente Èlite
- Messaggi
- 1,528
- Reazioni
- 792
- Punteggio
- 108
Tra l'SN850X e il 990 PRO? L'SN850X siccome ha performance migliori (anche se sono notabili soltanto in benchmark) e un prezzo più basso (il 990 PRO ha sempre avuto il prezzo più alto tra gli SSD PCIe 4.0 anche se in questo momento di carestia l'1TB ha un prezzo competitivo).
L'S70 Blade non è un buon SSD: usa come controller l'InnoGrit IG5236 e come NAND flash potrebbe usare le vecchie YMTC CDT1B (128L TLC) che sono un'accoppiata problematica. L'IG5236 è conosciuto per entrare casualmente nello stato "MN-5236" in cui l'SSD viene visualizzato da 2GB e al quale non è più possibile accederci (come se si rompesse) mentre le CDT1B sono conosciute per avere un disturbo di lettura eccessiva che ne causa la morte (e quindi la perdita dei dati ovviamente).
L'SN7100 è assolutamente un buon SSD, uno dei migliori DRAM-less tra i PCIe 4.0 ma costa quanto l'SN850X e non ne vale la pena visto che l'SN850X è più performante avendo la DRAM.
(P.S.: l'S70 Blade non esiste nel taglio da 2TB su Amazon)
Questo è giusto, son d'accordo con te: i produttori pompano le specifiche (ma non le falsificano, tutto ciò che scrivono è vero) postando la velocità dell'SSD ottenuta tramite altissime queue depth (il numero di richieste I/O che vengono contemporaneamente chieste all'SSD) e tanti thread e visto che la maggior parte degli utenti non supera la QD4 come ha detto Liupen difficilmente si raggiungono i 14 GB/s in un trasferimenti di file, idem per i 6,5 GB/s degli SSD PCIe 4.0. Si raggiunge qualcosina in meno ma il concetto che volevo trasmettere è lo stesso: le scritture sequenziali ti capita di usarle quando trasferisci dei file che non sono di dimensioni inferiori a 4kB e quindi sono importanti anche loro, non soltanto le performance randomiche.
Te l'ha detto Liupen: le "operazioni reali" rientrano soltanto per i blocchi di dimensione di 4kB, di più è sequenziale.
Vero anche questo, le performance randomiche non hanno bottleneck dalla banda PCIe ma è un limite delle NAND flash che per motivi architettonici sono molto più lente delle NOR flash.
No, perché il sequenziale non rientra soltanto se sposti ogni giorno TB. Te l'ha proprio spiegato Liupen:
- Messaggi
- 12,184
- Reazioni
- 6,238
- Punteggio
- 208
Ah si certo, sono velocità raggiunte in particolari condizioni di favore. I benchmark sono sempre indicativi.
Non si raggiungono nel reale quelle prestazioni ma i bench hanno la peculiarità di servire a fare confronti tra modelli; il che va benissimo per scoprirne le caratteristiche.
Qualche giorno fà ad esempio ho dovuto trasferire in steam un gioco da un ssd ad un altro (per far spazio su quell più veloce) ma l'altro disco era un Samsung QVO sata ... quindi figurati il tempo che ci ha messo. In questo caso se l'ssd ricevente fosse stato un altro 980 PRO avrei avuto una prestazione almeno 10 volte superiore, perchè sequenziale (anche senza aspettarsi i 6000-7000 MB/s.
...nella reattività purtroppo le nand sono il limite si. Sono una tecnologia che potrà migliorare ancora di un qualche %, ma non di molto.
Dovresti rileggere cosa ho scritto sopra sulle reali misure dei file letti per il funzionamento normale del pc... non devi considerare solo i valori 4K QD1 ma anche code superiori e grandezze di file superiori.
File casuali e sequenziali per misurare le prestazioni non sono così netti, sono un mix anche in merito a "reattività" del pc.
Inoltre guarda (utilizzo il sito che hai preso come banca dati)
Nella realtà - come puoi constatare tu stesso - un sistema operativo su un pcie 5.0 con 4K da 100 MB/s non è 3 volte più veloce di un OS su ssd sata... o per meglio dire: l'aumento della reattività di Windows non corrisponde al percepito come 3 volte più veloce.
Non è che lo dico per smontarti, vorrei che fosse come dici, ma non lo è.
Un po perchè i file da 4KiB con bassa coda non sono il tutto per l'OS, un po perchè ciò che si percepisce a bassa velocità non è significativo tanto quanto la differenza di tempo percepita nel sequenziale (prevalentemente in scrittura poi, neanche in lettura).
Quindi confermo: le letture 4K importanti si, ma non sono tutto se poi non si riesce a scorgere una differenza di prestazioni nette.
aluking
Nuovo Utente
- Messaggi
- 20
- Reazioni
- 2
- Punteggio
- 29
Capito! 32KiB sono già file sequenziali per Windows. ................. dopo questa non scrivo piu nulla
Un accesso da 32 KiB è solo un accesso più grande di 4K.
Sequenziale significa:
Sto leggendo blocchi consecutivi sul disco, uno dopo l’altro
Random significa:
Sto leggendo blocchi sparsi in punti diversi del disco
La dimensione del blocco non c’entra NULLA con il fatto che l’accesso sia sequenziale o random
puoi dirmi dove io avrei scritto 3 volte piu veloce mi sfugge? ho scritto piu reattivo.
Ultima modifica:
- Messaggi
- 12,184
- Reazioni
- 6,238
- Punteggio
- 208
Accidenti che polemico che sei!
Ma benvenga.. non farò altro che sciorinarti una lezione da dare in pasto a ChatGPT
Se scrivi più reattivo ma non si nota che lo è... a che serve?
E poi questo è un Forum tecnologico, quì valgono le cose provate a suon di numeri.
Ti rispondo così chi legge può magari farsi un idea precisa di cosa sia la randomicità e la sequenzialità dei dati di un bench su ssd, visto che tu non lo sai... e te l'ho fatto già notare.
Partiamo allora dal bench , prendiamo cystaldiskmark, spiegando come avviene e poi passo alla differenza tra casuale e sequenziale, se non fosse già chiaro:
Tutto default.
In giallo e azzurro ho evidenziato la corrispondenza.
Nel bench casuale a 4K QD1 T1 crystaldiskmark (giallo) non fà altro che:
- creare (se non giò creato) un file di test grande 1 GiB (lo vedi scritto sopra)
- leggere (test a sinistra) secondo un algoritmo interno il blocco da 4KiB e misurarne il tempo quindi desumerne la velocità
- ripete questa letture di 1 blocco da 4KiB preso ovunque dal file di test per un tempo di 5 secondi (il tempo lo leggi sopra vicino a 1 GiB)
- far la media delle velocità e riportare un risultato in IOPS che trasforma in MB/s (può perchè conosce la grandezza del file e la quantità di operazioni eseguite).
Nel bench sequenziale 1M Q8 T1 crystaldiskmark (azzurro):
- crea o ha già creato il file di test da 1GiB
- legge (test a sinistra) secondo un altro algoritmo un file da 1MiB, ovvero 256 blocchi da 4 KiB in posizione sequenziale: (es.: LBA 1000, 1001, 1002…)
- per rendere le cose più attive, rispetto al precedente test, òa QD da 1 passa a 8. Significa che sono date 8 richieste di lettura contemporaneamente
- come detto precedentemente, ripete il test prendendo file da 1MiB ovunque dal file di test, per 5 secondi
- fà la media e restituisce un valore numerico in MB/s
Qual è la differenza? Perchè il valore casuale è infinitamente più piccolo di quello sequenziale (del tipo seq. 7000 MB/s e casuale 100 MB/s)?
2 elementi: latenza e limiti del controller/nand.
Nel casuale il controller deve cercare un determinato blocco da 4K e portarlo su RAM, ne cerca un altro, un altro, altro, ecc.
Nel sequenziale il controller cerca un pacchetto di blocchi da 4K (256 in fila) e li porta in RAM (che vuol dire leggerli), poi di nuovo poi di nuovo..ecc. Parallelamente a questo, avendo 8 richieste simili, sfrutta il fatto che avendo più chip, cerca i dati da leggere da più di un canale e contemporaneamente (sentito parlare di "parallelismo" del controller...ecco).
Anche solo a intuito si capisce... se sono su un palco di un teatro e cerco una persona alla volta tra il pubblico, dopo 5 minuti avrò trovato e portato sul palco con me 10 persone. Se sono sul palco e dico "la prima fila sul palco", "la terza fila sul palco"..ecc, e magari siamo in due a cercare (ricordate il QD) dopo i soliti 5 minuti avrò metà persone del cinema con me sul palco.
Chiaro no la differenza per cui si arriva nel sequenziale ad avere i numeroni e nel casuale dei numeri molto molto inferiori.
Su...sono bravo vero?
Così non ve l'avevano ancora spiegato!
Andando al nostro ssd, il controller impiega del tempo per attivare e portare a termine il comando e quindi tanti comandi ripetuti portano via più tempo di un comando unico. Questa è la latenza; fatta da: un po di tempo di seek (ricerca) + overhead (controlli, ecc, ecc).
Oltre questo abbiamo i limiti fisici del controller, che è una cpu con delle caratteristiche ben precise di MT/s, come anche le nand stesse.
I bench di Crystaldiskmark, è anche importante dirlo, sono all'interno della cache (spezie la cache di scrittura) ma anche la lettura ha la sua cache costituita dalla mappatura proprio di quel file di test da 1GiB che viene tenuta in una zona veloce (ma questo è un altro discorso).
Torniamo al casuale VS sequenziale.
Snocciolando cosa rende più veloce l'ssd tra i due tipi di dati, ed evidenziato fino a questo punto?
- la misura del file: il blocco base da 4K rispetto al file più grande fatto di pezzi da 4K contigui
- la QD ovvero la coda delle operazioni che il controller deve svolgere e può fare in parallelo perché nvme esegue più operazioni in parallelo e perchè se presenti più chip, più stack, al controller fanno capo più linee di comunicazione (in gergo: canali) e quindi più dati possono essere letti o anche scritti.
Ti riporto, visto che non mi credi cosa dice Microsoft a proposito del DirectStorage e della sequenzialità degli ssd:
DirectStorage è una funzionalità pensata per consentire ai giochi di sfruttare appieno l'archiviazione ad alta velocità (come gli SSD NVMe) in grado di fornire diversi gigabyte al secondo di letture di dati di piccole dimensioni (ad esempio, 64 kb) con un sovraccarico minimo della CPU.
Read sizes
L'assenza di parti mobili sull'NVMe crea una soglia molto più bassa. Le prestazioni di lettura aumentano notevolmente a partire da 32 KiB e raggiungono il massimo a 64 KiB. Leggere dati superiori non aumenta le prestazioni. Ciò significa che è necessario un minore sforzo per unire i dati in blocchi più grandi nel pacchetto per ottenere prestazioni ottimali.
Perchè 4K?
Innanzitutto contestualizzare che sono concetti nati prima degli ssd, con gli hdd e con le memorie volatili.
Il file da 4K (4KiB) non è una grandezza a caso sono i "settori 4K" dell'hdd ovvero la minima misura di grandezza utilizzata da un file system.
Vero, tradizionalmente il file system opera con blocchi da 512 Byte ma ormai con la formattazione avanzata (utilizzata da tutti i dispositivi attuali) tra l'intestazione del settore e le aree ECC, vengono combinati otto settori da 512 byte.
Quindi ad esempio il nostro Windows quando legge o scrive lo fà prendendo e portando su RAM, blocchi/settori da 4K:
4K+4K+4K+4K+......
L'hdd stesso o ora l'ssd (convenzionalmente, perchè poi internamente non è così) sono organizzati per essere formattati in questo modo.
Tutta questo modo di memorizzare e leggere i dati del sistema operativo è la parte definita "logica".
Si deve immaginare infatti che Windows a cui noi utenti diamo i comandi, pensi e agisca sullo storage in termini "logici", e che poi in effetti alla base gli hdd e ssd, abbiano un loro modo di memorizzare i dati, e spesso un ssd utilizza blocchi molto più grandi.
Ma benvenga.. non farò altro che sciorinarti una lezione da dare in pasto a ChatGPT
Se scrivi più reattivo ma non si nota che lo è... a che serve?
E poi questo è un Forum tecnologico, quì valgono le cose provate a suon di numeri.
Ti rispondo così chi legge può magari farsi un idea precisa di cosa sia la randomicità e la sequenzialità dei dati di un bench su ssd, visto che tu non lo sai... e te l'ho fatto già notare.
Partiamo allora dal bench , prendiamo cystaldiskmark, spiegando come avviene e poi passo alla differenza tra casuale e sequenziale, se non fosse già chiaro:
Tutto default.
In giallo e azzurro ho evidenziato la corrispondenza.
Nel bench casuale a 4K QD1 T1 crystaldiskmark (giallo) non fà altro che:
- creare (se non giò creato) un file di test grande 1 GiB (lo vedi scritto sopra)
- leggere (test a sinistra) secondo un algoritmo interno il blocco da 4KiB e misurarne il tempo quindi desumerne la velocità
- ripete questa letture di 1 blocco da 4KiB preso ovunque dal file di test per un tempo di 5 secondi (il tempo lo leggi sopra vicino a 1 GiB)
- far la media delle velocità e riportare un risultato in IOPS che trasforma in MB/s (può perchè conosce la grandezza del file e la quantità di operazioni eseguite).
Nel bench sequenziale 1M Q8 T1 crystaldiskmark (azzurro):
- crea o ha già creato il file di test da 1GiB
- legge (test a sinistra) secondo un altro algoritmo un file da 1MiB, ovvero 256 blocchi da 4 KiB in posizione sequenziale: (es.: LBA 1000, 1001, 1002…)
- per rendere le cose più attive, rispetto al precedente test, òa QD da 1 passa a 8. Significa che sono date 8 richieste di lettura contemporaneamente
- come detto precedentemente, ripete il test prendendo file da 1MiB ovunque dal file di test, per 5 secondi
- fà la media e restituisce un valore numerico in MB/s
Qual è la differenza? Perchè il valore casuale è infinitamente più piccolo di quello sequenziale (del tipo seq. 7000 MB/s e casuale 100 MB/s)?
2 elementi: latenza e limiti del controller/nand.
Nel casuale il controller deve cercare un determinato blocco da 4K e portarlo su RAM, ne cerca un altro, un altro, altro, ecc.
Nel sequenziale il controller cerca un pacchetto di blocchi da 4K (256 in fila) e li porta in RAM (che vuol dire leggerli), poi di nuovo poi di nuovo..ecc. Parallelamente a questo, avendo 8 richieste simili, sfrutta il fatto che avendo più chip, cerca i dati da leggere da più di un canale e contemporaneamente (sentito parlare di "parallelismo" del controller...ecco).
Anche solo a intuito si capisce... se sono su un palco di un teatro e cerco una persona alla volta tra il pubblico, dopo 5 minuti avrò trovato e portato sul palco con me 10 persone. Se sono sul palco e dico "la prima fila sul palco", "la terza fila sul palco"..ecc, e magari siamo in due a cercare (ricordate il QD) dopo i soliti 5 minuti avrò metà persone del cinema con me sul palco.
Chiaro no la differenza per cui si arriva nel sequenziale ad avere i numeroni e nel casuale dei numeri molto molto inferiori.
Su...sono bravo vero?
Così non ve l'avevano ancora spiegato!
Andando al nostro ssd, il controller impiega del tempo per attivare e portare a termine il comando e quindi tanti comandi ripetuti portano via più tempo di un comando unico. Questa è la latenza; fatta da: un po di tempo di seek (ricerca) + overhead (controlli, ecc, ecc).
Oltre questo abbiamo i limiti fisici del controller, che è una cpu con delle caratteristiche ben precise di MT/s, come anche le nand stesse.
I bench di Crystaldiskmark, è anche importante dirlo, sono all'interno della cache (spezie la cache di scrittura) ma anche la lettura ha la sua cache costituita dalla mappatura proprio di quel file di test da 1GiB che viene tenuta in una zona veloce (ma questo è un altro discorso).
Torniamo al casuale VS sequenziale.
Snocciolando cosa rende più veloce l'ssd tra i due tipi di dati, ed evidenziato fino a questo punto?
- la misura del file: il blocco base da 4K rispetto al file più grande fatto di pezzi da 4K contigui
- la QD ovvero la coda delle operazioni che il controller deve svolgere e può fare in parallelo perché nvme esegue più operazioni in parallelo e perchè se presenti più chip, più stack, al controller fanno capo più linee di comunicazione (in gergo: canali) e quindi più dati possono essere letti o anche scritti.
Ops!
Ti riporto, visto che non mi credi cosa dice Microsoft a proposito del DirectStorage e della sequenzialità degli ssd:
DirectStorage è una funzionalità pensata per consentire ai giochi di sfruttare appieno l'archiviazione ad alta velocità (come gli SSD NVMe) in grado di fornire diversi gigabyte al secondo di letture di dati di piccole dimensioni (ad esempio, 64 kb) con un sovraccarico minimo della CPU.
Read sizes
L'assenza di parti mobili sull'NVMe crea una soglia molto più bassa. Le prestazioni di lettura aumentano notevolmente a partire da 32 KiB e raggiungono il massimo a 64 KiB. Leggere dati superiori non aumenta le prestazioni. Ciò significa che è necessario un minore sforzo per unire i dati in blocchi più grandi nel pacchetto per ottenere prestazioni ottimali.
Perchè 4K?
Innanzitutto contestualizzare che sono concetti nati prima degli ssd, con gli hdd e con le memorie volatili.
Il file da 4K (4KiB) non è una grandezza a caso sono i "settori 4K" dell'hdd ovvero la minima misura di grandezza utilizzata da un file system.
Vero, tradizionalmente il file system opera con blocchi da 512 Byte ma ormai con la formattazione avanzata (utilizzata da tutti i dispositivi attuali) tra l'intestazione del settore e le aree ECC, vengono combinati otto settori da 512 byte.
Quindi ad esempio il nostro Windows quando legge o scrive lo fà prendendo e portando su RAM, blocchi/settori da 4K:
4K+4K+4K+4K+......
L'hdd stesso o ora l'ssd (convenzionalmente, perchè poi internamente non è così) sono organizzati per essere formattati in questo modo.
Tutta questo modo di memorizzare e leggere i dati del sistema operativo è la parte definita "logica".
Si deve immaginare infatti che Windows a cui noi utenti diamo i comandi, pensi e agisca sullo storage in termini "logici", e che poi in effetti alla base gli hdd e ssd, abbiano un loro modo di memorizzare i dati, e spesso un ssd utilizza blocchi molto più grandi.
aluking
Nuovo Utente
- Messaggi
- 20
- Reazioni
- 2
- Punteggio
- 29
Capisco la voglia di spiegare, ma stai confondendo due cose completamente diverse: la dimensione del blocco e la natura dell’accesso. Dire che “32 KiB sono sequenziali” è tecnicamente sbagliato. Un blocco da 32 KiB può essere random o sequenziale: dipende da dove si trova l’offset, non dalla grandezza del pezzo letto. Sequenziale significa leggere blocchi contigui (offset consecutivi), random significa leggere blocchi sparsi, anche se sono più grandi. Questi concetti sono indipendenti.Accidenti che polemico che sei!
Ma benvenga.. non farò altro che sciorinarti una lezione da dare in pasto a ChatGPT
Se scrivi più reattivo ma non si nota che lo è... a che serve?
E poi questo è un Forum tecnologico, quì valgono le cose provate a suon di numeri.
Ti rispondo così chi legge può magari farsi un idea precisa di cosa sia la randomicità e la sequenzialità dei dati di un bench su ssd, visto che tu non lo sai... e te l'ho fatto già notare.
Partiamo allora dal bench , prendiamo cystaldiskmark, spiegando come avviene e poi passo alla differenza tra casuale e sequenziale, se non fosse già chiaro:
Visualizza allegato 500878
Tutto default.
In giallo e azzurro ho evidenziato la corrispondenza.
Nel bench casuale a 4K QD1 T1 crystaldiskmark (giallo) non fà altro che:
- creare (se non giò creato) un file di test grande 1 GiB (lo vedi scritto sopra)
- leggere (test a sinistra) secondo un algoritmo interno il blocco da 4KiB e misurarne il tempo quindi desumerne la velocità
- ripete questa letture di 1 blocco da 4KiB preso ovunque dal file di test per un tempo di 5 secondi (il tempo lo leggi sopra vicino a 1 GiB)
- far la media delle velocità e riportare un risultato in IOPS che trasforma in MB/s (può perchè conosce la grandezza del file e la quantità di operazioni eseguite).
Nel bench sequenziale 1M Q8 T1 crystaldiskmark (azzurro):
- crea o ha già creato il file di test da 1GiB
- legge (test a sinistra) secondo un altro algoritmo un file da 1MiB, ovvero 256 blocchi da 4 KiB in posizione sequenziale: (es.: LBA 1000, 1001, 1002…)
- per rendere le cose più attive, rispetto al precedente test, òa QD da 1 passa a 8. Significa che sono date 8 richieste di lettura contemporaneamente
- come detto precedentemente, ripete il test prendendo file da 1MiB ovunque dal file di test, per 5 secondi
- fà la media e restituisce un valore numerico in MB/s
Qual è la differenza? Perchè il valore casuale è infinitamente più piccolo di quello sequenziale (del tipo seq. 7000 MB/s e casuale 100 MB/s)?
2 elementi: latenza e limiti del controller/nand.
Nel casuale il controller deve cercare un determinato blocco da 4K e portarlo su RAM, ne cerca un altro, un altro, altro, ecc.
Nel sequenziale il controller cerca un pacchetto di blocchi da 4K (256 in fila) e li porta in RAM (che vuol dire leggerli), poi di nuovo poi di nuovo..ecc. Parallelamente a questo, avendo 8 richieste simili, sfrutta il fatto che avendo più chip, cerca i dati da leggere da più di un canale e contemporaneamente (sentito parlare di "parallelismo" del controller...ecco).
Anche solo a intuito si capisce... se sono su un palco di un teatro e cerco una persona alla volta tra il pubblico, dopo 5 minuti avrò trovato e portato sul palco con me 10 persone. Se sono sul palco e dico "la prima fila sul palco", "la terza fila sul palco"..ecc, e magari siamo in due a cercare (ricordate il QD) dopo i soliti 5 minuti avrò metà persone del cinema con me sul palco.
Chiaro no la differenza per cui si arriva nel sequenziale ad avere i numeroni e nel casuale dei numeri molto molto inferiori.
Su...sono bravo vero?
Così non ve l'avevano ancora spiegato!
Andando al nostro ssd, il controller impiega del tempo per attivare e portare a termine il comando e quindi tanti comandi ripetuti portano via più tempo di un comando unico. Questa è la latenza; fatta da: un po di tempo di seek (ricerca) + overhead (controlli, ecc, ecc).
Oltre questo abbiamo i limiti fisici del controller, che è una cpu con delle caratteristiche ben precise di MT/s, come anche le nand stesse.
I bench di Crystaldiskmark, è anche importante dirlo, sono all'interno della cache (spezie la cache di scrittura) ma anche la lettura ha la sua cache costituita dalla mappatura proprio di quel file di test da 1GiB che viene tenuta in una zona veloce (ma questo è un altro discorso).
Torniamo al casuale VS sequenziale.
Snocciolando cosa rende più veloce l'ssd tra i due tipi di dati, ed evidenziato fino a questo punto?
- la misura del file: il blocco base da 4K rispetto al file più grande fatto di pezzi da 4K contigui
- la QD ovvero la coda delle operazioni che il controller deve svolgere e può fare in parallelo perché nvme esegue più operazioni in parallelo e perchè se presenti più chip, più stack, al controller fanno capo più linee di comunicazione (in gergo: canali) e quindi più dati possono essere letti o anche scritti.
Ops!
Ti riporto, visto che non mi credi cosa dice Microsoft a proposito del DirectStorage e della sequenzialità degli ssd:
DirectStorage è una funzionalità pensata per consentire ai giochi di sfruttare appieno l'archiviazione ad alta velocità (come gli SSD NVMe) in grado di fornire diversi gigabyte al secondo di letture di dati di piccole dimensioni (ad esempio, 64 kb) con un sovraccarico minimo della CPU.
Read sizes
L'assenza di parti mobili sull'NVMe crea una soglia molto più bassa. Le prestazioni di lettura aumentano notevolmente a partire da 32 KiB e raggiungono il massimo a 64 KiB. Leggere dati superiori non aumenta le prestazioni. Ciò significa che è necessario un minore sforzo per unire i dati in blocchi più grandi nel pacchetto per ottenere prestazioni ottimali.
Perchè 4K?
Innanzitutto contestualizzare che sono concetti nati prima degli ssd, con gli hdd e con le memorie volatili.
Il file da 4K (4KiB) non è una grandezza a caso sono i "settori 4K" dell'hdd ovvero la minima misura di grandezza utilizzata da un file system.
Vero, tradizionalmente il file system opera con blocchi da 512 Byte ma ormai con la formattazione avanzata (utilizzata da tutti i dispositivi attuali) tra l'intestazione del settore e le aree ECC, vengono combinati otto settori da 512 byte.
Quindi ad esempio il nostro Windows quando legge o scrive lo fà prendendo e portando su RAM, blocchi/settori da 4K:
4K+4K+4K+4K+......
L'hdd stesso o ora l'ssd (convenzionalmente, perchè poi internamente non è così) sono organizzati per essere formattati in questo modo.
Tutta questo modo di memorizzare e leggere i dati del sistema operativo è la parte definita "logica".
Si deve immaginare infatti che Windows a cui noi utenti diamo i comandi, pensi e agisca sullo storage in termini "logici", e che poi in effetti alla base gli hdd e ssd, abbiano un loro modo di memorizzare i dati, e spesso un ssd utilizza blocchi molto più grandi.
Il documento Microsoft che citi per DirectStorage non dice che 32 o 64 KiB diventano sequenziali: dice che gli SSD NVMe sono più efficienti quando le richieste sono grandi almeno 32–64 KiB. Parlano della dimensione ottimale della richiesta, non del fatto che queste richieste siano sequenziali. Anche un request da 64 KiB può essere totalmente random, ed è così nel 90% dei casi nei giochi moderni. Gli engine leggono decine o centinaia di chunk sparsi dentro pacchetti PAK, bundle, archive o file compressi. Sono chunk da 32–128 KiB, sì, ma in offset completamente non contigui. Esattamente come Windows quando apre DLL, plugin, font, configurazioni e file sparsi in tutto il filesystem. Il fatto che i blocchi siano più grandi rende l’NVMe più efficiente, non più sequenziale.
Se apri Process Monitor o Resource Monitor e osservi l’I/O reale dell’avvio di Windows, di Chrome, di Photoshop, di Blender, o del caricamento di qualsiasi gioco, vedrai immediatamente: gli accessi sono quasi tutti random 4K–128K. Anche in giochi DirectStorage. Anche in engine moderni. Anche nelle applicazioni Adobe. Non è una teoria: è verificabile in 10 secondi, basta guardare gli offset.
Dire che “32 KiB è sequenziale” è come dire che “se prendo una scatola più grande la sto mettendo automaticamente nello stesso scaffale di quella prima”. No: la dimensione non decide dove lo storage va a leggere. Decide la quantità di dati richiesta in una singola operazione, non se quell’operazione è contigua o sparsa.
La metafora del teatro funziona solo con gli HDD, perché lì la testina deve fisicamente muoversi. Sugli SSD non c’è nessuna testina. La latenza non ha nulla a che vedere con il movimento o con il cercare file contigui: dipende dal media (NAND o Optane), dalla struttura dei canali, dall’FTL e dal firmware. L'accesso random rimane random anche se è 32K o 64K.
Il motivo per cui i valori sequenziali sono enormemente più alti dei random non è la dimensione del blocco, ma il fatto che sequenziale = offset contigui + parallelismo massimo + latenza praticamente azzerata. Il random invece costringe il controller a saltare continuamente su offset diversi all'interno della NAND, e la NAND ha latenze interne non evitabili. È per questo che 4K random QD1 sta su 60–100 MB/s, mentre un sequenziale va a 7000 MB/s: non c’entra la dimensione del blocco, c’entra che una richiesta è contigua, l’altra è sparsa.
Infine: sì, un SSD più veloce in random è più reattivo, e sì, si nota eccome. Passare da 50 a 100 MB/s in random cambia l’avvio Windows, l’apertura dei programmi, lo streaming delle texture, il caricamento degli asset, la reattività generale. E chi ha provato un Optane o un SSD con random molto alto lo sa benissimo senza bisogno di teoria.
La confusione nasce tutta da questo: stai prendendo “dimensione del blocco” come sinonimo di “sequenziale”, ma non lo è. Sono due concetti separati. Windows, i giochi e le applicazioni moderne leggono blocchi più grandi perché l’NVMe è più efficiente così, ma gli offset rimangono sparsi: quindi resta comunque random. Questo è il motivo per cui anche con DirectStorage le performance random contano tantissimo.
Se vuoi veramente vedere com’è l’I/O reale, basta aprire Process Monitor: vedrai esattamente quello che sto dicendo. Tutto random, anche quando i blocchi non sono più da 4K.
- Messaggi
- 12,184
- Reazioni
- 6,238
- Punteggio
- 208
Non girare la frittata.
Non ti ho detto che 32KiB sono valori sequenziali, ti ho spiegato come performa un ssd rispetto alla grandezza del file (4KiB, 32KiB, 64KiB, 128KiB, ecc) e rispetto alla coda di comandi.
L'ho fatto mostrandoti quanto cambiano le prestazioni da 4K a 32K utilizzando ATTO, utilizzando le stesse parole di Microsoft), che dice che per DirectStorage il miglior trasferimento di dati dagli ssd per sfruttarne la velocità è 64KiB
Ti ho detto che Windows nell'uso normale non processa solo file 4K QD1 ma per il 50% file di grandezza maggiore di 32KiB.
Infine dimostrato quanto la coda ei comandi (QD) alzandosi, amplifica le prestazioni nell'ssd.
Tutte queste cose (spiegate) per dire che le prestazioni 4K Q1 che guardi, non sono l'unica cosa da guardare in un ssd, perchè 4K Q1 è un astrazione che dà un idea di quanto può essere reattivo un ssd, non di quanto è migliore.
Il discorso che fai su sequenziale, casuale, offset, è spiegato (succintamente) quì
Seguendo il tuo discorso, la sostanza non cambia @aluking
4K non è casuale come 128K non è sequenziale, siamo d'accordo, che cosa fà di uno o dell'altro il casuale e il sequenziale è il fatto che:
4K è il file più piccolo e "normalmente" processato (scritto/letto) da Windows e OS, quindi se prendo un file da 4K, essendo non divisibile, ho per antonomasia, "il" dato casuale (da usare nei bench... ricordati che non stiamo parlando in generale ma in discorso è il benchmark 4K Q1 che tu evidenzi negli ssd).
128K (preso come esempio) è la raccolta di tanti "spezzoni" di file da 4K contigui tali da renderli non casuali. Quindi in se, prendere un file da 128K riproduce già una prestazione sequenziale (infatti vedi sopra Crystaldiskmark).
Il discorso è sempre quello sopra, non è che cambia o c'è una spiegazione diversa se si parla di Crystaldiskmark o di Dirctstorage:
le prestazioni migliori per un ssd in lettura sono già buone con trasferimenti di file da 32KiB e ideali da 64KiB.
Poi nello specifico di DirectStorage ci si può chiedere: "come mai quella grandezza e non 1MiB che fà numeri più alti? La risposta è che DirectStorage diventa un compromesso, perchè hanno trovato la grandezza che è più piccola possibile per non creare coda (quindi pause nel trasferimento dei dati alla VRAM) e nello stesso tempo dare le migliori prestazioni.
Secondo te quando in Crystaldiskmark imposto che il file di test deve essere di 128KiB mica poi il controller vaà a prendere 32 pezzi da 4KiB sparsi per l'ssd... no, li prenderà contigui perchè fanno parte dello stesso set. Se lo facesse non sarebbe diverso da eseguire tanti singoli file da 4 KiB.
Magari ti è sfuggito il bench di ATTO che ho messo sopra. si tratta dell'aumento della velocità degli ssd semplicemente al variare della grandezza del file di test... non centra casuale o sequenziale, solo una variazione in crescendo.
Non ti ho detto che 32KiB sono valori sequenziali, ti ho spiegato come performa un ssd rispetto alla grandezza del file (4KiB, 32KiB, 64KiB, 128KiB, ecc) e rispetto alla coda di comandi.
L'ho fatto mostrandoti quanto cambiano le prestazioni da 4K a 32K utilizzando ATTO, utilizzando le stesse parole di Microsoft), che dice che per DirectStorage il miglior trasferimento di dati dagli ssd per sfruttarne la velocità è 64KiB
Ti ho detto che Windows nell'uso normale non processa solo file 4K QD1 ma per il 50% file di grandezza maggiore di 32KiB.
Infine dimostrato quanto la coda ei comandi (QD) alzandosi, amplifica le prestazioni nell'ssd.
Tutte queste cose (spiegate) per dire che le prestazioni 4K Q1 che guardi, non sono l'unica cosa da guardare in un ssd, perchè 4K Q1 è un astrazione che dà un idea di quanto può essere reattivo un ssd, non di quanto è migliore.
Il discorso che fai su sequenziale, casuale, offset, è spiegato (succintamente) quì
Seguendo il tuo discorso, la sostanza non cambia @aluking
4K non è casuale come 128K non è sequenziale, siamo d'accordo, che cosa fà di uno o dell'altro il casuale e il sequenziale è il fatto che:
4K è il file più piccolo e "normalmente" processato (scritto/letto) da Windows e OS, quindi se prendo un file da 4K, essendo non divisibile, ho per antonomasia, "il" dato casuale (da usare nei bench... ricordati che non stiamo parlando in generale ma in discorso è il benchmark 4K Q1 che tu evidenzi negli ssd).
128K (preso come esempio) è la raccolta di tanti "spezzoni" di file da 4K contigui tali da renderli non casuali. Quindi in se, prendere un file da 128K riproduce già una prestazione sequenziale (infatti vedi sopra Crystaldiskmark).
DirectStorage è nato per sfruttare la velocità degli ssd, per sfruttarne le prestazioni sequenziali a bassa coda, aggiungo.
Il discorso è sempre quello sopra, non è che cambia o c'è una spiegazione diversa se si parla di Crystaldiskmark o di Dirctstorage:
le prestazioni migliori per un ssd in lettura sono già buone con trasferimenti di file da 32KiB e ideali da 64KiB.
Poi nello specifico di DirectStorage ci si può chiedere: "come mai quella grandezza e non 1MiB che fà numeri più alti? La risposta è che DirectStorage diventa un compromesso, perchè hanno trovato la grandezza che è più piccola possibile per non creare coda (quindi pause nel trasferimento dei dati alla VRAM) e nello stesso tempo dare le migliori prestazioni.
Sbagli a dirlo. La latenza fà parte del mondo degli ssd, (evidenziato in rosso come dici sotto) ma comunque l'esempio del teatro ha come argomento tutt'altro. Serve a spiegare in maniera semplice la differenza dda un benchmark casuale da uno sequenziale. Te la ripropongo da leggere:
Quello che scrivi quì è giusto, ma è la dimensione del file di test che ne determina se sequenzialità.
Secondo te quando in Crystaldiskmark imposto che il file di test deve essere di 128KiB mica poi il controller vaà a prendere 32 pezzi da 4KiB sparsi per l'ssd... no, li prenderà contigui perchè fanno parte dello stesso set. Se lo facesse non sarebbe diverso da eseguire tanti singoli file da 4 KiB.
Magari ti è sfuggito il bench di ATTO che ho messo sopra. si tratta dell'aumento della velocità degli ssd semplicemente al variare della grandezza del file di test... non centra casuale o sequenziale, solo una variazione in crescendo.
Ma non stò confondendo le cose... ti sto parlando di prestazioni nei bench degli ssd.
Real Black
Utente Èlite
- Messaggi
- 1,528
- Reazioni
- 792
- Punteggio
- 108
Ma quando mai che i giochi fanno soltanto letture sequenziali composte prevalentemente da blocchi da 4-32kB? Magari informa ChatGPT su questo documento: https://www.solidigm.com/content/da...ocuments/Solidigm-Synergy-2.0-White-Paper.pdf.
Guarda aluking, è talmente vera questa cosa che c'è un articolo scientifico che la smentisce direttamente:
1. On the Performance of Games using Solid State Drives:
Poi se vuoi leggere (da solo) il documento sopra di Solidigm...
Ok, allora se dici questo ci porti delle prove che dimostrano che "sì, si nota eccome [la differenza]"? Perché io da quello che vedo c'è una differenza di quasi un secondo e mezzo, niente roba da "sì, si nota eccome":
Real Black
Utente Èlite
- Messaggi
- 1,528
- Reazioni
- 792
- Punteggio
- 108
Impossibile chiedere una cosa del genere a un LLM, loro pur di sostenere quello che dicono girano la frittata in 800.000 maniere diverse. La risposta che ti ha dato ieri è sempre generata da un LLM, lo si nota in tutto.
Mi chiedo perché metter bocca in cose che non si sanno (e penso che riconosca il fatto che non conosca l'argomento se usa ChatGPT per ogni singolo commento).
- Messaggi
- 12,184
- Reazioni
- 6,238
- Punteggio
- 208
l'hai ammazzato!Sono aspetti troppo tecnici e se uno è profano vede i dati giusti della AI ma perde la visione di insieme.
-------------------------
@aluking le nozioni che hai preso da ...ovunque le hai prese, sono giuste e io tendo a semplificare anche troppo perchè vorrei si capissero.
Tipo dire che il 4k è "per antonomasia" il dato casuale.... il bench sul 4K di CDM è casuale perché il benchmark lo esegue casualmente per via delle sue caratteristiche come grandezza; logicamente la dimensione del blocco (4K) è indipendente dal tipo di accesso (casuale), come la dimensione del blocco non determina l'accesso, ma è un parametro necessario affinché il test possa misurare la prestazione (latenza vs. prestazione) che è il vero obiettivo del benchmark.
Nei benchmark (e nelle performance di DirectStorage) la dimensione del blocco è il fattore chiave che sblocca il parallelismo e il throughput, rendendola, di fatto, collegata alla performance sequenziale.
Esempio appunto ATTO è il benchmark ideale per questo scopo perché esegue test sequenziali puri utilizzando diverse dimensioni di blocco, mantenendo la profondità della coda (Queue Depth) costante.
Non c'è il modo di usare il file di test come casuale o sequenziale, semplicemente varia solo la sua grandezza e il dato viene letto sequenzialmente: prima un set seq da 512 byte, poi 1KiB, poi 2...3...4...ecc
C'è da dire in pratica che nonostante l'accesso sia sequenziale, la dimensione del blocco è troppo piccola per sfruttare appieno il parallelismo dei chip nand. Il controller spende tempo a gestire singole piccole transazioni.... ma mano a mano crescendo il file di test (blocchi contigui letti), diminuisce la latenza e accresce il parallelismo (lettura da più canali). Lo vedi da 32-128 KiB che il grafico mostra un incremento verticale improvviso della velocità. Questo è il punto in cui la dimensione del blocco diventa abbastanza grande da permettere al controller di raggruppare i dati e distribuire il carico su più canali NAND in parallelo.
Il paradosso proprio evidenziato da ATTO è che un accesso è "sequenziale" solo quando la sua dimensione del blocco è sufficientemente grande da sbloccare il massimo throughput (parallelismo) dell'ssd. Senza un blocco grande, anche un accesso sequenziale si comporta in termini di velocità come un accesso casuale.
Se usi invece Crrystaldiskmark posso dimostrare in modo analogo
nota come al solo crescere del file di test, mantenendo il benchmark di tipo casuale, crescono le prestazioni in lettura.
In questo caso si osserva e dimostra che anche una transazione casuale o random (lettura) di un file sufficientemente grande (vedi da 128 KiB in su), si comporta/ha prestazioni come se la velocità di accesso fosse sequenziale
Mettendo quindi che sia vero cosa scrivi su (lo è in parte)
solo nel caso del crystaldiskmark che ho messo sopra (980 PRO), si passa in un range da 268 a 2880 MB/s
Capisci che i 100 MB/s del 4K Q1 perdono significato se occorre considerare che windows & co fanno l'altalena con valori vari e più alti.
Come ti dicevo all'inizio il 4K Q1 è un astrazione. Utile eh... la considero come detto anch'io e Optane è figo per questo, ma.. non proprio reale, contano altri elementi, visto appunto che
PS aggiunte conclusioni che mi ero dimenticato di scrivere (evidenzio in viola).
Ultima modifica:
aluking
Nuovo Utente
- Messaggi
- 20
- Reazioni
- 2
- Punteggio
- 29
All ora prenditela con black per averti citato lui ha scritto questo:
Sono aspetti troppo tecnici e se uno è profano vede i dati giusti della AI ma perde la visione di insieme.
-------------------------
@aluking le nozioni che hai preso da ...ovunque le hai prese, sono giuste e io tendo a semplificare anche troppo perchè vorrei si capissero.
Tipo dire che il 4k è "per antonomasia" il dato casuale.... il bench sul 4K di CDM è casuale perché il benchmark lo esegue casualmente per via delle sue caratteristiche come grandezza; logicamente la dimensione del blocco (4K) è indipendente dal tipo di accesso (casuale), come la dimensione del blocco non determina l'accesso, ma è un parametro necessario affinché il test possa misurare la prestazione (latenza vs. prestazione) che è il vero obiettivo del benchmark.
Nei benchmark (e nelle performance di DirectStorage) la dimensione del blocco è il fattore chiave che sblocca il parallelismo e il throughput, rendendola, di fatto, collegata alla performance sequenziale.
Visualizza allegato 500982
Esempio appunto ATTO è il benchmark ideale per questo scopo perché esegue test sequenziali puri utilizzando diverse dimensioni di blocco, mantenendo la profondità della coda (Queue Depth) costante.
Non c'è il modo di usare il file di test come casuale o sequenziale, semplicemente varia solo la sua grandezza e il dato viene letto sequenzialmente: prima un set seq da 512 byte, poi 1KiB, poi 2...3...4...ecc
C'è da dire in pratica che nonostante l'accesso sia sequenziale, la dimensione del blocco è troppo piccola per sfruttare appieno il parallelismo dei chip nand. Il controller spende tempo a gestire singole piccole transazioni.... ma mano a mano crescendo il file di test (blocchi contigui letti), diminuisce la latenza e accresce il parallelismo (lettura da più canali). Lo vedi da 32-128 KiB che il grafico mostra un incremento verticale improvviso della velocità. Questo è il punto in cui la dimensione del blocco diventa abbastanza grande da permettere al controller di raggruppare i dati e distribuire il carico su più canali NAND in parallelo.
Il paradosso proprio evidenziato da ATTO è che un accesso è "sequenziale" solo quando la sua dimensione del blocco è sufficientemente grande da sbloccare il massimo throughput (parallelismo) dell'ssd. Senza un blocco grande, anche un accesso sequenziale si comporta in termini di velocità come un accesso casuale.
Se usi invece Crrystaldiskmark posso dimostrare in modo analogo
Visualizza allegato 500983
nota come al solo crescere del file di test, mantenendo il benchmark di tipo casuale, crescono le prestazioni in lettura.
In questo caso si osserva e dimostra che anche una transazione casuale o random (lettura) di un file sufficientemente grande (vedi da 128 KiB in su), si comporta/ha prestazioni come se la velocità di accesso fosse sequenziale
Mettendo quindi che sia vero cosa scrivi su (lo è in parte)
solo nel caso del crystaldiskmark che ho messo sopra (980 PRO), si passa in un range da 268 a 2880 MB/s
Capisci che i 100 MB/s del 4K Q1 perdono significato se occorre considerare che windows & co fanno l'altalena con valori vari e più alti.
Come ti dicevo all'inizio il 4K Q1 è un astrazione. Utile eh... la considero come detto anch'io e Optane è figo per questo, ma.. non proprio reale, contano altri elementi, visto appunto che
PS aggiunte conclusioni che mi ero dimenticato di scrivere (evidenzio in viola).
Te l'ha detto Liupen: le "operazioni reali" rientrano soltanto per i blocchi di dimensione di 4kB, di più è sequenziale.
Nn sono stato a leggere chi ha scritto o taggato cosa. Se nn l hai scritto all ora cominciamo ad andare d accordo
Dimmi come interpreti questa frase....
Te l'ha detto Liupen: le "operazioni reali" rientrano soltanto per i blocchi di dimensione di 4kB, di più è sequenziale......
Cmq io me ne accorgo 1 2 secondi ogni volta che apri app e giochi e tanti programmi cambia.
Poi se testate la singola app vivendo solo nel mondo del benchmark. Dove apri un app con windows appena installato e non hai niente altro aperto all ora e come nn farlo.
Pensa nel mondo reale dopo 3 4 mesi che hai messo windows e ci hai installato un 200 gb di app programmi e giochi a sto punto
apri photoshop unity comfyui poi apri sketchup e li non e piu 9 vs 10 secondi.
Perche ci osno aperte 4 5 cose pesanti.
Li cambia anche di 2 3 secondi se non 3 4 e cambia molto.
Ora ho scritto io Intendevo dire questo ma non riuscivo a farmi capire poi la frase scritta sopra mi ha fatto scattare.
Ora dimmi che quello che ho detto nn e cosi. O dimmi che piu di 4k é sequenziale ahahahahahahahahahahah come ha scritto black.
All ora prenditela con black per averti citato lui ha scritto questo:
Sono aspetti troppo tecnici e se uno è profano vede i dati giusti della AI ma perde la visione di insieme.
-------------------------
@aluking le nozioni che hai preso da ...ovunque le hai prese, sono giuste e io tendo a semplificare anche troppo perchè vorrei si capissero.
Tipo dire che il 4k è "per antonomasia" il dato casuale.... il bench sul 4K di CDM è casuale perché il benchmark lo esegue casualmente per via delle sue caratteristiche come grandezza; logicamente la dimensione del blocco (4K) è indipendente dal tipo di accesso (casuale), come la dimensione del blocco non determina l'accesso, ma è un parametro necessario affinché il test possa misurare la prestazione (latenza vs. prestazione) che è il vero obiettivo del benchmark.
Nei benchmark (e nelle performance di DirectStorage) la dimensione del blocco è il fattore chiave che sblocca il parallelismo e il throughput, rendendola, di fatto, collegata alla performance sequenziale.
Visualizza allegato 500982
Esempio appunto ATTO è il benchmark ideale per questo scopo perché esegue test sequenziali puri utilizzando diverse dimensioni di blocco, mantenendo la profondità della coda (Queue Depth) costante.
Non c'è il modo di usare il file di test come casuale o sequenziale, semplicemente varia solo la sua grandezza e il dato viene letto sequenzialmente: prima un set seq da 512 byte, poi 1KiB, poi 2...3...4...ecc
C'è da dire in pratica che nonostante l'accesso sia sequenziale, la dimensione del blocco è troppo piccola per sfruttare appieno il parallelismo dei chip nand. Il controller spende tempo a gestire singole piccole transazioni.... ma mano a mano crescendo il file di test (blocchi contigui letti), diminuisce la latenza e accresce il parallelismo (lettura da più canali). Lo vedi da 32-128 KiB che il grafico mostra un incremento verticale improvviso della velocità. Questo è il punto in cui la dimensione del blocco diventa abbastanza grande da permettere al controller di raggruppare i dati e distribuire il carico su più canali NAND in parallelo.
Il paradosso proprio evidenziato da ATTO è che un accesso è "sequenziale" solo quando la sua dimensione del blocco è sufficientemente grande da sbloccare il massimo throughput (parallelismo) dell'ssd. Senza un blocco grande, anche un accesso sequenziale si comporta in termini di velocità come un accesso casuale.
Se usi invece Crrystaldiskmark posso dimostrare in modo analogo
Visualizza allegato 500983
nota come al solo crescere del file di test, mantenendo il benchmark di tipo casuale, crescono le prestazioni in lettura.
In questo caso si osserva e dimostra che anche una transazione casuale o random (lettura) di un file sufficientemente grande (vedi da 128 KiB in su), si comporta/ha prestazioni come se la velocità di accesso fosse sequenziale
Mettendo quindi che sia vero cosa scrivi su (lo è in parte)
solo nel caso del crystaldiskmark che ho messo sopra (980 PRO), si passa in un range da 268 a 2880 MB/s
Capisci che i 100 MB/s del 4K Q1 perdono significato se occorre considerare che windows & co fanno l'altalena con valori vari e più alti.
Come ti dicevo all'inizio il 4K Q1 è un astrazione. Utile eh... la considero come detto anch'io e Optane è figo per questo, ma.. non proprio reale, contano altri elementi, visto appunto che
PS aggiunte conclusioni che mi ero dimenticato di scrivere (evidenzio in viola).
Te l'ha detto Liupen: le "operazioni reali" rientrano soltanto per i blocchi di dimensione di 4kB, di più è sequenziale.
Non sono stato a leggere chi ha scritto o taggato cosa. Se non l hai scritto tu. all ora cominciamo ad andare d accordo
Dimmi come interpreti questa frase....
Te l'ha detto Liupen: le "operazioni reali" rientrano soltanto per i blocchi di dimensione di 4kB, di più è sequenziale......
Cmq io me ne accorgo 1 2 secondi ogni volta che apri app e giochi e tanti programmi cambia.
Poi se testate la singola app vivendo solo nel mondo del benchmark. Dove apri un app con windows appena installato e non hai niente altro aperto all ora e come non farlo.
Pensa nel mondo reale dopo 3 4 mesi che hai messo windows e ci hai installato un 200 gb di app programmi e giochi a sto punto
apri photoshop unity comfyui poi apri sketchup e li non e piu 9 vs 10 secondi.
Perche ci osno aperte 4 5 cose pesanti.
Li cambia anche di 2 3 secondi se non 3 4 e cambia molto. Ma ripeto che l utente medio non se ne accorge cmq potrei anche darti ragione. Io cmq si ma ci sta ragionavo per come la vedo io non e detto che sia cosi per tutti.
Non ci siamo capiti poi la frase scritta sopra mi ha fatto scattare.
Ora dimmi che quello che ho scritto non e cosi. O dimmi che piu di 4k é sequenziale ahahahahahahahahahahah come ha scritto black.
Ultima modifica da un moderatore:
Real Black
Utente Èlite
- Messaggi
- 1,528
- Reazioni
- 792
- Punteggio
- 108
Scusami hai elaborato ora quella parte di un mio vecchio commento? i commenti più avanti non li hai letti?
Comunque la vedo come una cosa di poca importanza vista la spiegazione di Liupen: blocchi da 4kB sono a prescindere più lenti di quelli più grandi siccome vanno presi singolarmente, mentre i blocchi più grandi possono essere smontati sequenzialmente in blocchi più piccoli e questa sequenzialità rende il tutto più veloce.
Eh ma questo è un problema, mica funziona così nelle discussioni. Quando si discute tu devi leggere tutto, mica quello che vuoi tu e basta, altrimenti grazie al piffero che rimani indietro con gli argomenti.
Ma cosa ti fa “scattare”? leggere e rispondere a quello che vuoi?
Comunque il succo è: indipendentemente dalla natura di accesso dei blocchi (casuale o sequenziale), un blocco più piccolo avrà sempre prestazioni inferiori di un blocco più grande visto che diminuisce il parallelismo attraverso i vari chip NAND flash. Gli accesso casuali con blocchi da 4kB sono un limite delle NAND flash o degli attuali SSD in generale e tra i vari SSD la differenza è poco tangibile nell’uso reale visto che cade di qualche secondo. E questo è un fatto siccome i benchmark dimostrano una differenza di pochi secondi anche con Optane (che non usa NAND flash).
Se per te 2-3 secondi fanno una grande differenza poco importa, nel 99% delle esperienze che si leggono su internet si scopre che gli utenti non vedono differenze di fluidità tra le varie generazioni degli SSD NVMe e quindi si può affermare che l’SN8100 assolutamente “non caga in testa” all’SN850X per le prestazioni casuali superiori e che 19 MB/s di differenza con blocchi da 4kB rispetto al 9100 PRO non sono tanti.
Pubblicità