View Full Version : [SSD] TRIM vs Background Garbage Collection
Il TRIM non è la stessa cosa del Garbage Collector... hanno lo steso scopo (preservare le performance e la vita dell'SSD) ma sono due funzioni diverse.
Le finalità sono le stesse (recuperare il degrado prestazionale) ma operano in modo completamente diverso.
Il TRIM NON è una prerogativa di Windows 7, c'è anche su Linux.
Il TRIM NON è una funzione presente solo sui Samsung e sui Corsair.
Il TRIM non è attivo quando si utilizzano configurazioni RAID:
Il problema vero è che il TRIM è una funzionalità Software del SO che richiede una controparte Firmware nel controller. Se due dischi sono configurati in RAID si avvalgono di un apposito controller RAID, che non sa dove sta di casa il TRIM. In parole povere è come se il controller per gestire il RAID "scavalcasse" per una questione gerarchica quello dell'SSD negando la controparte al SO per la funzione TRIM.
Il GC è un operazione svolta dal controller indipendentemente dallo stato del SO visto che non lo coinvolge. Quindi lo stato di IDLE è da intendere del disco non del SO, a conti fatti il GC agisce quando l'SSD è in stato di IDLE, o perlomeno sotto una certa soglia di lavoro. Questo perché essendo un attività lato controller introduce un overhead notevole sul disco tralasciando quasi del tutto il sistema operativo.
Il Garbage Collector rialloca le celle con dati non validi.
Il sistema operativo marca gli LBA (modifiche di file e non cancellazioni dei file) per i dati non validi ed l'SSD ne viene informato.
Quindi il GC legge/scrive/formatta.
Il BGC, come dice la parola stessa, non è altro che il GC lanciato durante dei tempi di idle (quali specificatamente non saprei dire e variano in base ai vari firmware).
La funzione principale è quella di rendere subito disponibili i vari blocchi di nand.
Funziona a livello di controller e le modalità di funzionamento variano a seconda delle implementazioni al livello di firmware.
Aspetti positivi: mantiene alte le performance.
Aspetti negativi: aumento write amplification, aumento scritture sulle nand.
Il TRIM istruisce l'SSD tramite i blocchi LBA quali dati sono cancellati.
Di conseguenza l'SSD non si porterà dietro questi blocchi dati (che non sono modificati) durante il GC.
Aspetti positivi: mantiene alte le perfomarnce, diminuisce i cicli di scrittura e la write amplification.
Aspetti negativi: funziona a livello di SO e deve essere implementato nel firmware dell'SSD.
Sono due cose diverse?
Sì.
Chi dei due è più importante?
Entrambi.
Chi è meglio implementato (attualmente)?
Il TRIM.
Non bisogna fare l'errore di credere che si possa fare a meno dell'uno o dell'altro.
Attualemente le due tecnologie sono complementari.
L'OverProvisionig è lo spazio che viene messo a disposizione del controller (quindi tutto quello non partizionato più quello riservato dall'SSD stesso) per le operazioni di GC e WL.
Credo funzioni anche per mappare eventuali nand danneggiate ma non ne sono sicuro.
E' importante?
Ovviamente sì.
Garbage collection
http://www.oczenterprise.com/whitepa...rim-and-gc.pdf
http://download.micron.com/pdf/techn...and/tn2917.pdf
http://www.enterprisestorageforum.co...he-Garbage.htm
http://blog.corsair.com/?p=3044
Overprovisioning
http://www.plianttechnology.com/pdf/..._July_2009.pdf
http://www.snia.org/events/storage-d...sable_Life.pdf
TRIM
http://www.snia.org/events/storage-d...n_Windows7.pdf
http://www.enterprisestorageforum.co...-with-TRIM.htm
Chi vuole informasi legga.
Faccio un esempio alla "Topolino apprendista stregone"... Il Trim è uno scopino magico, che toglie la spazzatura ogni volta che qualcuno la butta per terra.. un pò come fanno i ragazzi con i pattini a Disneyland...il Garbage Collection, invece... è lo staff che finisce e rifinisce le pulizie la sera, quando i parchi sono chiusi e le giostre sono immobili.
Entrambe le funzionalità sono in tutti i nuovi SSD prodotti dopo il 2008, il Trim opera su Windows 7, su Linux e presto anche sui Mac. Il GC, opera in condizioni di ridotto uso del disco, basso flusso dati, semi-idle e idle.
Quanto sia meglio il Trim su un tipo di controller rispetto al Garbage Collection, su altri tipi, è oggetto di discussione quotidiana puramente speculativa su diversi forum, perchè occorrerebbe un test su decine di unità in centinaia di configurazioni diverse, su diversi sistemi operativi di diverse configurazione di PC, prima di avere un valore attendibile al 100%.
Di norma, il degrado prestazionale su Sandforce, Indilinx e Intel, su un Windows 7, può non avvertirsi per mesi o anni.
per qualsiasi curiosità, dubbio o informazioni in generale sugli SSD fare riferimento a questo thread http://www.hwupgrade.it/forum/showthread.php?t=2228319
ringrazio: jined | S3N
Allora signori, concentriamo i commenti su TRIM vs GARBAGE COLLECTION qui, cosi' cerchiamo di chiarire la faccenda, e se nei vari thread degli SSD vedete domande su questo tema linkate questa discussione.
Grazie.
- CRL -
"Entrambe le funzionalità sono in tutti i nuovi SSD prodotti dopo il 2008, il Trim opera su Windows 7, su Linux e presto anche sui Mac. Il GC, opera in condizioni di ridotto uso del disco, basso flusso dati, semi-idle e idle."
E' sicuro che il Trim sia supporta su OSX ?
E' da un pò di tempo che cerco online, ma trovo solo domande datate e senza risposta.
E' sicuro che il Trim sia supporta su OSX ?
E' da un pò di tempo che cerco online, ma trovo solo domande datate e senza risposta.
Al momento non è supportato . Lo sarà di sicuro in Lion e in Snow Leopard ( tramite patch )
E' sicuro che il Trim sia supporta su OSX ?
E' da un pò di tempo che cerco online, ma trovo solo domande datate e senza risposta.
Per questo ho scritto "presto", perchè ancora non lo supporta, ma lo supporterà.
K Reloaded
02-11-2010, 16:26
ottimo thread ... :)
tirannosaurorex
02-11-2010, 16:43
Veramente prima che ne parlassi io, del Background Garbage Collection non ne aveva mai parlato nessuno su questo forum quindi sono felice nell' ottica di condivisione che la questione abbia destato interesse tanto da aprire un apposito thread scavalcando il mio apposito thread che avevo precedentemente aperto qui http://www.hwupgrade.it/forum/showthread.php?t=2271306
Intanto vorrei aggiungere che non bisogna confondere il Background Garbage Collection implementato sui dischi filo-Samsung (Corsair e Samsung) con il semplice Garbage Collection implementato nei dischi filo-Intel.
Inoltre vorrei aggiungere per maggiore chiarezza che le celle di memoria impiegate negli SSD filo-Samsung (Corsair e Samsung) sono costruite con un processo produttivo molto più avanzato a 30 nanometri, ricordo che Samsung è il primo e più grande produttore di memorie al mondo quindi più avanti tecnologicamente rispetto ad Intel che ancora deve capire come sono fatte le celle di memoria a 30 nanometri che Samsung produce già da un bel po di tempo.
Veramente prima che ne parlassi io, del Background Garbage Collection non ne aveva mai parlato nessuno su questo forum quindi sono felice nell' ottica di condivisione che la questione abbia destato interesse tanto da aprire un apposito thread scavalcando il mio apposito thread che avevo precedentemente aperto qui http://www.hwupgrade.it/forum/showthread.php?t=2271306
Intanto vorrei aggiungere che non bisogna confondere il Background Garbage Collection implementato sui dischi filo-Samsung (Corsair e Samsung) con il semplice Garbage Collection implementato nei dischi filo-Intel.
Inoltre vorrei aggiungere per maggiore chiarezza che le celle di memoria impiegate negli SSD filo-Samsung (Corsair e Samsung) sono costruite con un processo produttivo molto più avanzato a 30 nanometri, ricordo che Samsung è il primo e più grande produttore di memorie al mondo quindi più avanti tecnologicamente rispetto ad Intel che ancora deve capire come sono fatte le celle di memoria a 30 nanometri che Samsung produce già da un bel po di tempo.
Intel sta iniziando la produzione a 25 nanometri proprio in questo periodo, per il rilascio delle nuove unità G3. Già in prova presso alcuni reviewers, quindi direi che la produzione a 25 è bella che avviata, il che significa che la progettazione era già in canna almeno 6 mesi fa.
Detto questo.. non vorrei farti crollare il mondo addosso, ma i Force Corsair, usano Nand Intel .29F32G08AAMDB. (senza dubbio ottime) :cool:
volevo anche ricordare, che più scende la scala di nanometri, e più si riducono i cicli di scrittura :fagiano:
Tutto sommato forse me li terrei stretti gli SSD attuali..
Veramente prima che ne parlassi io, del Background Garbage Collection non ne aveva mai parlato nessuno su questo forum quindi sono felice nell' ottica di condivisione che la questione abbia destato interesse tanto da aprire un apposito thread scavalcando il mio apposito thread che avevo precedentemente aperto qui http://www.hwupgrade.it/forum/showthread.php?t=2271306
Intanto vorrei aggiungere che non bisogna confondere il Background Garbage Collection implementato sui dischi filo-Samsung (Corsair e Samsung) con il semplice Garbage Collection implementato nei dischi filo-Intel.
Inoltre vorrei aggiungere per maggiore chiarezza che le celle di memoria impiegate negli SSD filo-Samsung (Corsair e Samsung) sono costruite con un processo produttivo molto più avanzato a 30 nanometri, ricordo che Samsung è il primo e più grande produttore di memorie al mondo quindi più avanti tecnologicamente rispetto ad Intel che ancora deve capire come sono fatte le celle di memoria a 30 nanometri che Samsung produce già da un bel po di tempo.
Intel sta iniziando la produzione a 25 nanometri proprio in questo periodo, per il rilascio delle nuove unità G3. Già in prova presso alcuni reviewers, quindi direi che la produzione a 25 è bella che avviata, il che significa che la progettazione era già in canna almeno 6 mesi fa.
Abbiamo aperto questo thread proprio per non mischiare le cose...qui parliamo solo di TRIM e BGC. Discussioni sugli SSD in generale, marche, modelli, tecnologie di produzione, prezzi, bench, recensioni, configurazioni....insomma tutto il resto discutiamolo nel thread degli SSD appena ce lo riaprono gentilmente :D .
tirannosaurorex
02-11-2010, 17:22
Abbiamo aperto questo thread proprio per non mischiare le cose...qui parliamo solo di TRIM e BGC.
Infatti non bisogna "mischiare" il Background Garbage Collection implementato negli SSD filo Samsung (Corsair e Samsung) con il semplice Garbage Collection implementato negli SSD filo-Intel, lo dico solo per fare chiarezza nell' ottica di condivisione.
Ehhh però per una discussione tecnica bisognerebbe riscrivere in modo più dettagliato e completo alcune parti del post iniziale.
Il mio intervento del thread precedente era dettato dalla fretta nel far capire a tirannosaurorex gli errori delle sue affermazioni.
Ma lui è imperterrito. :D
Evangelion01
02-11-2010, 17:34
volevo anche ricordare, che più scende la scala di nanometri, e più si riducono i cicli di scrittura :fagiano:
Tutto sommato forse me li terrei stretti gli SSD attuali..
Perchè? :confused:
Ehhh però per una discussione tecnica bisognerebbe riscrivere in modo più dettagliato e completo alcune parti del post iniziale.
Il mio intervento del thread precedente era dettato dalla fretta nel far capire a tirannosaurorex gli errori delle sue affermazioni.
Ma lui è imperterrito. :D
Nessun problema modifica ciò che ritieni più opportuno e me lo rimandi cosi aggiorno :D
Perchè? :confused:
Ne possiamo discutere nel thread delle faq sugli ssd.
http://www.hwupgrade.it/forum/showthread.php?t=2228319
The_Saint
02-11-2010, 17:46
Veramente prima che ne parlassi io, del Background Garbage Collection non ne aveva mai parlato nessuno su questo forum quindi sono felice nell' ottica di condivisione che la questione abbia destato interesse tanto da aprire un apposito thread scavalcando il mio apposito thread che avevo precedentemente aperto qui...Ehm... mi sa che ti sei perso il thread ufficiale sugli SSD, è da più di un anno che parliamo anche di GC ed affini. ;)
Intanto vorrei aggiungere che non bisogna confondere il Background Garbage Collection implementato sui dischi filo-Samsung (Corsair e Samsung) con il semplice Garbage Collection implementato nei dischi filo-Intel.Intanto comincierei con lo specificare di quali SSD Corsair parli, dato che Corsair non produce controller per SSD e nella sua linea sono presenti vari modelli con controller appunto differenti.
Per quanto riguarda poi il garbage collection in background che effettuano gli SSD con controller Samsung (parliamo cmq dell'ultima versione, perchè le prime non avevano nemmeno il TRIM), che io sappia non ha mai funzionato come dovrebbe... se hai delle fonti, dei test, qualsiasi cosa che evidenzi la sua corretta implementazione, sono ben felice di essere contraddetto e di valutarli. :)
Quante belle cose si imparano...iscritto pure a questo thread...vediamo di capirici di più :)
Stevejedi
02-11-2010, 21:03
Non credo di essere OT se chiedo: quali sono gli SSD che supportano la modalità TRIM anche in RAID?
Che io sappia solo gli Intel. Attualmente sono in attesa del debutto dei G3 (ho un ottimo X25-V da 40 GB sul mio portatile, e come reattività è anni luce avanti rispetto alla controparte meccanica) per un rinnovamento del pc fisso, ma vorrei sapere se devo tenere in considerazione altri modelli di altre aziende.
Preferirei acquistare un HD da 60-80 GB con ottime prestazioni ora, e dunque aggiungerne un'altro uguale in RAID-0 quando necessario, che fare la spesa doppia subito.
Grazie
tirannosaurorex
02-11-2010, 21:38
Non credo di essere OT se chiedo: quali sono gli SSD che supportano la modalità TRIM anche in RAID?
Che io sappia solo gli Intel. Attualmente sono in attesa del debutto dei G3 (ho un ottimo X25-V da 40 GB sul mio portatile, e come reattività è anni luce avanti rispetto alla controparte meccanica) per un rinnovamento del pc fisso, ma vorrei sapere se devo tenere in considerazione altri modelli di altre aziende.
Preferirei acquistare un HD da 60-80 GB con ottime prestazioni ora, e dunque aggiungerne un'altro uguale in RAID-0 quando necessario, che fare la spesa doppia subito.
Grazie
Ti rispondo citando Zenzip
Il TRIM non è attivo quando si utilizzano configurazioni RAID:
Il problema vero è che il TRIM è una funzionalità Software del SO che richiede una controparte Firmware nel controller. Se due dischi sono configurati in RAID si avvalgono di un apposito controller RAID, che non sa dove sta di casa il TRIM. In parole povere è come se il controller per gestire il RAID "scavalcasse" per una questione gerarchica quello dell'SSD negando la controparte al SO per la funzione TRIM.
Se vuoi una funzione di "TRIM" efficace con SSD messi in RAID ma anche non in RAID e anche con SO che non supporta il TRIM devi prendere un SSD che abbia il Background Garbage Collection sistema messo a punto da Samsung sui propri SSD per mantenere alte le prestazioni e la durata delle celle di memoria nel tempo, da non confondere con il semplice Garbage Collection che hanno quasi tutti gli SSD filo-Intel tranne i Corsair Force serie F con controller Sand Force 1200
Scusami ma mi fai qualche esempio di ssd Samsung così mi vado finalmente a vedere qualche recensione?
Già hai detto dei Corsair...passiamo ai Samsung
Ma senza usare il trim, il degrado prestazionale viene subito o comunque dopo tempo ?
Per dire, dopo un anno dall'utilizzo senza TRIM, l'SSD ha ancora delle buone prestazioni o è gia affossato ? :D
Il calo di prestazione è permanente o si può recuperare in qualche modo ?
Ma senza usare il trim, il degrado prestazionale viene subito o comunque dopo tempo ?
Per dire, dopo un anno dall'utilizzo senza TRIM, l'SSD ha ancora delle buone prestazioni o è gia affossato ? :D
Il calo di prestazione è permanente o si può recuperare in qualche modo ?
è una domanda da un milione di dollari.
Il livello di degrado cambia in base al tipo di controller, tipo di sistema operativo, tipo di utilizzo dell'ssd, tipo di configurazione hardware (controller ICH).
è una domanda da un milione di dollari.
Il livello di degrado cambia in base al tipo di controller, tipo di sistema operativo, tipo di utilizzo dell'ssd, tipo di configurazione hardware (controller ICH).
SandForce SF-1200, OCZ Agility 2 da 60GB in particolare, che starebbe su un ICH10R.
Il problema è che l'OS non supporta il TRIM
SandForce SF-1200, OCZ Agility 2 da 60GB in particolare, che starebbe su un ICH10R.
Il problema è che l'OS non supporta il TRIM
Scusa se non mi faccio i caxxi miei ma che SO usi?
Scusa se non mi faccio i caxxi miei ma che SO usi?
forse mac os X....
forse mac os X....
yep
E allora non ti resta che aspettare un pochino, con Lion sembra ci sarà il supporto a questa tecnologia:
Apple is transitioning towards SSD's as their main storage medium. Apple has a vested interest in prolonging the life of SSD's.
Apple will build TRIM support into Lion.
Se proprio non vuoi fare l'upgrade a Lion, in Snow Leopard potrai usufruire di una patch.
E allora non ti resta che aspettare un pochino, con Lion sembra ci sarà il supporto a questa tecnologia:
Se proprio non vuoi fare l'upgrade a Lion, in Snow Leopard potrai usufruire di una patch.
Eh si, l'unico problema è che l'SSD sta arrivando xD.
E' imperdonabile che apple non abbia ancora rilasciato una patch per il TRIM in ogni caso. Contando poi che sui nuovi MacBook Air gli SSD son saldati sulla mobo. Quando l'SSD comincia a perdere colpi che fai, butti 1000 euro di computer? -.-
Eh si, l'unico problema è che l'SSD sta arrivando xD.
E' imperdonabile che apple non abbia ancora rilasciato una patch per il TRIM in ogni caso. Contando poi che sui nuovi MacBook Air gli SSD son saldati sulla mobo. Quando l'SSD comincia a perdere colpi che fai, butti 1000 euro di computer? -.-
Da utente Apple consapevole e non da fanboy posso dirti che non sarebbe la prima volta che Apple assume un comportamento del genere.
Detto questo non sono informato sugli SSD che montano i nuovi MacBookAir può essere che abbiano una tecnologia tutta loro per il TRIM, può essere che zio Steve abbia pensato a questo :D .
Cmq mi informerò meglio, mi sembra troppo stupido che Apple lasci i suoi clienti di SSD (che iniziano a diventare significativi) senza un supporto a questa tecnologia, praticamente indispensabile, fino alla data di rilascio di Lion.
The_Saint
03-11-2010, 10:30
Ma senza usare il trim, il degrado prestazionale viene subito o comunque dopo tempo ?
Per dire, dopo un anno dall'utilizzo senza TRIM, l'SSD ha ancora delle buone prestazioni o è gia affossato ? :D
Il calo di prestazione è permanente o si può recuperare in qualche modo ?Ci sono da fare due distinzioni per valutare il degrado che può subire un SSD, una dipendente dal quante scritture totali abbiamo eseguito ed una dipendente da quanto è pieno il drive.
Per approfondire il discorso bisognerebbe prima documentarsi un po' su come funziona in generale la scrittura nelle celle di memoria di un SSD... nel thread ufficiale l'ho scritta varie volte.
Tornando invece al degrado, cerco di spiegarmi meglio e di semplificare un po' il discorso... parliamo cmq di SSD in cui il TRIM non è attivo:
1. il degrado delle prestazioni comincia non appena abbiamo utilizzato per almeno una volta tutte le celle che compongono l'SSD, compresa la spare area... quindi si può facilmente capire che dipende da quanti dati abbiamo scritto sull'SSD e non dal tempo.
Attenzione quindi, non parlo di quanto è pieno l'SSD, ma di dati scritti complessivamente... che è ben diverso: se ad esempio copio un file da 1GB e poi lo cancello, quel GB va considerato come scrittura.
2. Dato che l'SSD è composto da più chip di memoria NAND collegati in parallelo (con una struttura molto simile al RAID0) man mano che riempiamo l'SSD potrebbe capitare che un intero chip sia occupato da dati fissi e quindi non più utilizzabile per sfruttare le prestazioni date dalla scrittura parallela su più celle... quindi più il disco è pieno e più è facile che le prestazioni siano limitate da questo.
(PS: questa condizione non è permanente, cancellando alcuni dati oppure per intervento dello static wear-leveling, la cella potrebbe liberarsi di nuovo.)
In realtà si dovrebbe aggiungere anche un terzo punto per quanto riguarda i controller SandForce, dato che in questi (data la particolare tecnologia che utilizzano, abbastanza differente rispetto agli altri) il degrado per riempimento del disco è molto più immediato ed evidente rispetto agli altri...
;)
Beh, diciamo che avevo pensato di strutturare la cosa in questo modo:
Sull'SSD solo OS e programmi ( compreso i file temporanei, lo swap/paging disabilitato perché ho abbastanza ram da poterlo fare ), poi sposterei la cartella home su un raid di hd meccanici. In modo tale che ogni file salvato sul desktop o scaricato dal browser vada a finire direttamente sugli HDD.
Quindi diciamo che i cicli di scrittura sono piu o meno minimi, relegati solo ai file di temp.
Però immagino che col TRIM disabilitato il degrado sia abbastanza più veloce in ogni caso.
Pensavo, esiste un modo per fare un trim manuale ?
Che so, un utility anche da far partire da usb che ti fa il trim da lanciare ogni due o tre giorni.
The_Saint
03-11-2010, 12:02
Pensavo, esiste un modo per fare un trim manuale ?
Che so, un utility anche da far partire da usb che ti fa il trim da lanciare ogni due o tre giorni.Alcuni SSD hanno le apposite utility, ma sotto Mac OS X che io sappia non esiste nulla...
Alcuni SSD hanno le apposite utility, ma sotto Mac OS X che io sappia non esiste nulla...
Il trim dipende dal filesystem, quindi se non è stato fatto niente per osx vuol dire che non esiste niente per l'HFS.
Quindi immagino che sarebbe inutile pensare di usare programmi anche su windows per risolvere il problema, right ?
Il trim dipende dal filesystem, quindi se non è stato fatto niente per osx vuol dire che non esiste niente per l'HFS.
Quindi immagino che sarebbe inutile pensare di usare programmi anche su windows per risolvere il problema, right ?
right :D
The_Saint
03-11-2010, 12:30
Il trim dipende dal filesystem, quindi se non è stato fatto niente per osx vuol dire che non esiste niente per l'HFS.
Quindi immagino che sarebbe inutile pensare di usare programmi anche su windows per risolvere il problema, right ?Esatto... ma che SSD hai ordinato?
Tornando al tema di questa discussione, se è un Indilinx, ha il garbage collection in idle... se è un SandForce, ha il DuraClass (che si occupa anche del GC a modo suo), se è un Samsung non si sa (anche se tirannosaurorex si è fissato con questo fantomatico "Background Garbage Collection"), se è un altro controller ancora, purtroppo non ha nulla.
;)
Esatto... ma che SSD hai ordinato?
Tornando al tema di questa discussione, se è un Indilinx, ha il garbage collection in idle... se è un SandForce, ha il DuraClass (che si occupa anche del GC a modo suo), se è un Samsung non si sa (anche se tirannosaurorex si è fissato con questo fantomatico "Background Garbage Collection"), se è un altro controller ancora, purtroppo non ha nulla.
;)
OCZ Agility 2 60GB con l'SF-1200
In realtà si dovrebbe aggiungere anche un terzo punto per quanto riguarda i controller SandForce, dato che in questi (data la particolare tecnologia che utilizzano, abbastanza differente rispetto agli altri) il degrado per riempimento del disco è molto più immediato ed evidente rispetto agli altri...
;)
Come al solito, ritengo le tue conclusioni estremanente discutibili, nonchè prive di fondamento e/o documentazione tangibile.
Tant'è che, essendo il degrado dei Sandforce, così minimale, tale controller viene impiegato spesso e volentieri in soluzioni raid integrate e/o sistemi PCI Express, che tutti sappiamo, sono privi di TRIM. E stando alla tua fantomatica ipotesi, sarebbero già inultilizzabili dopo qualche mese... cosa che invece, NESSUNO ha confermato.
The_Saint
03-11-2010, 14:12
Tant'è che, essendo il degrado dei Sandforce, così minimale, tale controller viene impiegato spesso e volentieri in soluzioni raid integrate e/o sistemi PCI Express, che tutti sappiamo, sono privi di TRIM. E stando alla tua fantomatica ipotesi, sarebbero già inultilizzabili dopo qualche mese... cosa che invece, NESSUNO ha confermato.Non ho mai parlato di tempo... volevo dire che se riempi un SandForce, hai prestazioni degradate un modo differente rispetto agli altri controller e questo è documentato in vari test online.
Che poi il degrado sia minimo, questo vale più o meno per tutti gli SSD... il 99% delle persone che utilizzano un SSD non si accorgeranno mai se il loro disco sta andando a pieno regime o con prestazioni degradate... chi se ne accorge è chi fa bench o chi lo utilizza molto intensamente (uso professionale, etc.).
:)
tirannosaurorex
03-11-2010, 15:37
Intel sta iniziando la produzione a 25 nanometri proprio in questo periodo, per il rilascio delle nuove unità G3. Già in prova presso alcuni reviewers, quindi direi che la produzione a 25 è bella che avviata, il che significa che la progettazione era già in canna almeno 6 mesi fa.
Detto questo.. non vorrei farti crollare il mondo addosso, ma i Force Corsair, usano Nand Intel .29F32G08AAMDB. (senza dubbio ottime) :cool:
Intel fa gli annunci "tutto fumo e niente arrosto" ..... Samsung ha già gli SSD nei negozi da mesi con le memorie a 30 nanometri per cui considerando come dici tu che Intel aveva la "progettazione in canna almeno 6 mesi fa" Samsung non saprei dirti di preciso da quanti mesi forse anni "aveva la progettazione in canna".
Come al solito, ritengo le tue conclusioni estremanente discutibili, nonchè prive di fondamento e/o documentazione tangibile.
Tant'è che, essendo il degrado dei Sandforce, così minimale, tale controller viene impiegato spesso e volentieri in soluzioni raid integrate e/o sistemi PCI Express, che tutti sappiamo, sono privi di TRIM. E stando alla tua fantomatica ipotesi, sarebbero già inultilizzabili dopo qualche mese... cosa che invece, NESSUNO ha confermato.
Innanzitutto complimenti a chi ha aperto il topic, sicuramente interessante e di attualità... soprattutto perché sto "scegliendo" cosa regalarmi per Natale! :D
Seriamente... gli OCZ Vertex 2 in generale sono, a mio modesto parere, una delle soluzioni in assoluto migliori per un impiego su macchine che, per un qualche motivo, non possono utilizzare il TRIM.
Questo per alcuni motivi:
1) sono fra i pochi SSD ad essere "certificati" dalla casa come "RAID capable" e, notoriamente, allo stato delle cose non vi è modo (driver) di eseguire il TRIM in tale configurazione. Neanche le soluzioni OEM RAID (es. su scheda) lo eseguono
2) OCZ è il partner "privilegiato" di Sandforce e l'unico ad ottenere dei firmware "elaborati" che migliorano le prestazioni (soprattutto sull'SF-1200... che in versione OCZ ha prestazioni paragonabili al 1500...)
3) Il sistema di "background garbage collection" (sebbene chiamato diversamente...) del SandForce 1200 pare sia piuttosto efficace fra i sistemi "autonomi" (da cui il punto 1) probabilmente)
4) La mancata esecuzione del TRIM penalizza esclusivamente le prestazioni in scrittura degli SSD e, di solito, per un fattore massimo di circa il 45-50%.
Il Sandforce 1200, in particolare in versione OCZ (vedasi punto 2) ) è uno dei più rapidi in origine come velocità di scrittura (satura il SATA II!), per cui, anche rallentasse al massimo - cosa che non credo - sarebbe sempre ad un livello più che dignitoso
Detto questo ci sono due cose a cui fare attenzione, perché non tutti i Vertex 2 sono uguali! :eek:
1) esistono in versione dotata di "Native TRIM" (una "specie di TRIM autonomo" quindi...) ed in versione priva di questa caratteristica (più vecchi ma ancora venduti). Quelli nuovi hanno sigle tipo OCZSSD2-2VTX40G o OCZSSD2-2VTXE60G
Quelli vecchi mancano di una lettera... (sebbene certificati RAID anch'essi...)
2) esistono in versione "extended capacity" (es. OCZSSD2-2VTXE60G) o normale (es. OCZSSD2-2VTX40G).
Dato che negli extended capacity la maggior capacità va a discapito dello spazio tenuto da parte proprio per gestire invecchiamento del supporto e ottimizzare la garbage collection, in sistemi privi di TRIM via software forse è preferibile adottare le versioni "tradizionali".
(Oppure, che è quasi lo stesso... prendere gli Extended capacity MA assicurarsi sempre di non riempirli oltre l'80%...)
;)
Allora, ragionandoci un attimo sù.
Alla fine il non avere il TRIM influisce sulle prestazioni in scrittura.
Ma se si usa l'SSD "quasi" come se fosse una ROM non ha molto importanza.
Se la cartella home si mette su un raid di HD meccanici, si disabilita lo swap ( tanto la ram abbonda ) e si mettono i file temporanei in una ramdisk ( anche se questo non è proprio necessario ).L'SSD diventa quasi una ROM e le volte in cui ci saranno cicli di scrittura saranno davvero minimi.
Allora, ragionandoci un attimo sù.
Alla fine il non avere il TRIM influisce sulle prestazioni in scrittura.
Ma se si usa l'SSD "quasi" come se fosse una ROM non ha molto importanza.
Se la cartella home si mette su un raid di HD meccanici, si disabilita lo swap ( tanto la ram abbonda ) e si mettono i file temporanei in una ramdisk ( anche se questo non è proprio necessario ).L'SSD diventa quasi una ROM e le volte in cui ci saranno cicli di scrittura saranno davvero minimi.
In questo modo sicuramente riduci i cicli di scrittura ma a mio parere se devi spendere una cifra importante per beneficiare delle prestazioni di un SSD e non le sfrutti è quasi come non averlo...
E poi non dimentichiamoci che installando e disinstallando programmi/giochi/applicazioni di qualsiasi genere è da considerare scrittura pura anche se dopo viene liberato lo spazio occupato.
In questo modo sicuramente riduci i cicli di scrittura ma a mio parere se devi spendere una cifra importante per beneficiare delle prestazioni di un SSD e non le sfrutti è quasi come non averlo...
E poi non dimentichiamoci che installando e disinstallando programmi/giochi/applicazioni di qualsiasi genere è da considerare scrittura pura anche se dopo viene liberato lo spazio occupato.
Beh sì, normale. Ma i programmi si installano una volta ogni tanto.
Comunque sarebbe una situazione momentanea "aspettando il trim"
Marinelli
04-11-2010, 07:57
Intel fa gli annunci "tutto fumo e niente arrosto" ..... Samsung ha già gli SSD nei negozi da mesi con le memorie a 30 nanometri per cui considerando come dici tu che Intel aveva la "progettazione in canna almeno 6 mesi fa" Samsung non saprei dirti di preciso da quanti mesi forse anni "aveva la progettazione in canna".
Quella che stai facendo mi sembra più una crociata che altro.
Sei stato già ripreso dal moderatore di sezione a tale riguardo e ti pregherei di evitare questa linea di condotta.
Ciao.
The_Saint
04-11-2010, 09:16
Quella che stai facendo mi sembra più una crociata che altro.Magari lavora per la Samsung... :D :p
@ tirannosaurorex : se riesci a fornirci un minimo di benchmark o di prove qualsiasi effettuate per verificare questo BGC del controller Samsung, la cosa potrebbe essere molto interessante e finalmente i tuoi interventi non cadrebbero nel vuoto... perciò, datti da fare! ;)
tirannosaurorex
04-11-2010, 13:12
Magari lavora per la Samsung... :D :p
@ tirannosaurorex : se riesci a fornirci un minimo di benchmark o di prove qualsiasi effettuate per verificare questo BGC del controller Samsung, la cosa potrebbe essere molto interessante e finalmente i tuoi interventi non cadrebbero nel vuoto... perciò, datti da fare! ;)
Io mi devo dare da fare ?
Veramente io avevo aperto un thread ufficiale prima di questo http://www.hwupgrade.it/forum/showthread.php?t=2271306 per parlare appunto del Background Garbage Collection sistema messo a punto da Samsung e installato nei propri SSD, sistema che funziona benissimo senza nessun bisogno di nessun TRIM o Microsoft W7 che poi neanche funziano, poi il mio thread è stato chiuso ed è stato aperto questo perchè il mio a qualcuno presumibilmente non garbava e qualcun' altro non gradiva che fossi io a trattare un argomento presumibilmente mooooolto scomodo, perchè chiaramente se si diffondesse la notizia che gli SSD Samsung sono gli unici che funziano e chi li comprerebbe più gli altri, la gente mica è fessa.
La trattazione del sistema Background Garbage Collection della Samsung da non confondere col Garbage Collection spetta a chi ha aperto il thread io ho capito molto bene l' "antifona" dopo che il mio thread è stato chiuso e quindi non interverrò più e neanche mi interessa di leggere quello che verrà scritto in questo thread.
Scusami ma da quando hai iniziato a postare nei vari thread degli ssd (e non dico questo o quello che hai aperto tu) hai sempre spiegato che i Samsung sono i migliori per tutto quello detto anche nel post sopra ma non hai mai portato dati,tabelle,review,test dove si evincesse che le tue teorie sono fondate.
Ora io sono un neofito in questo campo e mi piacerebbe capirne di più per questo ti dico...fammi capire da quali dati partono queste tue teorie.
Tnx
P.s: certo però arrivare a dire che i Samsung sono gli unici che funzionano mi sembra un pochettino azzardato...non credi?
tirannosaurorex
04-11-2010, 13:41
Scusami ma da quando hai iniziato a postare nei vari thread degli ssd (e non dico questo o quello che hai aperto tu) hai sempre spiegato che i Samsung sono i migliori per tutto quello detto anche nel post sopra ma non hai mai portato dati,tabelle,review,test dove si evincesse che le tue teorie sono fondate.
Ora io sono un neofito in questo campo e mi piacerebbe capirne di più per questo ti dico...fammi capire da quali dati partono queste tue teorie.
Tnx
P.s: certo però arrivare a dire che i Samsung sono gli unici che funzionano mi sembra un pochettino azzardato...non credi?
Guarda io nello spirito di condivisione il mio dovere l' ho fatto, per cui siccome non lavoro per la Samsung -come qualcuno ha detto- e questo thread non l' ho aperto io e quello che avevo aperto è stato chiuso ho finito con l' argomento e non mi interessa ne andare avanti ne combattere contro i mulini a vento.
Io sto apposto con la coscenza le notizie sull' argomento chi vuole le può trovare in rete e per quanto mi riguarda userò solo SSD Samsung che tecnologicamente sono più avanzati sia per il processo produttivo delle memorie attualmente già a 30 nanometri sia per il sistema di mantenimento delle stesse che non necessita di TRIM o W7
Passo e chiudo
tirannosaurorex, non c'e' da essere risentiti, come ti ho gia' scritto, hai avuto un modo di porti al limite (e forse oltre) del provocatorio, e questo ha creato scompiglio in almeno 3 discussioni. A me interessa che le questioni siano sviscerate e ci sia confronto, ma non posso perdere una mattinata a leggere segnalazioni da 3 discussioni diverse. Il thread che avevi aperto seguiva la stessa impostazione, e per questo ho preferito chiuderlo e chiedere di aprirne uno piu' equilibrato.
Cio' non toglie che tu sia il benvenuto a riportare qui quello che dicevi di la', solo dovremmo cercare di non cadere nel provocatorio, sono sicuro che c'e' un modo di farlo.
Quindi se hai voglia ti invito a riportarlo qui il tuo post, e poi se ne dibattera'. Allo stesso tempo ricordo agli altri che questo non e' un tiro al bersaglio, e per come la vedo io non c'e' una risposta giusta ed una sbagliata da trovare, ma da confrontare tecnologie diverse, che sicuramente hanno vantaggi e svantaggi, quindi fate i bravi anche voi, e niente tiro al bersaglio, grazie.
- CRL -
Peccato che non scriverai più,avrei voluto capire qualcosa di nuovo.
Ho letto tante recensioni postate anche qui sui Sandforce,ma sui Samsung non so nulla.Mi mandi qualche link in pvt pls?
Sempre nell'ottica di un futuro acquisto...
Evangelion01
04-11-2010, 15:34
Io sto apposto con la coscenza le notizie sull' argomento chi vuole le può trovare in rete e per quanto mi riguarda userò solo SSD Samsung che tecnologicamente sono più avanzati sia per il processo produttivo delle memorie attualmente già a 30 nanometri sia per il sistema di mantenimento delle stesse che non necessita di TRIM o W7
Passo e chiudo.
Adesso ti svelo un segreto : guarda che i sandforce hanno l' ipervisioning garbage collection che è il migliore di tutti perchè è il più avanzato... trovi tutto in rete a riguardo.
Passo e chiudo non chiedere tabelle, perchè non ho tempo di postartele. ;)
Evangelion01
04-11-2010, 15:43
Tirannosaurus , oltretutto nei link che avevi postato, anand parla di bgc ma non dice assolutamente che è uguale al trim, come hai scritto tu nella discussione che hai creato ( e infatti sono 2 cose diverse, anche se nate col medesimo scopo ).
E cmq dice che è implementato anche nei controller indilinx , ed è vero, dato che io ho avuto 2 vertex in raid0 e li ho potuti testare proprio a riguardo.
Risultato? il degrado si riduceva momentaneamente ma non di molto e si ripresentava poco dopo, segno che il bgc era poco efficace. Cosa confermata dal tuo stesso link dove Anand dice :"While Indilinx is following in Samsung's footsteps with enabling idle garbage collection, I believe it's a mistake. Personally, real TRIM support (or at least the wiper tool) is the way to go and it sounds like we’ll be getting it for most if not all of these SSDs in the next couple of months. Idle garbage collection worries me.":asd:
Ovvero : il VERO trim è tutta un' altra cosa. :read:
Preso pari pari dal tuo post.
:D
.
Adesso ti svelo un segreto : guarda che i sandforce hanno l' ipervisioning garbage collection che è il migliore di tutti perchè è il più avanzato... trovi tutto in rete a riguardo.
Passo e chiudo non chiedere tabelle, perchè non ho tempo di postartele. ;)
Cartellino giallo. ;)
Non voglio provocazioni grazie. Scriva in questo thread chi ha qualcosa di tecnico da dire. Il resto dei commenti teneteveli per voi.
- CRL -
Non ho neanche fatto a tempo a complimentarmi per il topic che... :rolleyes: :muro:
Evangelion01
04-11-2010, 15:52
Cartellino giallo. ;)
Non voglio provocazioni grazie. Scriva in questo thread chi ha qualcosa di tecnico da dire. Il resto dei commenti teneteveli per voi.
- CRL -
Scusa, hai ragione. Cmq ho postato sotto la mia esperienza coi vertex in raid0.
Se vado a cercare dovrei avere anche gli screenshot che dimostrano che il bgc è poco efficace. A memoria ricordo che il gain era più o meno del 10-15% dopo una sessione di 8 ore di idle. :O
Evangelion01
04-11-2010, 16:12
Ecco gli screen, li avevo conservati. :p
Gli hd, 2 ocz vertex da 30 gb in raid0, erano pieni al 70-80% circa.
Il primo è stato preso dopo un po' di utilizzo
http://img830.imageshack.us/img830/4338/270709nogc.jpg (http://img830.imageshack.us/i/270709nogc.jpg/)
Il secondo dopo una bella sessione di bgc ( o idle gc, è la stessa cosa ) durata svariate ore.
http://img253.imageshack.us/img253/8639/220709gc.jpg (http://img253.imageshack.us/i/220709gc.jpg/)
Come si può vedere c'è un certo gain, tuttavia non così eclatante, e localizzato quasi solo sul sequenziale.
Certo, meglio di niente, ma ben lontano dal risolvere i problemi di degrado.
The_Saint
04-11-2010, 16:35
Ecco gli screen, li avevo conservati. :p
Gli hd, 2 ocz vertex da 30 gb in raid0, erano pieni al 70-80% circa.
Il primo è stato preso dopo un po' di utilizzo
http://img607.imageshack.us/img607/5021/220709.jpg (http://img607.imageshack.us/i/220709.jpg/)
Il secondo dopo una bella sessione di bgc ( o idle gc, è la stessa cosa ) durata svariate ore.
http://img253.imageshack.us/img253/8639/220709gc.jpg (http://img253.imageshack.us/i/220709gc.jpg/)
Come si può vedere c'è un certo gain, tuttavia non così eclatante, e localizzato quasi solo sul sequenziale.
Certo, meglio di niente, ma ben lontano dal risolvere i problemi di degrado.Nel primo screen c'era qualcos'altro che non andava... il degrado influenza solo le prestazioni di scrittura, non quelle in lettura...
.
Adesso ti svelo un segreto : guarda che i sandforce hanno l' ipervisioning garbage collection che è il migliore di tutti perchè è il più avanzato... trovi tutto in rete a riguardo.
Passo e chiudo non chiedere tabelle, perchè non ho tempo di postartele. ;)
Non esiste nulla da leggere a riguardo. Mi sa tanto che ti sei sbagliato a scrivere..........mi fermo qua.
Non esiste nulla da leggere a riguardo. Mi sa tanto che ti sei sbagliato a scrivere..........mi fermo qua.
Era ironico. Non esiste.
- CRL -
Evangelion01
04-11-2010, 17:58
Era ironico. Non esiste.
- CRL -
Infatti.. :D
Evangelion01
04-11-2010, 18:01
Nel primo screen c'era qualcos'altro che non andava... il degrado influenza solo le prestazioni di scrittura, non quelle in lettura...
Eppure sono genuini al 100%. ;)
magari è dovuto al modo in cui agisce il gc.
The_Saint
04-11-2010, 18:08
Eppure sono genuini al 100%. ;)
magari è dovuto al modo in cui agisce il gc.Non credo... uso SSD con controller Indilinx anche io e senza TRIM, dato che sono con Windows XP e non ho mai notato un calo il lettura...
Evangelion01
04-11-2010, 18:18
Non credo... uso SSD con controller Indilinx anche io e senza TRIM, dato che sono con Windows XP e non ho mai notato un calo il lettura...
Boh, non so che dirti... a me dava questi result, non avrei alcun beneficio a taroccare screen... :stordita:
E cmq ho fatto gli stessi test con atto, che mi ha confermato la cosa.
Stesse modalità, stessi hd.
Prima
http://img510.imageshack.us/img510/1461/240709nogc.jpg (http://img510.imageshack.us/i/240709nogc.jpg/)
Dopo
http://img713.imageshack.us/img713/8794/240709gc.jpg (http://img713.imageshack.us/i/240709gc.jpg/)
Evangelion01
04-11-2010, 18:28
Cmq nel 1° post ho sbagliato il 1° screen,:rolleyes: era di un altro test... ho messo quello giusto, e infatti le differenze sono molto più risicate, a conferma di ciò che dico. ;)
p.s. per fortuna hai quotato, così si vede l' errore e la differenza.
Grazie per avermelo fatto notare. :mano:
:help:
Mi permetto rispettosamente di far notare ai "contendenti" che gli OCZ di cui stanno parlando poco o nulla hanno a che vedere con i Vertex 2 "ultimo tipo" (come spiegato nel primo post a pagina 2...) che sono dotati di tutt'altre caratteristiche per evitare i suddetti problemi prestazionali in scrittura in assenza di un TRIM software... :read:
tirannosaurorex
05-11-2010, 06:34
Nel 2003 quando Western Digital e Seagate producevano hard disk da 3.5" 40GB alti 26 millimetri Samsung riusciva a farli alti 17 millimetri cioè 8 millimetri in meno.
Intel ha annunciato le nand da 25 nanometri (come se fosse la panacea di tutti i mali)
Samsung ha annunciato le nand da 20 nanometri
Gli SSD Samsung con celle di memoria a 30 nanometri sono una realtà acquistabile nei negozi già adesso cioè già oggi e da un bel pò di mesi.
Io non intervengo più perché quando si nega un' evidenza così colossale è completamente inutile continuare a discutere.
Chi vuole documentarsi però le informazioni le trova in rete.
Marinelli
05-11-2010, 07:25
Nel 2003 quando Western Digital e Seagate producevano hard disk da 3.5" 40GB alti 26 millimetri Samsung riusciva a farli alti 17 millimetri cioè 8 millimetri in meno.
E questo cosa c'entra con la discussione?
Ciò non fa altro che confermare quanto ho scritto in precedenza.
Basta, che dici?
Ciao!
Evangelion01
05-11-2010, 08:50
Vabbè , si è già detto di non usare toni provocatori, ma qui sembra che si tenti in tutti i modi di flammare...
The_Saint
05-11-2010, 09:36
Nel 2003 quando Western Digital e Seagate producevano hard disk da 3.5" 40GB alti 26 millimetri Samsung riusciva a farli alti 17 millimetri cioè 8 millimetri in meno.
...
Chi vuole documentarsi però le informazioni le trova in rete.Non serve andare in rete, a casa ho un "Maxtor DiamondMax Plus 8", altezza 17mm, prodotto nel 2003... i Samsung sono usciti subito dopo i Maxtor, come puoi vedere qui:
http://www.xbitlabs.com/articles/storage/display/samsung-pl40.html#sect0
Tra l'altro cmq i dischi low profile erano fuori standard ed erano prodotti solo per risparmiare...
Perdonatemi l'OT. :p
Intel ha annunciato le nand da 25 nanometri (come se fosse la panacea di tutti i mali)
Samsung ha annunciato le nand da 20 nanometri
Gli SSD Samsung con celle di memoria a 30 nanometri sono una realtà acquistabile nei negozi già adesso cioè già oggi e da un bel pò di mesi.Gli Intel utilizzano da + di un anno NAND da 34nm...
Cmq questo discorso non c'entra nulla con il background garbage collection, sarei felice di conoscere i dettagli ed i test della tecnologia utilizzata nei Samsung... sto ancora aspettando una risposta da te, non cambiare discorso. :)
Gradirei che gli utenti del thread siano tanto intelligenti da non cogliere "inutili" provocazioni, che non aiutano la discussione, il confronto e lo scambio di idee.
Cerchiamo di non spostare la discussione su una guerra tra marchi e produttori che a nulla serve, se non ad alimentare flame e marchette.
Non fatemi pentire di questo post,
Grazie :D.
K Reloaded
05-11-2010, 10:33
Gradirei che gli utenti del thread siano tanto intelligenti da non cogliere "inutili" provocazioni, che non aiutano la discussione, il confronto e lo scambio di idee.
Cerchiamo di non spostare la discussione su una guerra tra marchi e produttori che a nulla serve, se non ad alimentare flame e marchette.
Non fatemi pentire di questo post,
Grazie :D.
quoto, anche perchè la questione sta diventando 'noiosa'. :O
Domanda gli "OCZ RevoDrive x2 PCIe SSD " essendo un raid di controller sandforce non supporta il TRIM tuttavia come si comporta con il garbage collector? qualcuno di voi li ha provati? sa darmi qualche info o consiglio.
grazie
Domanda gli "OCZ RevoDrive x2 PCIe SSD " essendo un raid di controller sandforce non supporta il TRIM tuttavia come si comporta con il garbage collector? qualcuno di voi li ha provati? sa darmi qualche info o consiglio.
grazie
Essendo una funzionalità "firmware" la configurazione in single o in RAID su un controller apposito non ne influenza il funzionamento.
Trovi conferma leggendo qui: http://www.anandtech.com/show/3997/ocz-revodrive-x2-review/4
Nell'articolo però si sottolinea come la sola funzionalità di GC non basti a tenere al top le prestazioni delle unità, e che quindi perdere il TRIM in favore di una configurazione RAID può essere un arma a doppio taglio.
Nel 2003 quando Western Digital e Seagate producevano hard disk da 3.5" 40GB alti 26 millimetri Samsung riusciva a farli alti 17 millimetri cioè 8 millimetri in meno.
I dischi con 1 solo piatto sono stati da alcuni produttori prodotti nel formato slim, ma altri hanno deciso di usare lo stesso formato esterno e poi mettere piu' o meno piatti dentro; non credo questo sia un indicatore della qualita' del prodotto. I primi dischi con 40GB per piatto sono stati gli IBM Deskstar 60GXP e i Maxtor D740X, entrambi in produzione nel 2001-2002. Se non sbaglio il D740X aveva il formato slim, l'altro non credo, ma come detto non ritengo sia un parametro significativo.
Cmq, parlando di pietre miliari nel settore HDD a piatti magnetici, non credo che Samsung abbia nessun traguardo significativo:
Primo Disco con Tagged Command Queueing: IBM DeskStar 60GXP, 2001
Disco piú performante pre NCQ e Perp. Rec: IBM Deskstar 120GXP, 2002
Primo disco con Native Command Queueing: Seagate 7200.7, 2003
Primo disco 2.5" con Perpendicular Rec: Seagate Momentum 5400.3, 2006
Primo disco 3.5" da 1TB: Hitachi 7K1000, 2007
Primo disco 3.5" da 1.5TB: Seagate 7200.11, 2008
Primo disco 3.5" da 2TB: WD Caviar Green, 2009
Sul versante prestazioni samsung e' stata sempre dietro, forse escluso lo spinpoint da 500GB che aveva un transfer sequenziale max molto elevato. Sono stati dischi molto silenziosi, questo si', sono stati consigliati da molti siti di silent pc.
Tutto questo e' cmq OT e non vedo come sia legato al discorso SSD, sul quale preferirei ci concentrassimo tutti.
- CRL -
Devo aver attivato inavvertitamente l'invisible mode... :mbe:
No, ma continuate a "flammare" pure... :rolleyes:
Essendo una funzionalità "firmware" la configurazione in single o in RAID su un controller apposito non ne influenza il funzionamento.
Trovi conferma leggendo qui: http://www.anandtech.com/show/3997/ocz-revodrive-x2-review/4
Nell'articolo però si sottolinea come la sola funzionalità di GC non basti a tenere al top le prestazioni delle unità, e che quindi perdere il TRIM in favore di una configurazione RAID può essere un arma a doppio taglio.
Non esattamente... :mbe:
Quello che si fa presente nell'articolo è che, a causa di un bug nel firmware dell'unità (sicuramente legato al discorso "extended capacity"...), se l'unità viene riempita di dati non comprimibili (tutte le SSD che "si rispettino" comprimono i dati al loro interno, pur non mostrando all'utente lo spazio aggiuntivo bensì tenendoselo per i loro usi "interni" di wear spanning & simili...) non è più in grado di far funzionare adeguatamente la funzione di "background garbage collection" (che, personalmente, ritengo una soluzione più "elegante" del TRIM tecnicamente parlando... indipendentemente dalla sua efficienza o meno... ;) )
Questo, come dicevo, probabilmente è legato all'adozione sull'unità da parte di OCZ (al contrario di quanto consigliato da SandForce nelle specifiche ufficiali...) della "capacità estesa", cioè della riduzione dello spazio (di solito intorno al 20%) "riservato" che l'unità non mostra all'utente per sopperire, appunto, a celle difettose ed alle funzioni di "sistemazione delle celle" (che sia TRIM, garbage collection o semplice wear spanning poco cambia, le celle servono comunque, dove più dove meno...).
Probabilmente quelli della OCZ hanno "contato troppo" sullo spazio aggiuntivo lasciato dalla compressione (che si sommerebbe al 20% di cui sopra...) tanto che, in usi limite (disco pieno e di roba non comprimibile), il firmware va in crisi e non sa più come fare... :mc:
Ad ogni modo, questi problemi, così come il discorso TRIM vs. "garbage colletion", dal punto di vista puramente teorico delle cose hanno poco senso: non vi è alcuna ragione tecnica per cui un algoritmo di "garbage collection" efficace non dovrebbe essere in grado di riportare il disco in condizioni ideali a differenza del TRIM. Anzi! Per come funziona - sempre in teoria - è più intelligente del TRIM, perché l'overhead dato dalla "sistemazione" delle celle viene fatto pesare in momenti di inutilizzo del disco, al contrario di quanto accade con il TRIM ove, per questioni di "somma di lavoro da fare", potrebbe essere obbligato a mettersi a sistemare le celle mentre l'utente avrebbe bisogno delle maggiori prestazioni...
D'altra parte non dimentichiamo un altro fatto poco trascurabile... anche la maggior parte degli hard disk una volta riempiti accusano cali sensibili nelle prestazioni, per non parlare di Windows che, di solito, senza almeno il 15% di spazio libero "non garantisce" sull'esito di una eventuale deframmentazione...
Detto questo, il punto è che, allo stato attuale delle cose, pare che il TRIM sia più a punto/più efficace soprattutto perché è più facile da implementare (è più facile se ti dico una cosa invece che se te la devi andare a cercare...), mentre gli algoritmi di "garbage collection", in media, paiono essere un po' più indietro con la messa a punto (quali più, quali meno... quelli degli OCZ Vertex 2 ultimo tipo sembrano essere fra i più efficienti allo stato attuale delle cose...).
E' una tecnologia tutto sommato nuova, è normale che richieda ottimizzazione e messe a punto.
MA, ripeto, una volta ottimizzati (quindi potrebbe bastare un semplice update firmware, considerazioni di opportunità commerciale a parte...:rolleyes: ) i due sistemi non dovrebbero fornire prestazioni distinte: semplicemente perché non vi è alcuna ragione reale per cui ciò accada... ;)
K Reloaded
05-11-2010, 20:16
Non esattamente... :mbe:
Quello che si fa presente nell'articolo è che, a causa di un bug nel firmware dell'unità (sicuramente legato al discorso "extended capacity"...), se l'unità viene riempita di dati non comprimibili (tutte le SSD che "si rispettino" comprimono i dati al loro interno, pur non mostrando all'utente lo spazio aggiuntivo bensì tenendoselo per i loro usi "interni" di wear spanning & simili...) non è più in grado di far funzionare adeguatamente la funzione di "background garbage collection" (che, personalmente, ritengo una soluzione più "elegante" del TRIM tecnicamente parlando... indipendentemente dalla sua efficienza o meno... ;) )
Questo, come dicevo, probabilmente è legato all'adozione sull'unità da parte di OCZ (al contrario di quanto consigliato da SandForce nelle specifiche ufficiali...) della "capacità estesa", cioè della riduzione dello spazio (di solito intorno al 20%) "riservato" che l'unità non mostra all'utente per sopperire, appunto, a celle difettose ed alle funzioni di "sistemazione delle celle" (che sia TRIM, garbage collection o semplice wear spanning poco cambia, le celle servono comunque, dove più dove meno...).
Probabilmente quelli della OCZ hanno "contato troppo" sullo spazio aggiuntivo lasciato dalla compressione (che si sommerebbe al 20% di cui sopra...) tanto che, in usi limite (disco pieno e di roba non comprimibile), il firmware va in crisi e non sa più come fare... :mc:
Ad ogni modo, questi problemi, così come il discorso TRIM vs. "garbage colletion", dal punto di vista puramente teorico delle cose hanno poco senso: non vi è alcuna ragione tecnica per cui un algoritmo di "garbage collection" efficace non dovrebbe essere in grado di riportare il disco in condizioni ideali a differenza del TRIM. Anzi! Per come funziona - sempre in teoria - è più intelligente del TRIM, perché l'overhead dato dalla "sistemazione" delle celle viene fatto pesare in momenti di inutilizzo del disco, al contrario di quanto accade con il TRIM ove, per questioni di "somma di lavoro da fare", potrebbe essere obbligato a mettersi a sistemare le celle mentre l'utente avrebbe bisogno delle maggiori prestazioni...
D'altra parte non dimentichiamo un altro fatto poco trascurabile... anche la maggior parte degli hard disk una volta riempiti accusano cali sensibili nelle prestazioni, per non parlare di Windows che, di solito, senza almeno il 15% di spazio libero "non garantisce" sull'esito di una eventuale deframmentazione...
Detto questo, il punto è che, allo stato attuale delle cose, pare che il TRIM sia più a punto/più efficace soprattutto perché è più facile da implementare (è più facile se ti dico una cosa invece che se te la devi andare a cercare...), mentre gli algoritmi di "garbage collection", in media, paiono essere un po' più indietro con la messa a punto (quali più, quali meno... quelli degli OCZ Vertex 2 ultimo tipo sembrano essere fra i più efficienti allo stato attuale delle cose...).
E' una tecnologia tutto sommato nuova, è normale che richieda ottimizzazione e messe a punto.
MA, ripeto, una volta ottimizzati (quindi potrebbe bastare un semplice update firmware, considerazioni di opportunità commerciale a parte...:rolleyes: ) i due sistemi non dovrebbero fornire prestazioni distinte: semplicemente perché non vi è alcuna ragione reale per cui ciò accada... ;)
quindi prescindendo dalle ottimizzazioni, se ho ben capito tu equipari le due 'istruzioni' ... però c'è da dire che una viene effettuata via SW l'altra via HW (sempre che abbia capito bene) e se la mia esperienza non m'inganna un'operazione effettuata via HW è tendenzialmente meglio che una effettuata via SW ... tralascio la spiegazione logica di questo in quanto mi pare lapalissiano.
Non esattamente... :mbe:
Quello che si fa presente nell'articolo è che, a causa di un bug nel firmware dell'unità (sicuramente legato al discorso "extended capacity"...), se l'unità viene riempita di dati non comprimibili (tutte le SSD che "si rispettino" comprimono i dati al loro interno, pur non mostrando all'utente lo spazio aggiuntivo bensì tenendoselo per i loro usi "interni" di wear spanning & simili...) non è più in grado di far funzionare adeguatamente la funzione di "background garbage collection" (che, personalmente, ritengo una soluzione più "elegante" del TRIM tecnicamente parlando... indipendentemente dalla sua efficienza o meno... ;) )
Questo, come dicevo, probabilmente è legato all'adozione sull'unità da parte di OCZ (al contrario di quanto consigliato da SandForce nelle specifiche ufficiali...) della "capacità estesa", cioè della riduzione dello spazio (di solito intorno al 20%) "riservato" che l'unità non mostra all'utente per sopperire, appunto, a celle difettose ed alle funzioni di "sistemazione delle celle" (che sia TRIM, garbage collection o semplice wear spanning poco cambia, le celle servono comunque, dove più dove meno...).
Probabilmente quelli della OCZ hanno "contato troppo" sullo spazio aggiuntivo lasciato dalla compressione (che si sommerebbe al 20% di cui sopra...) tanto che, in usi limite (disco pieno e di roba non comprimibile), il firmware va in crisi e non sa più come fare... :mc:
Ad ogni modo, questi problemi, così come il discorso TRIM vs. "garbage colletion", dal punto di vista puramente teorico delle cose hanno poco senso: non vi è alcuna ragione tecnica per cui un algoritmo di "garbage collection" efficace non dovrebbe essere in grado di riportare il disco in condizioni ideali a differenza del TRIM. Anzi! Per come funziona - sempre in teoria - è più intelligente del TRIM, perché l'overhead dato dalla "sistemazione" delle celle viene fatto pesare in momenti di inutilizzo del disco, al contrario di quanto accade con il TRIM ove, per questioni di "somma di lavoro da fare", potrebbe essere obbligato a mettersi a sistemare le celle mentre l'utente avrebbe bisogno delle maggiori prestazioni...
D'altra parte non dimentichiamo un altro fatto poco trascurabile... anche la maggior parte degli hard disk una volta riempiti accusano cali sensibili nelle prestazioni, per non parlare di Windows che, di solito, senza almeno il 15% di spazio libero "non garantisce" sull'esito di una eventuale deframmentazione...
Non esattamente :D ...
Gli Hard Disk tradizionali sono soggetti a quel tipo di calo prestazionale per un fatto molto semplice, dovuta alla loro architettura meccanica piatto-testina, cosa che negli SSD non c'è vista l'assenza di parti meccaniche in movimento, così si spiega anche la forza degli SSD nell'accesso casuale contro i piatti rotanti di mazinga a 10k rpm :D.
Quindi il decadimento prestazionale degli SSD in generale dovuto alla saturazione del disco è frutto di quelle operazioni che alcuni post fa ho descritto come "lscrivi-cancella-scrivi-scrivi-cancella-scrivi-scrivi....etc."
Detto ciò per quanto riguarda gli SSD OCZ oggetto della discussione, sicuramente vale quello che hai scritto tu, purtroppo è una scelta costruttiva di OCZ con delle controindicazioni non indifferenti.
Detto questo, il punto è che, allo stato attuale delle cose, pare che il TRIM sia più a punto/più efficace soprattutto perché è più facile da implementare (è più facile se ti dico una cosa invece che se te la devi andare a cercare...), mentre gli algoritmi di "garbage collection", in media, paiono essere un po' più indietro con la messa a punto (quali più, quali meno... quelli degli OCZ Vertex 2 ultimo tipo sembrano essere fra i più efficienti allo stato attuale delle cose...).
E' una tecnologia tutto sommato nuova, è normale che richieda ottimizzazione e messe a punto.
MA, ripeto, una volta ottimizzati (quindi potrebbe bastare un semplice update firmware, considerazioni di opportunità commerciale a parte...:rolleyes: ) i due sistemi non dovrebbero fornire prestazioni distinte: semplicemente perché non vi è alcuna ragione reale per cui ciò accada... ;)
Sicuramente sono tecnologie con grossi margini di miglioramento, e credo che la volontà dei produttori sia quella di trasferire il grosso dell'overhead sui controller rendendo così queste funzionalità indipendenti dai sistemi operativi e dalle configurazioni degli utenti, insomma la filosofia è sempre quella del plug-and-play :D
Cmq in generale l'algoritmo di Garbage Collection non sostituisce il TRIM ma sono complementari, ecco anche il perché uno viene implementato via firmware e l'altro a livello software(o quasi).
quindi prescindendo dalle ottimizzazioni, se ho ben capito tu equipari le due 'istruzioni' ... però c'è da dire che una viene effettuata via SW l'altra via HW (sempre che abbia capito bene) e se la mia esperienza non m'inganna un'operazione effettuata via HW è tendenzialmente meglio che una effettuata via SW ... tralascio la spiegazione logica di questo in quanto mi pare lapalissiano.
Per la precisione via "firmware" (del controller incluso nelle SSD)...
Per il resto io la penso allo stesso modo.
Anche "concettualmente parlando", ritengo più corretto che un'unità sia in grado di "mantenersi da sola" e non con gli "aiuti da casa" del SO... ;)
Non esattamente :D ...
Gli Hard Disk tradizionali sono soggetti a quel tipo di calo prestazionale per un fatto molto semplice, dovuta alla loro architettura meccanica piatto-testina, cosa che negli SSD non c'è vista l'assenza di parti meccaniche in movimento, così si spiega anche la forza degli SSD nell'accesso casuale contro i piatti rotanti di mazinga a 10k rpm :D.
Mai sostenuto il contrario... di più, sono vincenti anche contro i SAS da 15k rpm...
Facevo solo notare che, se con gli SSD abbiamo "qualche problema prestazionale" quando sono quasi pieni, con gli HDD... pure!
(da qui tecniche come lo "short stroking" sugli hard disk... utilizzatela sugli SSD e vedrete se la "garbage collection" funziona bene dopo!!! :read: )
Quindi il decadimento prestazionale degli SSD in generale dovuto alla saturazione del disco è frutto di quelle operazioni che alcuni post fa ho descritto come "lscrivi-cancella-scrivi-scrivi-cancella-scrivi-scrivi....etc."
Detto ciò per quanto riguarda gli SSD OCZ oggetto della discussione, sicuramente vale quello che hai scritto tu, purtroppo è una scelta costruttiva di OCZ con delle controindicazioni non indifferenti.
E' principalmente un discorso commerciale: alla OCZ non sono stupidi (tutt'altro!).
Se hanno visto che riescono a vendere dei dischi da 60 GB invece che da 50 ad un prezzo competitivo, di poco superiore ai 50 della concorrenza - guadagnandoci peraltro di più... dato che per loro l'unica differenza è nel firmware! - e con prestazioni, tutto sommato, similari, perché non farlo? ;)
Sicuramente sono tecnologie con grossi margini di miglioramento, e credo che la volontà dei produttori sia quella di trasferire il grosso dell'overhead sui controller rendendo così queste funzionalità indipendenti dai sistemi operativi e dalle configurazioni degli utenti, insomma la filosofia è sempre quella del plug-and-play :D
Esatto. Ed è secondo me quella più corretta anche "concettualmente", come dicevo anche nel precedente post...
Cmq in generale l'algoritmo di Garbage Collection non sostituisce il TRIM ma sono complementari, ecco anche il perché uno viene implementato via firmware e l'altro a livello software(o quasi).
Se hai analizzato in dettaglio come funziona a livello "di logica" un algoritmo di "background garbage collection" (o, più correttamente, di "idle garbage collection"...) ti sarai reso conto che fa esattamente le stesse cose del TRIM.
Solo in maniera diversa.
Per fare un paragone esemplificativo con i vecchi hard disk, è come avere due differenti programmi di deframmentazione: uno più immediato e rapido ma da eseguire manualmente (tipo XP...), l'altro che lavora in background in maniera autonoma quando ritiene sia il caso (tipo Win 7)...
Alla fine, in un modo o nell'altro, il risultato è il solito: un disco deframmentato.
Se, per il momento, il TRIM appare più efficace è, a mio modestissimo parere, solo perché è più semplice da implementare e pertanto più avanti nella "messa a punto"... esattamente come una volta si credeva che la deframmentazione si potesse fare solo un modalità "monotasking a bocce ferme". Poi siamo passati alla deframmentazione a windows in funzione, infine addirittura a quella autonoma in background...
(e proprio ora che è ottimizzata, con gli SSD non servirà più! ;) )
Ma sono pressoché certo che il futuro (vista anche l'impossibilità tecnica, salvo "miracoli"... di implementare il TRIM in configurazioni RAID, soprattutto quelle avanzate!) sarà per l'adozione della garbage collection in maniera più universale...
Il problema semmai è un'altro... che, temo, almeno in determinate configurazioni RAID anche un'algoritmo di garbage collection potrebbe trovare moolte difficoltà ad operare al meglio... :mc:
Per stemperare un po' la tensione che si è creata qui sull'argomento... vi lascio con questo (http://www.youtube.com/watch?v=96dWOEa4Djs) video che sicuramente... vi colpirà! :read:
P.S.: volete diventare ricchi? Ideate un algoritmo concettualmente valido per far funzionare il TRIM anche su configurazioni RAID e proponetelo ad un produttore di SSD a caso... ;)
The_Saint
05-11-2010, 21:09
quindi prescindendo dalle ottimizzazioni, se ho ben capito tu equipari le due 'istruzioni' ... però c'è da dire che una viene effettuata via SW l'altra via HW (sempre che abbia capito bene) e se la mia esperienza non m'inganna un'operazione effettuata via HW è tendenzialmente meglio che una effettuata via SW ... tralascio la spiegazione logica di questo in quanto mi pare lapalissiano.Il TRIM viene effettuato via hardware... il sistema operativo manda semplicemente il comando di cancellazione dei file ed il firmware dell'SSD fa tutto il resto.
Quindi non parlerei di operazioni effettuate dal software o dall'hardware, ma di operazioni attivate dal sistema operativo ed operazioni indipendenti dal SO.
Cmq fra TRIM e Background Garbage Collection è preferibile il TRIM... il BGC deve essere molto aggressivo per essere efficace, ma questo va a discapito della write amplification ed è per questo che molti produttori non lo implementano nei loro SSD.
Discorso diverso andrebbe fatto (come ho già detto) per i SandForce, dato che il loro algoritmo GC è completamente diverso da quello degli altri...
Mi sono sciroppato tutte le pagine:sofico: mi sento quasi preparato:D
Senza il BGC il Trim sarebbe molto meno efficace.
Il GC (e di conseguenze il BGC) ed il TRIM non possono funzionare indipendentemente dal SO.
Dove si crede non sia implementato il BGC (come per gli Intel) in realtà vi sono algoritmi che, proprio per evitare un aumento della WA con consumo di cicli di scrittura, adottano una sorta di BGC molto più blando che agisce su un ridotto numero di celle nand per volta.
Il TRIM viene effettuato via hardware... il sistema operativo manda semplicemente il comando di cancellazione dei file ed il firmware dell'SSD fa tutto il resto.
Quindi non parlerei di operazioni effettuate dal software o dall'hardware, ma di operazioni attivate dal sistema operativo ed operazioni indipendenti dal SO.
Esatto. Per la precisione: entrambi sono eseguiti dal firmware del disco: il TRIM mediante "imbeccata" da parte del sistema operativo, i BGC (quale che sia...) in maniera del tutto autonoma.
Cmq fra TRIM e Background Garbage Collection è preferibile il TRIM... il BGC deve essere molto aggressivo per essere efficace, ma questo va a discapito della write amplification ed è per questo che molti produttori non lo implementano nei loro SSD.
Discorso diverso andrebbe fatto (come ho già detto) per i SandForce, dato che il loro algoritmo GC è completamente diverso da quello degli altri...
Esatto. E' quasi un "TRIM autonomo" (tanto che lo definiscono "Native TRIM"...)
Purtroppo questa parte "intelligente" del loro GC è quella che più facilmente avrà difficoltà a funzionare in configurazioni RAID (per motivi similari alle difficoltà tecniche di passare il TRIM da parte dell'OS in tali configurazioni...), pertanto temo che anche gli stessi finiranno per divenire GC "stupidi" implementati da molti altri produttori...
Il problema, nel caso del RAID, è che manca la collaborazione "nel mezzo", da parte del controller (e relativo driver) cioè!
Solo lui sa "come" ha virtualizzato il sottosistema dischi verso il sistema operativo e come ha suddiviso i dati scritti fra gli stessi verso i dischi.
Perché il tutto funzioni servirebbe un protocollo preciso mediante il quale l'OS possa inviare il TRIM non direttamente al disco bensì al driver del controller, il quale, in base al tipo di RAID implementato ed alla logica di gestione, dovrebbe "tradurlo" in singoli comandi TRIM (diversi ma da quello originario derivati...) da inviare ai singoli dischi.
Fino a che questo non verrà implementato sia l'OS che i dischi avranno difficoltà a svolgere i loro compiti (l'OS per l'impossibilità nell'inviare il TRIM, i dischi per la difficoltà nell'interpretare i dati scritti su di loro così da poter effettuare quella specie di "TRIM autonomo" che gli OCZ più recenti già svolgono e di cui si parlava sopra... ;) )
Il GC (e di conseguenze il BGC) ed il TRIM non possono funzionare indipendentemente dal SO.
Non proprio... il sistema di BGC "intelligente" di OCZ (chiamiamolo Native TRIM se vogliamo...) - da quello che ho capito - vi riesce perché "legge" in autonomia il contenuto del disco.
Per cui fino a che si utilizzano FileSystem che è in grado di "leggere" è in grado di lavorare anche in autonomia.
Il problema col RAID è che, vada per il RAID1, ma con lo 0 ed il 5 ad esempio, il singolo disco che legge? Come fa a comprendere "frazioni" di dati?
Ecco che l'aiuto da parte dell'OS, per mezzo della comunicazione via driver che al momento manca del tutto, diviene fondamentale...
The_Saint
05-11-2010, 21:44
Senza il BGC il Trim sarebbe molto meno efficace.
Il GC (e di conseguenze il BGC) ed il TRIM non possono funzionare indipendentemente dal SO.
Dove si crede non sia implementato il BGC (come per gli Intel) in realtà vi sono algoritmi che, proprio per evitare un aumento della WA con consumo di cicli di scrittura, adottano una sorta di BGC molto più blando che agisce su un ridotto numero di celle nand per volta.
Sono un po' sibilline queste affermazioni... puoi spiegarti meglio?
1. Non vedo il nesso...
2. Il TRIM ok... il BGC perchè no?
3. Se così fosse, non si spiegherebbe il calo delle prestazioni... anche se meno aggressivo, il BGC renderebbe cmq l'SSD meno soggetto al degrado, invece dalle prove effettuate sui G2 ed altri modelli, si è riusciti a riprodurre facilmente mediante test lo "stato di degrado"...
Non proprio... il sistema di BGC "intelligente" di OCZ (chiamiamolo Native TRIM se vogliamo...) - da quello che ho capito - vi riesce perché "legge" in autonomia il contenuto del disco.
Per cui fino a che si utilizzano FileSystem che è in grado di "leggere" è in grado di lavorare anche in autonomia.
Mi citi una fonte nella quale viene affermato che il GC di OCZ (e non il BGC) riesce ad interpretare gli LBA riguardanti i blocchi da considerare modificati all'interno delle pagine delle nand senza ricorrere al sistema operativo e basandosi solo sul tipo di file system?
Sono un po' sibilline queste affermazioni... puoi spiegarti meglio?
1. Non vedo il nesso...
Il nesso sta nel avere ben in mente cosa è il TRIM.
Il SO passa un comado SATA all'SSD indicandogli gli LBA dei dati da cancellare.
A questo punto l'ssd nelle routine di GC prende le pagine delle nand riguardanti quei dati e le cancella senza portarsele dietro (formatta le pagine senza riscriverle da qualche altra parte).
Ne consegue che durate l'idle time il BGC farò proprio questo, aggiungendo un ulteriore layer di miglioramento alle performance.
2. Il TRIM ok... il BGC perchè no?
Se il SO non passa all'ssd i blocchi da considerare non validi il GC non può far nulla e di conseguenza non farà nulla neanche il BGC.
Ovviamente la sua implementazione è lato firmware.
3. Se così fosse, non si spiegherebbe il calo delle prestazioni... anche se meno aggressivo, il BGC renderebbe cmq l'SSD meno soggetto al degrado, invece dalle prove effettuate sui G2 ed altri modelli, si è riusciti a riprodurre facilmente mediante test lo "stato di degrado"...
Il calo di prestazioni si avrà sempre anche dov'è implementato il BGC.
Lo stesso BGC ha bisogno di un minimo di ore per essere efficace (Tony della OCZ, per le prime implementazioni, parlava addirittura di 19/24 ore utili per massimizzare i benefici del BGC).
Ripeto ancora una volta che attualemente il BGC porta comunque dei risvolti negativi relativi alla WA e aumento dei cicli di scrittura.
Alla fine resta sempre un problema: nessuno ha mia fornito dati e/o documenti sul funzionamento specifico e sulle varie ottimizazzioni adottate dai vari sviluppatori.
Si conosce solo il fondamento di tutte queste tecnologie.
The_Saint
06-11-2010, 00:04
Il nesso sta nel avere ben in mente cosa è il TRIM.
Il SO passa un comado SATA all'SSD indicandogli gli LBA dei dati da cancellare.
A questo punto l'ssd nelle routine di GC prende le pagine delle nand riguardanti quei dati e le cancella senza portarsele dietro (formatta le pagine senza riscriverle da qualche altra parte).
Ne consegue che durate l'idle time il BGC farò proprio questo, aggiungendo un ulteriore layer di miglioramento alle performance.Il TRIM viene eseguito subito, quindi il BGC eventualmente non troverà nulla da cancellare...
Se il SO non passa all'ssd i blocchi da considerare non validi il GC non può far nulla e di conseguenza non farà nulla neanche il BGC.
Ovviamente la sua implementazione è lato firmware.Il BGC può leggere le informazioni direttamente dal file-system (ovviamente deve supportarlo), in questo senso dicevo che è indipendente dal SO, non deve aspettare qualche cosa per potersi attivare da solo.
Il calo di prestazioni si avrà sempre anche dov'è implementato il BGC.
Lo stesso BGC ha bisogno di un minimo di ore per essere efficace (Tony della OCZ, per le prime implementazioni, parlava addirittura di 19/24 ore utili per massimizzare i benefici del BGC).
Ripeto ancora una volta che attualemente il BGC porta comunque dei risvolti negativi relativi alla WA e aumento dei cicli di scrittura.Su quest'ultima cosa siamo d'accordo, l'ho scritto anche io poco fa... il BGC attualmente implementato sugli Indilinx è una via di mezzo, ma a quanto pare sembra essere abbastanza efficace ed il tempo che necessita dipende da quanto è stato utilizzato l'SSD...
Alla fine resta sempre un problema: nessuno ha mia fornito dati e/o documenti sul funzionamento specifico e sulle varie ottimizazzioni adottate dai vari sviluppatori.
Si conosce solo il fondamento di tutte queste tecnologie.Questo è vero, anche se di alcuni controller (Intel G2/Indilinx, etc.) un po' di "reverse engineering" è stato fatto mediante test specifici, quindi qualche dato lo abbiamo. :)
Il TRIM viene eseguito subito, quindi il BGC eventualmente non troverà nulla da cancellare... è
In realtà le cose non starebbero proprio così.
In fatti è possibile che dopo che il SO segna i blocchi da poter cancellare l'ssd può pianificare la loro cancellazione (-> link (http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx)).
Questo significa che parte del processo di GC relativo potrebbe rientrare nelle routine di BGC.
Il BGC può leggere le informazioni direttamente dal file-system (ovviamente deve supportarlo), in questo senso dicevo che è indipendente dal SO, non deve aspettare qualche cosa per potersi attivare da solo.
L'attivazione è indipendente dal SO, ma senza SO non saprebbe mai su quali pagine/blocchi agire.
Mi citi una fonte nella quale viene affermato che il GC di OCZ (e non il BGC) riesce ad interpretare gli LBA riguardanti i blocchi da considerare modificati all'interno delle pagine delle nand senza ricorrere al sistema operativo e basandosi solo sul tipo di file system?
Certo... http://www.anandtech.com/show/3997/ocz-revodrive-x2-review/4
cito testualmente (e non è l'unica fonte in tal senso cmq... poi se non è vero non so che dirti, non l'ho fatto io il firmware OCZ, altrimenti sarei sicuramente più ricco... :D )
"SSD controller manufacturers have avoided the TRIM issue by equipping drives with idle garbage collection. The principle behind idle garbage collection is simple. When the SSD controller detects a period of no activity, it can query the file system for available addresses, and then internally mark those addresses for cleaning."
Mi sembra estremamente chiaro come discorso. Ed il sito non mi pare uno di quelli che, solitamente, "conta balle"... ;)
Il nesso sta nel avere ben in mente cosa è il TRIM.
Il SO passa un comado SATA all'SSD indicandogli gli LBA dei dati da cancellare.
A questo punto l'ssd nelle routine di GC prende le pagine delle nand riguardanti quei dati e le cancella senza portarsele dietro (formatta le pagine senza riscriverle da qualche altra parte).
Ne consegue che durate l'idle time il BGC farò proprio questo, aggiungendo un ulteriore layer di miglioramento alle performance.
Se il SO non passa all'ssd i blocchi da considerare non validi il GC non può far nulla e di conseguenza non farà nulla neanche il BGC.Ovviamente la sua implementazione è lato firmware.
In base a quanto scritto sopra... parrebbe proprio di no... :mbe:
Il calo di prestazioni si avrà sempre anche dov'è implementato il BGC.
Lo stesso BGC ha bisogno di un minimo di ore per essere efficace (Tony della OCZ, per le prime implementazioni, parlava addirittura di 19/24 ore utili per massimizzare i benefici del BGC).
Ripeto ancora una volta che attualemente il BGC porta comunque dei risvolti negativi relativi alla WA e aumento dei cicli di scrittura.
Se le cose stanno come dicono sopra, non dovrebbe essere così (almeno con formattazioni "supportate" dal firmware ed una volta che gli stessi andranno a posto almeno...)
Alla fine resta sempre un problema: nessuno ha mia fornito dati e/o documenti sul funzionamento specifico e sulle varie ottimizazzioni adottate dai vari sviluppatori.
Si conosce solo il fondamento di tutte queste tecnologie.
Senza voler minimamente andare in cerca di "polemica" (non avrei neanche il tempo per un eventuale "dibattito"...), qualcosina mi pare di aver portato.
Ovvio che, anche fra chi come me lavora professionalmente nel settore MA non è impiegato nello sviluppo del firmware da parte delle aziende interessate è un po' difficile che si possa trovare qualcuno in grado di fornire dati precisi sulle singole funzionalità degli algoritmi impiegati...
...e questo per due semplici motivi:
1) le case che li stanno sviluppando e che si fanno concorrenza anche e soprattutto su questi punti - oltre che sulle tecniche costruttive da un nanometro più o meno... - hanno tutto l'interesse a stare ben abbottonate in merito...
2) visto che un algoritmo "ideale" al momento pare che non ci sia, chi fosse in grado di svilupparlo, ripeto, sarebbe una persona ricca... :read:
Detto questo, in base alle informazioni che ho reperito in giro, alla lettura attenta delle specifiche e di quanto dichiarato dalle case - almeno in via ufficiale - e sfruttando le basi delle mie conoscenze personali in materia penso di essermi fatto un'idea abbastanza, se non esatta, quanto meno "verosimile" della situazione attuale...
E, ripeto, senza una formalizzazione precisa dei protocolli da utilizzare da parte dell'OS nella comunicazione col driver del controller (SATA, AHCI, RAID o SAS che sia...) per passare i dati del TRIM verso il disco, lo stesso avrà sempre delle situazioni in cui non potrà funzionare...
Esattamente come quella parte ("intelligente"?) del GC (idle o backround che sia...) che va ad agire allo stesso modo del TRIM ma in modalità autonoma di cui si parlava sopra...
Senza una di queste due soluzioni in funzione, la parte "stupida" del GC (quella impiegata fin'ora da quasi tutti i produttori, tranne i più recenti OCZ da quanto mi risulta...) è evidente che non sarà mai così efficace da non introdurre un certo degrado nei tempi di scrittura dei drive SSD...
Questo almeno negli MLC, perché ad esempio i drive prodotti con memorie SLC pare risentano moolto meno di tale effetto (proprio per come funzionano le memorie al loro interno...). Peccato che costino mooolto di più... :rolleyes:
The_Saint
06-11-2010, 15:47
In realtà le cose non starebbero proprio così.
In fatti è possibile che dopo che il SO segna i blocchi da poter cancellare l'ssd può pianificare la loro cancellazione (-> link (http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx)).
Questo significa che parte del processo di GC relativo potrebbe rientrare nelle routine di BGC.Questo è vero, l'operazione di erase della cella è pianificato ma potrebbe essere eseguito in un altro momento, ora ho capito cosa intendevi dire... però la tua affermazione "senza il BGC il Trim sarebbe molto meno efficace" dovrebbe essere il contrario, ovvero "il BCG è meno efficace senza l'ausilio del TRIM"... anche perchè tutti gli SSD che hanno il TRIM, hanno anche un GC che lavora in background, ma la differenza è che i dati su cui lavora sono solo quelli appunto forniti dal TRIM e basta, non hanno routine che provvedono a cercare da sole le celle da ripulire...
L'attivazione è indipendente dal SO, ma senza SO non saprebbe mai su quali pagine/blocchi agire.Questo è ovvio, senza SO non c'è nemmeno bisogno di TRIM o GC! :D
Questo è vero, l'operazione di erase della cella è pianificato ma potrebbe essere eseguito in un altro momento, ora ho capito cosa intendevi dire... però la tua affermazione "senza il BGC il Trim sarebbe molto meno efficace" dovrebbe essere il contrario, ovvero "il BCG è meno efficace senza l'ausilio del TRIM"... anche perchè tutti gli SSD che hanno il TRIM, hanno anche un GC che lavora in background, ma la differenza è che i dati su cui lavora sono solo quelli appunto forniti dal TRIM e basta, non hanno routine che provvedono a cercare da sole le celle da ripulire...
Questo è ovvio, senza SO non c'è nemmeno bisogno di TRIM o GC! :D
Ok alla fine ci siamo capiti. :D
Solo un appunto.
Il BGC lavora sia su pagine/blocchi modificati/sovrascritti che su quelli cancellati.
Ecco perchè dicevo che con il TRIM è più efficace.
Perchè sui blocchi cancellati ("trimmati") ha meno passaggi da compiere: in pratica effettua solo un erase (es. cancellazione di un blocco intero) oppure, rispetto al caso di dati modificati/sovrascritti, un minor numero di riscritture.
Per il funzionamento generale di queste tecnologie abbiamo capito, nei nostri limiti, comunque come funzionano.
Per rispondere a enetec:
diciamo la stessa cosa, solo che quello che volevo far notare è che gli LBA legati ai PBA da qualche parte il GC deve pur prenderli.
Ed è proprio il SO che glieli fornisce.
Tutto quì.
Ok alla fine ci siamo capiti. :D
...
Per rispondere a enetec:
diciamo la stessa cosa, solo che quello che volevo far notare è che gli LBA legati ai PBA da qualche parte il GC deve pur prenderli.
Ed è proprio il SO che glieli fornisce.
Tutto quì.
Esatto. Direttamente (TRIM) o indirettamente (idle GC OCZ) che sia.
Il punto è se sarebbe meglio cercare di investire risorse per cercare di aumentare le possibilità di applicazione del TRIM o se cercare nuovi metodi/algoritmi per rendere più efficace il GC.
O, infine, se migliorare la tecnologia costruttiva per risolvere il problema alla radice.
Oppure, ad esempio, l'adozione di una discreta quantità di cache a bordo dei dischi tale da "mascherare" la reale lentezza di scrittura delle celle MLC non trimmate... (magari col firmware del disco che la adotta come area "di parcheggio temporaneo" dei dati SOLO quando si trova a scrivere su quelle non trimmate, così da ottenere risultati interessanti anche con minori quantità di cache... ;) )
Le soluzione, volendo, si trovano sempre. Diamo tempo al tempo...
Anche perché, cmq, una SSD "rallentata al massimo" da celle non trimmate, rimane sempre nettamente più veloce anche in scrittura di un disco tradizionale, non dimentichiamolo...
Qui si parla se è meglio il caviale o il salmone, ma fino a ieri si mangiava mortadella! :D
tirannosaurorex
07-11-2010, 04:28
volevo anche ricordare, che più scende la scala di nanometri, e più si riducono i cicli di scrittura :fagiano:
Esatto.
Negli SSD della Samsung le NAND sono a 30 nanometri per cui i cicli di scrittura sono più ridotti rispetto agli SSD Intel e filo-Intel.
Approfitto anche per precisare che il Bacground Garbage Collection è stato introdotto da Samsung nei propri SSD nel 2008 essendosi accorti che il semplice Garbage Collection non funzionava.
Il semplice Garbage Collection invece è a tutt' oggi implementato negli SSD Intel e filo-Intel che per funzionare a dovere devono avvalersi del TRIM di W7 via software escludendo però configurazioni degli SSD in RAID dove il TRIM non funzia.
The_Saint
07-11-2010, 07:05
Negli SSD della Samsung le NAND sono a 30 nanometri per cui i cicli di scrittura sono più ridotti rispetto agli SSD Intel e filo-Intel.Mi sa che non hai capito... avere meno cicli di scrittura vuol dire che la cella NAND durerà meno, quindi non è una cosa positiva!
Ad esempio i primi SSD con NAND a 50nm erano garantiti per 10.000 cicli di scrittura, quelle a 35nm per 5.000...
Approfitto anche per precisare che il Bacground Garbage Collection è stato introdotto da Samsung nei propri SSD nel 2008 essendosi accorti che il semplice Garbage Collection non funzionava.Quando Samsung si è accorta di questo, gli SSD con controller Indilinx avevano già l'idle garbage collection.
Il semplice Garbage Collection invece è a tutt' oggi implementato negli SSD Intel e filo-Intel che per funzionare a dovere devono avvalersi del TRIM di W7 via software escludendo però configurazioni degli SSD in RAID dove il TRIM non funzia.Questo è risaputo... ma cosa intendi per SSD filo-Intel? Il controller Intel è usato solo negli SSD Intel.
Sono sempre in attesa dei tuoi test sul BGC Samsung... quando li posti? :)
tirannosaurorex
07-11-2010, 08:00
Ci tengo a precisare che ho una grande ammirazione per la politica commerciale della Intel perché sanno come far quattrini a palate e lo si può riscontrare dai dati del fatturato in aumento nel terzo trimestre di quest' anno.
Molto probabilmente questo è dovuto proprio al fatto di non aver scelto la strada di Samsung di implementare nel controller dell' SSD il Background Garbage Collection ma di scegliere il TRIM implementato nel sistema operativo W7 ... questo chiaramente ha incentivato le vendite per Microsoft perché chi si comprava un SSD Intel o filo-Intel doveva poi per non perdere le prestazioni dell' SSD comprarsi il sistema operativo W7 ma d' altro canto una volta messo nel proprio pc un sistema operativo come W7 che occupa 19GB di spazio sull' SSD qualcuno si sarà accorto che la RAM non era più sufficente e che neanche il processore ce la faceva a trascinarlo, per cui scheda madre nuova + CPU nuova + 8 GB di RAM e la Intel incassa.
Chiaramente non tutti poi si comprano la scheda madre Intel e il processore Intel e non tutti utilizzano W7 ma una buona percentuale SI e il fatturato della Intel cresce come dimostrano i dati.
Questo è un esempio tipico di come le aziende americane lavorino in sinergia per risollevare l' economia ..... mica come le nostre :muro:
Che grandi che sono le aziende americane, di un' astuzia e una furbizia uniche :yeah:
The_Saint
07-11-2010, 08:15
... Molto probabilmente questo è dovuto proprio al fatto di non aver scelto la strada di Samsung di implementare nel controller dell' SSD il Background Garbage Collection ma di scegliere il TRIM implementato nel sistema operativo W7 ... questo chiaramente ha incentivato le vendite per Microsoft perché chi si comprava un SSD Intel o filo-Intel doveva poi per non perdere le prestazioni dell' SSD comprarsi il sistema operativo W7
...
Questo è un esempio tipico di come le aziende americane lavorino in sinergia per risollevare l' economia ..... mica come le nostre :muro:Non è questo il caso, il tuo ragionamento non è corretto... hai tralasciato il fatto Intel insieme al supporto per il TRIM ha rilasciato anche una utility chiamata "Intel SSD Tool" che esegue manualmente il TRIM nei sistemi operativi come Windows XP che non lo supportano nativamente... quindi non c'era nessun bisogno di passare a Win7...
The_Saint
07-11-2010, 08:36
...Oppure, ad esempio, l'adozione di una discreta quantità di cache a bordo dei dischi tale da "mascherare" la reale lentezza di scrittura delle celle MLC non trimmate... (magari col firmware del disco che la adotta come area "di parcheggio temporaneo" dei dati SOLO quando si trova a scrivere su quelle non trimmate, così da ottenere risultati interessanti anche con minori quantità di cache... ;) )
Le soluzione, volendo, si trovano sempre. Diamo tempo al tempo...L'utilizzo di una cache grande crea svariati problemi, fra i quali il consumo, il costo aggiuntivo (intendo costo di produzione) ed il fatto che per evitare la perdita di dati in caso di cali/interruzione della tensione, va implementato anche un sistema che garantisca il tempo di scrivere i dati nelle NAND prima di spegnersi (come un piccolo accumulatore o addirittura una batteria tampone)... è per questo che ad esempio il controller SandForce non integra nessuna cache, ha solo un buffer interno al chip stesso del controller.
Cmq le soluzioni adottate da SF, anche se non perfette, sono molto buone ed innovative rispetto alla concorrenza... vediamo cosa tirano fuori con la nuova serie di controller SF-2000. :)
L'utilizzo di una cache grande crea svariati problemi, fra i quali il consumo, il costo aggiuntivo (intendo costo di produzione) ed il fatto che per evitare la perdita di dati in caso di cali/interruzione della tensione, va implementato anche un sistema che garantisca il tempo di scrivere i dati nelle NAND prima di spegnersi (come un piccolo accumulatore o addirittura una batteria tampone)...
Mai sostenuto il contrario... e ti aggiungo un'altro problema se vuoi, forse uno dei principali: il costo aggiuntivo che comporta.
Però è indubbio che potrebbe essere una delle possibili vie da percorrere...
...è per questo che ad esempio il controller SandForce non integra nessuna cache, ha solo un buffer interno al chip stesso del controller.
Cmq le soluzioni adottate da SF, anche se non perfette, sono molto buone ed innovative rispetto alla concorrenza... vediamo cosa tirano fuori con la nuova serie di controller SF-2000. :)
Concordo. ;)
TigerTank
10-11-2010, 00:42
Ragazzi io ho 2 Crucial C300 da 128GB in raid0. Al momento li ho su controller Intel perchè il Marvell 6 GB fa schifo...
Che mi potete dire circa CG e trim su questi miei ssd? Grazie!
K Reloaded
10-11-2010, 11:15
Ragazzi io ho 2 Crucial C300 da 128GB in raid0. Al momento li ho su controller Intel perchè il Marvell 6 GB fa schifo...
Che mi potete dire circa CG e trim su questi miei ssd? Grazie!
sul raid0 nn funge il TRIM (se ricordo bene) ... come non è confermato il funzionamento del TRIM sul Sata 6gb/s ...
TigerTank
10-11-2010, 12:32
sul raid0 nn funge il TRIM (se ricordo bene) ... come non è confermato il funzionamento del TRIM sul Sata 6gb/s ...
Grazie K, questa cosa aveva spiazzato anche a me però so che i miei ssd con il firmware 002 (i miei ce lo avevano già in partenza) hanno un ottimo GC che invece dovrebbe funzionare bene anche in raid, essendo esclusivamente una funzione inclusa a livello firmware. Vedremo tra un pò di tempo quando riproverò a fare un paio di bench.
K Reloaded
10-11-2010, 12:38
Grazie K, questa cosa aveva spiazzato anche a me però so che i miei ssd con il firmware 002 (i miei ce lo avevano già in partenza) hanno un ottimo GC che invece dovrebbe funzionare bene anche in raid, essendo esclusivamente una funzione inclusa a livello firmware. Vedremo tra un pò di tempo quando riproverò a fare un paio di bench.
si la rev. 002 risolve alcune problematiche che avevano ... :)
Star trek
15-11-2010, 04:31
Potete dare un occhio su quello che ho scritto su : http://www.hwupgrade.it/forum/showpost.php?p=33652531&postcount=464 ?
Grazie
kaZablas
05-12-2010, 00:13
salve raga parlando da nab in materia, ho 2 vertex2 in raid e mi è capitato che dopo qualche settimana ho perso circa 50mb in scrittura al test crystal, ora volevo capire se bisognasse abilitare questo fanigerato Background Garbage Collection che a quanto ho capito deframmenta hdd in background ma la cosa che non capisco è come attivarlo
qualcuno che mi dia una mano grazie anticipatamente:)
The_Saint
05-12-2010, 05:11
salve raga parlando da nab in materia, ho 2 vertex2 in raid e mi è capitato che dopo qualche settimana ho perso circa 50mb in scrittura al test crystal, ora volevo capire se bisognasse abilitare questo fanigerato Background Garbage Collection che a quanto ho capito deframmenta hdd in background ma la cosa che non capisco è come attivarlo
qualcuno che mi dia una mano grazie anticipatamente:)Non va attivato, è una funzione che si attiva automaticamente a livello di controller dell'SSD...
Star trek
05-12-2010, 10:25
Aspetta Saint. Io avevo capito che il BGC fosse attivo sempre attivo poiché facente parte del fimware del disco. Questo nei Corsair Force....negli OCZ è diverso?
The_Saint
05-12-2010, 11:30
Aspetta Saint. Io avevo capito che il BGC fosse attivo sempre attivo poiché facente parte del fimware del disco. Questo nei Corsair Force....negli OCZ è diverso?No, è uguale... infatti ho scritto che non va attivato. ;)
kaZablas
05-12-2010, 11:45
Non va attivato, è una funzione che si attiva automaticamente a livello di controller dell'SSD...
grazie per la info perchè mi stavo scervellando, il vertex2 che ho preso pare sia un s.f-1200 se non sbaglio e ha il penultimo fw 1.22, acquistato 1 mesetto fa e sulla confezione sta scritto trim support e raid capability, quindi la funzione si attiva in automatico deduco?ma la cosa che mi meraviglia come mai ho perso 50mb in scrittura nel crystaldisk da quand era nuovo:confused:
The_Saint
05-12-2010, 17:59
grazie per la info perchè mi stavo scervellando, il vertex2 che ho preso pare sia un s.f-1200 se non sbaglio e ha il penultimo fw 1.22, acquistato 1 mesetto fa e sulla confezione sta scritto trim support e raid capability, quindi la funzione si attiva in automatico deduco?ma la cosa che mi meraviglia come mai ho perso 50mb in scrittura nel crystaldisk da quand era nuovo:confused:La funzione è sempre attiva, ma non è efficiente al 100%... poi cmq a disco pieno le prestazioni calano...
kaZablas
05-12-2010, 19:20
La funzione è sempre attiva, ma non è efficiente al 100%... poi cmq a disco pieno le prestazioni calano...
grazie per risposta:) cmq sentendo un pò in giro e qui, conviene non superare 80% con un vertex2; a saperlo prendevo un 120:muro:
Star trek
05-12-2010, 19:52
Provate a informarvi sulla funzione Hyperfast di Diskeeper.
Star trek
16-12-2010, 14:05
Ho letto con interesse tutte le pagine e ho un quesito da porre.
Considerato che osx non sfrutta il trim,quale ssd è consigliabile prendere in questo momento?
Neanche su Snow?
Star trek
16-12-2010, 19:29
Direi che i Corsair Force e i Samsung lo hanno. Lo so perché stavo guardando per prendere due da mettere in RAID poi sono rimasto fermo a causa della poco chiara vita delle celle. Cmq entro febbraio può darsi che riprenda la questione.
Star trek
17-12-2010, 19:17
Vedrai che ti piacerà...controlla solo di avere anche il trim attivato così sei apposto.
Star trek
21-12-2010, 16:18
Potenzialmente gli SSD sono molto più veloce come AT e TR rispetto al miglior disco meccanico in circolazione. Poi non si sa per quale motivo ma se anche un SSD e tre volte più veloce di un disco meccanico,in molti scenari questa differenza prestazionale non la si nota. Il motivo è semplice e si chiama accesso misto. Nonostante un SSD possa fare molti IOPS in più di un disco meccanico,non significa che il PC triplichi la sua velocità di lavoro. Non c'è solo il disco nel PC. La fregatura degli SSD attuali credo sia nei cicli di scritture che mi pare siamo molto inferiori a un disco meccanico. Quindi un SSD costa molto di più e dura meno però è molto più veloce. Questi sono i pro e i contro delle due tecnologie. Alcune recensioni parlano di tempi di durata notevoli. Io però non so se siano proprio così longevi.
Kimera O.C.
21-02-2011, 09:12
Iscritto per eventuali sviluppi e prove in raid di 2 ssd quipaggiati con BGC
K Reloaded
21-02-2011, 13:24
Potenzialmente gli SSD sono molto più veloce come AT e TR rispetto al miglior disco meccanico in circolazione. Poi non si sa per quale motivo ma se anche un SSD e tre volte più veloce di un disco meccanico,in molti scenari questa differenza prestazionale non la si nota. Il motivo è semplice e si chiama accesso misto. Nonostante un SSD possa fare molti IOPS in più di un disco meccanico,non significa che il PC triplichi la sua velocità di lavoro. Non c'è solo il disco nel PC. La fregatura degli SSD attuali credo sia nei cicli di scritture che mi pare siamo molto inferiori a un disco meccanico. Quindi un SSD costa molto di più e dura meno però è molto più veloce. Questi sono i pro e i contro delle due tecnologie. Alcune recensioni parlano di tempi di durata notevoli. Io però non so se siano proprio così longevi.
3 anni di garanzia te li danno tutti i produttori, il che nn mi sembra poco, dopodichè bastano un paio di piccoli accorgimenti e stressi ancor di meno il disco ... :)
Star trek
21-02-2011, 21:01
Rimane il fatto che quando si parla di affidabilità nel tempo effettiva, messa a confronto con quella dei dischi meccanici, nessuno sa dare una risposta chiara. Si sa che la durata delle celle è limitata come del resto lo è anche quello dei supporti magnetici,però questi ultimi sono stra testati e a meno di difetti evidenti,i dischi durano anni anche tenuti accesi 24 ore al giorno...Con gli SSD è una incognita. Certo che hai la garanzia di 3 anni il che si presume che sia una data minima di durata se il disco rimarrebbe acceso 24 ore al giorno essendo una tecnologia destinata all'ambiente server.
Ovviamente punti di vista personalissimi...destinati ad essere condivisi o no. Ergo IMHO.
The_Saint
21-02-2011, 21:19
Rimane il fatto che quando si parla di affidabilità nel tempo effettiva, messa a confronto con quella dei dischi meccanici, nessuno sa dare una risposta chiara. Si sa che la durata delle celle è limitata come del resto lo è anche quello dei supporti magnetici,però questi ultimi sono stra testati e a meno di difetti evidenti,i dischi durano anni anche tenuti accesi 24 ore al giorno...Con gli SSD è una incognita.Fino ad un certo punto... in questa pagina Anandtech spiega in maniera dettagliata il discorso dei cicli di scrittura delle celle NAND:
http://www.anandtech.com/show/4159/ocz-vertex-3-pro-preview-the-first-sf2500-ssd/2
... salvo usi "impropri" dell'SSD, la durata delle celle è un non-problema... ;)
K Reloaded
22-02-2011, 09:07
Rimane il fatto che quando si parla di affidabilità nel tempo effettiva, messa a confronto con quella dei dischi meccanici, nessuno sa dare una risposta chiara. Si sa che la durata delle celle è limitata come del resto lo è anche quello dei supporti magnetici,però questi ultimi sono stra testati e a meno di difetti evidenti,i dischi durano anni anche tenuti accesi 24 ore al giorno...Con gli SSD è una incognita. Certo che hai la garanzia di 3 anni il che si presume che sia una data minima di durata se il disco rimarrebbe acceso 24 ore al giorno essendo una tecnologia destinata all'ambiente server.
Ovviamente punti di vista personalissimi...destinati ad essere condivisi o no. Ergo IMHO.
a livello teorico hai certamente ragione, essendo il SSD una tecnologia 'nuova' necessita come tutte di ottimizzazioni e miglioramenti, non si discute su questo, però come vedi la situazione non è così 'tradica' ... anzi ;)
Star trek
22-02-2011, 19:17
a livello teorico hai certamente ragione, essendo il SSD una tecnologia 'nuova' necessita come tutte di ottimizzazioni e miglioramenti, non si discute su questo, però come vedi la situazione non è così 'tradica' ... anzi ;)
Ci mancherebbe..con quello che li fanno pagare...Sarebbe come darsi una martellata sui maroni :D .
Tooyalaket
24-02-2011, 18:00
Ciao
A breve usciranno gli Intel 510 ed io vorrei prenderne un paio.
Uno piccolo per Windows 7 e l'altro più grande per i dati.
Vorrei solo una conferma: il trim resta?
Ciao e grazie
K Reloaded
25-02-2011, 10:45
Ciao
A breve usciranno gli Intel 510 ed io vorrei prenderne un paio.
Uno piccolo per Windows 7 e l'altro più grande per i dati.
Vorrei solo una conferma: il trim resta?
Ciao e grazie
certo, perchè nn dovrebbe?
TechnoPhil
18-04-2011, 14:58
Ottima discussione, molto interessante, anche perchè in giro se ne parla parecchio di questo confronto!
Io attualmente ho potuto solo provare un SSD OCZ 120 GB (con garbage collector) sul mio MacBook Pro.
A breve mi arriverà in MacBook Air sul quale è abilitato il TRIM se non ho capito male (ma senza garbage collector).
Semmai posterò le mie impressioni! ;)
K Reloaded
18-04-2011, 20:27
Ottima discussione, molto interessante, anche perchè in giro se ne parla parecchio di questo confronto!
Io attualmente ho potuto solo provare un SSD OCZ 120 GB (con garbage collector) sul mio MacBook Pro.
A breve mi arriverà in MacBook Air sul quale è abilitato il TRIM se non ho capito male (ma senza garbage collector).
Semmai posterò le mie impressioni! ;)
mi pare strano che non ci sia il GC, di che SSD stai parlando?
TechnoPhil
19-04-2011, 10:59
Gli OCZ hanno il GC!
Ecco la mia recensione : http://www.fotografisanmarino.com/viewtopic.php?f=24&t=283
TechnoPhil
24-04-2011, 10:13
Ottima discussione, molto interessante, anche perchè in giro se ne parla parecchio di questo confronto!
Io attualmente ho potuto solo provare un SSD OCZ 120 GB (con garbage collector) sul mio MacBook Pro.
A breve mi arriverà in MacBook Air sul quale è abilitato il TRIM se non ho capito male (ma senza garbage collector).
Semmai posterò le mie impressioni! ;)
Mi correggo!
Ho effettuato la prova su MacBook Air 3,2 il quale ha un SSD Toshiba con controller sempre Toshiba (T6UG1XBG).
Il TRIM non è attivo, ma questo controller ha la Garbage Collection!
Prestazioni di poco inferiori all'SSD OCZ Vertex 2! ;)
deltazor
27-06-2012, 13:08
Iscritto
Star trek
27-06-2012, 17:49
Domanda. Ma il GC funziona anche su controller AMD e in modalità RAID?
Sono un pò fuori dal discorso.
Ciao
deltazor
27-06-2012, 21:40
Domanda. Ma il GC funziona anche su controller AMD e in modalità RAID?
Sono un pò fuori dal discorso.
Ciao
E una funzione del FW dell SSD
Star trek
27-06-2012, 22:45
Allora tutto come prima. ;)
delvo_69
21-09-2012, 11:17
Salve a tutti.
Mi sono letto le pagine della discussione ma vorrei capire una cosa ad oggi!
Su un notebook (dell e4300, che è solo sata 1 ... lo so :cry: ) dove non posso non usare XP, devo cambiare hd. Visto che in XP non c'è il trim, se ho ben capito la migliore garanzia di mantenere prestazioni nel tempo è quella di scegliere un disco con BCG Background Garbage Collection.
E quindi la mia prima domanda è:
1) quali ssd hanno il BCG oggi? tutti?
poi
2) il BCG dove presente e previsto è attivo di default, giusto? Nel senso che il BCG lavora in background indipendentemente da OS o altro, non bisogna controllare niente o attivare niente, giusto?.
3) E poi c'è qualche operazione di "manutenzione" su XP che andrebbe fatta periodicamente per mantenere prestazioni e/o affidabilità e/o longevità?
4) Nelle condizioni di cui sopra, come andrebbe riempito? nel senso quale sarebbe la percentuale di spazio da riempire come miglior compromesso tra affidabilità prestazione e durata? 50-60%? e che relazione c'è tra lo spazio libero e la BCG?
Grazie in anticipo delle vostre info
Star trek
21-09-2012, 14:30
Gli SSD hanno deicicli di riscritura limitata .Ma in utilizzo quotidiano normale il disco dura anni.E' probabile che si cambi disco perchè obsoleto più che esaurito. Cmq basta cercare su GOOGLE . (https://www.google.it/#hl=it&biw=1360&bih=609&sclient=psy-ab&q=ssd%20cosa%20disabilitare&oq=&gs_l=&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=743ac526e5c4490e&pf=p&pdl=300)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.