Ssd Samsung 980

[svkap]

Ho ripristinato un altro backup di circa 150gb sempre dal vecchio disco sata 2.
Il 980 si è comportato in questa maniera: facendo riferimento alla temperatura del controller, si è partiti da 54° in idle per poi schizzare a 86° nell'arco di appena 3 minuti (Hwinfo segna in rosso questo valore).
Dopo 9 minuti la temperatura crolla a 63° per poi arrivare dopo 12 minuti a 70°, dopo circa 17 minuti è a 75°, dopo 20 minuti è a 77°, dopo 23 minuti è a 78°, dopo 26 minuti scende a 75°, dopo 30 minuti si rialza a 81°, dopo 33 minuti scende a 79°, dopo 36 minuti scende a 80°, dopo 40 minuti scende a 79°, dopo 43 minuti sale a 80°, dopo 50 minuti sale a 85° ma HWinfo non lo evidenzia ancora in rosso e dopo un paio di minuti il backup è concluso.
Mi sembra di capire che a 86° il 980 va in TT, la temperatura all'improvviso cala drasticamente a 63° per poi lentamente arrivare, tra salite e discese varie, a 85° dopo 50 minuti di lavoro.

 

[crimescene]

Ho ripristinato un altro backup di circa 150gb sempre dal vecchio disco sata 2.
Il 980 si è comportato in questa maniera: facendo riferimento alla temperatura del controller, si è partiti da 54° in idle per poi schizzare a 86° nell'arco di appena 3 minuti (Hwinfo segna in rosso questo valore).
Dopo 9 minuti la temperatura crolla a 63° per poi arrivare dopo 12 minuti a 70°, dopo circa 17 minuti è a 75°, dopo 20 minuti è a 77°, dopo 23 minuti è a 78°, dopo 26 minuti scende a 75°, dopo 30 minuti si rialza a 81°, dopo 33 minuti scende a 79°, dopo 36 minuti scende a 80°, dopo 40 minuti scende a 79°, dopo 43 minuti sale a 80°, dopo 50 minuti sale a 85° ma HWinfo non lo evidenzia ancora in rosso e dopo un paio di minuti il backup è concluso.
Mi sembra di capire che a 86° il 980 va in TT, la temperatura all'improvviso cala drasticamente a 63° per poi lentamente arrivare, tra salite e discese varie, a 85° dopo 50 minuti di lavoro.

beh come dicevo un dissipatore io ce lo metterei non tanto per il TT ma perchè comunque le temp alte non fanno bene alla lunga.

Basta un pezzo di alluminio di 10 euro per risolvere

 

[Liupen]

Ho ripristinato un altro backup di circa 150gb sempre dal vecchio disco sata 2.
Il 980 si è comportato in questa maniera: facendo riferimento alla temperatura del controller, si è partiti da 54° in idle per poi schizzare a 86° nell'arco di appena 3 minuti (Hwinfo segna in rosso questo valore).
Dopo 9 minuti la temperatura crolla a 63° per poi arrivare dopo 12 minuti a 70°, dopo circa 17 minuti è a 75°, dopo 20 minuti è a 77°, dopo 23 minuti è a 78°, dopo 26 minuti scende a 75°, dopo 30 minuti si rialza a 81°, dopo 33 minuti scende a 79°, dopo 36 minuti scende a 80°, dopo 40 minuti scende a 79°, dopo 43 minuti sale a 80°, dopo 50 minuti sale a 85° ma HWinfo non lo evidenzia ancora in rosso e dopo un paio di minuti il backup è concluso.
Mi sembra di capire che a 86° il 980 va in TT, la temperatura all'improvviso cala drasticamente a 63° per poi lentamente arrivare, tra salite e discese varie, a 85° dopo 50 minuti di lavoro.

Sarebbe stato interessante vedere anche l'andamento della copia ma..
Con un file così grande e non sapendo quanto spazio libero hai, potrebbe semplicemente essere finito lo spazio della cache di scrittura SLC ed aver ridotto le prestazioni/abbassato la temperatura.
Comunque tutto fa pensare al TT.

 

[svkap]

@Liupen
Ho fatto di meglio: ho scompatatto con winrar un file video di 20gb direttamente sul 980 e ci avrà messo qualcosa come 20 secondi. La temperatura del controller in questo lasso di tempo è rimasta invariata a 51°, la stessa di quando ho avviato il pc.
Per entrare in TT come si è visto con il test precedente, basta un semplice ripristino di un backup da un vecchio hard disk per far schizzare le temperature del controller nell'arco di pochi minuti.
Credo quindi che non sia il carico di per sè ma la durata dell'operazione.

 

[BAT]

ho scompatatto con winrar un file video di 20gb direttamente sul 980

non è una prova significativa, i file video sono già compressi ed inoltre si tratta di un singolo file
una prova più realistica è un archivio di quellla dimensione o anche meno, all'interno del quale si trovino migliaia di piccoli file

 

[Liupen]

Credo @svkap che 20 secondi siano più che sufficienti per far arrivare il controller al TT (se l'ssd è uno di quelli che lo raggiunge).
La questione è che scompattando in archivio carichi la cpu e non l'ssd (che scrive alla velocità cui la cpu gli fornisce i dati.

Invece @BAT si tratta di prendere un file compresso (diciamo che non volevo spaventare svkap con un file troppo grande) ma se 10GB sono pochi (per via del tempo che ci mette...pochi secondi) oltre i 30GB si rischia di avere il collo di bottiglia rappresentato dal termine della cache slc e che ha come conseguenza quella di far scrivere l'ssd ad una velocità intorno ai 1000MB/s (che appunto non sono i clock del controller che scrive a oltre 3000MB/s).
Perchè è meglio un file compresso rispetto a tanti file? Non centra la compressione, come ho accennato l'host si avvale di altre risorse e non del controller dell'ssd.
L'elemento emergente è che lo spazio determinato di un file che viene scritto viene calcolato prima dal controller dell'ssd che cancella le celle che servono (eventualmente spsta, ci sono le verifiche overhead, ecc... ma sono pause). Tra un file e l'altro c'è maggiore tempo di risposta che non un unico file sequenziale, e maggiore tempo di inattività della scrittura (vuoi anche di pochi centesimi di secondo alla volta), sono comunque tempo non usato dal controller per scrivere. Quindi per prendere energia, scaldarsi.
Lo fà lo stesso, ma non al massimo, insomma.

 

[BAT]

Perchè è meglio un file compresso rispetto a tanti file? Non centra la compressione, come ho accennato l'host si avvale di altre risorse e non del controller dell'ssd.

mi rimane comunque il dubbio:
se il file da decomprimere è grosso e contiene migliaia/decine di migliaia di file relativamente piccoli (ma maggiori di 4 KiB o comunque maggiori della dimesione massima di un file che può essere inserito direttamente negli indici di una MFT -Master File Table- spiego dopo), ci sono migliaia/decine di migliaia di aggiornamenti (ossia di scritture) da fare sulle strutture del file system.
Queste migliaia (o decine di migliaia) di scritture ulteriori secondo me rallentano gli SSD DRAM-less che di media hanno prestazioni minori in termini di random read/write al secondo. Questo intuitivamente mi viene da pensare.

P.S
preciso meglio, anche se un po' alla buona: Windows per velocizzare l'accesso a piccoli file, invece di mettere un puntatore all'ininzio del file stesso e seguire la catena di pezzi da cui è composto, se il file non eccede una certa dimensione, invece del puntatore nellle MFT ci può mettere l'intero file. Ma se i file eccedono la dimensione massima consentita non si può fare, quindi per scirvere un file bisogna, oltre che calcolare e trovare lo spazio dove scriverlo, anche registrare la modifica sul file-system

 

[Liupen]

mi rimane comunque il dubbio:
se il file da decomprimere è grosso e contiene migliaia/decine di migliaia di file relativamente piccoli (ma maggiori di 4 KiB o comunque maggiori della dimesione massima di un file che può essere inserito direttamente negli indici di una MFT -Master File Table- spiego dopo), ci sono migliaia/decine di migliaia di aggiornamenti (ossia di scritture) da fare sulle strutture del file system.
Queste migliaia (o decine di migliaia) di scritture ulteriori secondo me rallentano gli SSD DRAM-less che di media hanno prestazioni minori in termini di random read/write al secondo. Questo intuitivamente mi viene da pensare.

P.S
preciso meglio, anche se un po' alla buona: Windows per velocizzare l'accesso a piccoli file, invece di mettere un puntatore all'ininzio del file stesso e seguire la catena di pezzi da cui è composto, se il file non eccede una certa dimensione, invece del puntatore nellle MFT ci può mettere l'intero file. Ma se i file eccedono la dimensione massima consentita non si può fare, quindi per scirvere un file bisogna, oltre che calcolare e trovare lo spazio dove scriverlo, anche registrare la modifica sul file-system

Capisco cosa vuoi dire, non ci avevo pensato; ma non si tratta di un DRAM less sata ma di un nvme HMB.

L'aggiornamento continuo del FTL dovrebbe avvenire sulla RAM di sistema.
Quindi la tabella non viene aggiornata in tempo reale sulle nand credo ma a termine operazione o con un frequenza indipendente.

E' come la telecronaca di un campionato di calcio: ci sono n. partite che si giocano parallelamente nei 90', ebbene un ssd con DRAM registrerebbe la telecronaca con tutti i fatti che succedono nello svolgimento di tutte le partite su un video; un DRAM less registrerebbe la telecronaca mentre si svolgono le azioni su...con carta e penna; un ssd con HMB registrerebbe sia su video la telecronaca (o meglio sulla RAM) che un resoconto dei punti a fine partita su un foglio di carta (le celle dell'ssd).

Tanto per dire che il peso della telecronaca/scrittura aggiornamento FTL tiene impegnato il controller ma non la scrittura su nand... non completamente insomma.

Scusate l'OT