[SSD] TRIM vs Background Garbage Collection

[Evangelion01]

Originariamente inviato da CRL

Era ironico. Non esiste.

- CRL -

Infatti..

[Evangelion01]

Originariamente inviato da The_Saint

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]

Originariamente inviato da Evangelion01

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]

Originariamente inviato da The_Saint

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...
E cmq ho fatto gli stessi test con atto, che mi ha confermato la cosa.

Stesse modalità, stessi hd.
Prima


Dopo

[Evangelion01]

Cmq nel 1° post ho sbagliato il 1° screen, 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.

[enetec]

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

[tirannosaurorex]

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]

Originariamente inviato da tirannosaurorex

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]

Vabbè , si è già detto di non usare toni provocatori, ma qui sembra che si tenti in tutti i modi di flammare...

[The_Saint]

Originariamente inviato da tirannosaurorex

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/sto...l40.html#sect0
Tra l'altro cmq i dischi low profile erano fuori standard ed erano prodotti solo per risparmiare...

Perdonatemi l'OT.

Originariamente inviato da tirannosaurorex

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.

[zenzip]

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 .

[K Reloaded]

Originariamente inviato da zenzip

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 .

quoto, anche perchè la questione sta diventando 'noiosa'.

[xquadx]

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

[zenzip]

Originariamente inviato da xquadx

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/o...ve-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.

[CRL]

Originariamente inviato da tirannosaurorex

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 -

[enetec]

Devo aver attivato inavvertitamente l'invisible mode...

No, ma continuate a "flammare" pure...

[enetec]

Originariamente inviato da zenzip

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/o...ve-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...

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

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... ) i due sistemi non dovrebbero fornire prestazioni distinte: semplicemente perché non vi è alcuna ragione reale per cui ciò accada...

[Gui35]

Interessante

[K Reloaded]

Originariamente inviato da enetec

Non esattamente...

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

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

[zenzip]

Originariamente inviato da enetec

Non esattamente...

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

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

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

Originariamente inviato da enetec

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

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