Revodrive contro Revodrive X2, SSD OCZ in test

[molochgrifone]

Originariamente inviato da ciocia

aZZ, mi fate venire la tentazione...il 160gb quanto costa?
sirio hai pvt per il link, grazie

405 € + SS

Geizhals, è un trovaprezzi austriaco/tedesco/eu

[misthral]

Se il costo non è un fattore limitante io andrei direttamente sull Ibis sempre di OCZ.

Grossomodo per la stessa cifra si porta a casa il disco da 100GB, con controller HSDL separato.

Credo che 100Gb non facciano la differenza dato che chi cerca questi prodotti è principalmente interessato alle prestazioni piuttosto che allo spazio a disposizione.

[ORS0]

Originariamente inviato da sirioo

in germania dove ho preso il mio revo x2 da 240 gb in questi giorni il prezzo oscilla tra 450/70 euro , il prezzo sicuramente non e alla portata ma rispetto ai prezzi italiani e un altro mondo...

Ciao!

Hai la casella piena...saresti così cortese da inviarmi qualche link
di shoops europei, in pvt?

Grazie!

[sirioo]

Originariamente inviato da ORS0

Ciao!

Hai la casella piena...saresti così cortese da inviarmi qualche link
di shoops europei, in pvt?

Grazie!

trovi qui in 1° pag i prezzi italiani e stranieri : http://www.hwupgrade.it/forum/showthread.php?t=2320077

[sirioo]

Originariamente inviato da molochgrifone

OT: sirioo ogni volta che nella tua firma leggo "i7 920 4.4 1.24v" mi viene voglia di spaccare il monitor

[sirioo]

Originariamente inviato da misthral

Se il costo non è un fattore limitante io andrei direttamente sull Ibis sempre di OCZ.

Grossomodo per la stessa cifra si porta a casa il disco da 100GB, con controller HSDL separato.

Credo che 100Gb non facciano la differenza dato che chi cerca questi prodotti è principalmente interessato alle prestazioni piuttosto che allo spazio a disposizione.

x la precisione la diff ce' oltre allo spazio ma anche sulle prestazioni :

OCZ RevoDrive X2 PCI-Express SSD

Prestazioni:

100GB-160GB Max Performance

* Read: Up to 740 MB/s
* Write: Up to 690 MB/s
* Sustained Write: Up to 550 MB/s
* Random Write 4KB (Aligned): 100,000 IOPS

240GB-960GB Max Performance

* Read: Up to 740 MB/s
* Write: Up to 720 MB/s
* Sustained Write: Up to 600 MB/s
* Random Write 4KB (Aligned): 120,000 IOPS

[shodan]

Originariamente inviato da AceGranger

il TRIM con la durabilita non c'entra una fava

Ciao, questo non è corretto.
Il comando TRIM può avere, anzi ha, un impatto sulla write amplification, aumentandola.

E' per questo motivo che alcuni controller (in particolare in nuovi SF25xx), anche dopo essere stati "trimmati", _non_ cancellano fisicamente le pagine di flash, ma lo fanno opportunisticamente in modo da abbassare quanto più possibile il write amplification.
Certo in questo modo il concetto di TRIM va un po' a monte ma, evidentemente, SF ha scelto di fare più attenzione all'affidabilità che alle prestazioni pure (comunque elevatissime).

Fonte: http://www.anandtech.com/show/4159/o...t-sf2500-ssd/6

Ciao.

[ORS0]

Originariamente inviato da sirioo

trovi qui in 1° pag i prezzi italiani e stranieri : http://www.hwupgrade.it/forum/showthread.php?t=2320077

...grazie!!!!!!!!

[sirioo]

Originariamente inviato da shodan

Ciao, questo non è corretto.
Il comando TRIM può avere, anzi ha, un impatto sulla write amplification, aumentandola.

E' per questo motivo che alcuni controller (in particolare in nuovi SF25xx), anche dopo essere stati "trimmati", _non_ cancellano fisicamente le pagine di flash, ma lo fanno opportunisticamente in modo da abbassare quanto più possibile il write amplification.
Certo in questo modo il concetto di TRIM va un po' a monte ma, evidentemente, SF ha scelto di fare più attenzione all'affidabilità che alle prestazioni pure (comunque elevatissime).

Fonte: http://www.anandtech.com/show/4159/o...t-sf2500-ssd/6

Ciao.

forse qui spiega meglio la cosa : NAND Mortality Rate , mettendo i puntini sulle i quando si parla di compressione in tempo reale dei SF


http://www.anandtech.com/show/4159/o...t-sf2500-ssd/2



The worst write amplification we saw was around 0.6x. Actually, most of the drives we've deployed in house came in at 0.6x. In this particular drive the user (who happened to be me) wrote 1900GB to the drive (roughly 7.7GB per day over 8 months) and the SF-1200 controller in turn threw away 800GB and only wrote 1100GB to the flash. This includes garbage collection and all of the internal management stuff the controller does.
Over this period of time I used only 10 cycles of flash (it was a 120GB drive) out of a minimum of 3000 available p/e cycles. In eight months I only used 1/300th of the lifespan of the drive.

The other drives we had deployed internally are even healthier. It turns out I'm a bit of a write hog.

Paired with a decent SSD controller, write lifespan is a non-issue. Note that I only fold Intel, Crucial/Micron/Marvell and SandForce into this category. Write amplification goes up by up to an order of magnitude with the cheaper controllers. Characterizing this is what I've been spending much of the past six months doing. I'm still not ready to present my findings but as long as you stick with one of these aforementioned controllers you'll be safe, at least as far as NAND wear is concerned.

[shodan]

Originariamente inviato da sirioo

forse qui spiega meglio la cosa : NAND Mortality Rate , mettendo i puntini sulle i quando si parla di sanforce e dati compressi...


http://www.anandtech.com/show/4159/o...t-sf2500-ssd/2

Si, infatti quelle sono probabilmente le motivazione che hanno portato SF a utilizzare, almeno sulla serie SF25xx (enterprise), questo tipo di approccio al TRIM.

Ciao.

[JackZR]

Originariamente inviato da AceGranger

si sono bootabili e ti viene riconosciuto come disco solo se la tua MB è compatibile, l'elenco lo trovi sul sito OCZ

e ancora..... il TRIM non c'entra una fava con la durata; il TRIM reintegra le prestazioni.

il Garbage fa lo stesso lavoro del TRIM; solo che lo fa dilazionato invece che in una botta sola; dopodiche su anand c'è un bell'articolo sulla scrittura dei dati e sulla durata delle NAND

il succo: le menate sulla durata sono solo paranoie

al massimo per la perdita del TRIM, ma avendo il GC e prestazioni elevatissime non è un problema

Ok, giusto per chiarirmi un altro po' le idee vi faccio un altro paio di domande:
- In che cosa differiscono TRIM e GC?
- Si possono usare contemporaneamente sia TRIM che GC?
- Io lo userei come disco per OS e programmi, le prestazioni in che arco di tempo decadrebbero?

[sirioo]

Originariamente inviato da shodan

Si, infatti quelle sono probabilmente le motivazione che hanno portato SF a utilizzare, almeno sulla serie SF25xx (enterprise), questo tipo di approccio al TRIM.

Ciao.

resta il fatto che i SF con la compressione dei dati e riuscita a tenere a bada il write amplification a prescindere dal trim o dal BGC (presente sul revodrive) rispetto ad altri controller



Remember that write amplification is the ratio of NAND writes to host writes. On all non-SF architectures that number should be greater than 1 (e.g. you go to write 4KB but you end up writing 128KB). Due to SF's real time compression/dedupe engine, it's possible for SF drives to have write amplification below 1.

So how did our drives fare?

The worst write amplification we saw was around 0.6x. Actually, most of the drives we've deployed in house came in at 0.6x. In this particular drive the user (who happened to be me) wrote 1900GB to the drive (roughly 7.7GB per day over 8 months) and the SF-1200 controller in turn threw away 800GB and only wrote 1100GB to the flash. This includes garbage collection and all of the internal management stuff the controller does.


So how did our drives fare?

The worst write amplification we saw was around 0.6x. Actually, most of the drives we've deployed in house came in at 0.6x. In this particular drive the user (who happened to be me) wrote 1900GB to the drive (roughly 7.7GB per day over 8 months) and the SF-1200 controller in turn threw away 800GB and only wrote 1100GB to the flash. This includes garbage collection and all of the internal management stuff the controller does.



Over this period of time I used only 10 cycles of flash (it was a 120GB drive) out of a minimum of 3000 available p/e cycles. In eight months I only used 1/300th of the lifespan of the drive.

The other drives we had deployed internally are even healthier. It turns out I'm a bit of a write hog.

Paired with a decent SSD controller, write lifespan is a non-issue. Note that I only fold Intel, Crucial/Micron/Marvell and SandForce into this category. Write amplification goes up by up to an order of magnitude with the cheaper controllers. Characterizing this is what I've been spending much of the past six months doing. I'm still not ready to present my findings but as long as you stick with one of these aforementioned controllers you'll be safe, at least as far as NAND wear is concerned.

[giovanbattista]

in effetti anche questo

http://www.techpowerup.com/141684/OC...ate-Drive.html

Offers a humongous 4 terabyte of storage, higher than even the highest PC hard drive in the market, which offers 3 TB. IBIS XL offers transfer rates of 1800 MB/s read, 1700 MB/s write, and up to 200,000 IOPS 4K random write performance.

era da prendere in considerazione x una comparativa.....cmq sempre + interessanti, speriamo in una discesa dei prezzi..........veloce.


ps con uno di questi puoi dimenticati di spazio/prestazioni/rumore/calore/0 parti inmovimento=resistenza.

se non fosse x il prezzo chiunque lo avrebbe all'interno del proprio pc

[sirioo]

Originariamente inviato da giovanbattista

in effetti anche questo

http://www.techpowerup.com/141684/OC...ate-Drive.html

Offers a humongous 4 terabyte of storage, higher than even the highest PC hard drive in the market, which offers 3 TB. IBIS XL offers transfer rates of 1800 MB/s read, 1700 MB/s write, and up to 200,000 IOPS 4K random write performance.

era da prendere in considerazione x una comparativa.....cmq sempre + interessanti, speriamo in una discesa dei prezzi..........veloce.


ps con uno di questi puoi dimenticati di spazio/prestazioni/rumore/calore/0 parti inmovimento=resistenza.

se non fosse x il prezzo chiunque lo avrebbe all'interno del proprio pc

Li si parla gia della prossima generazione di sistemi ibis xl 4 ma se non vendi un rene la vedo diff che saranno prodotti accessibili a noi umani

[shodan]

Originariamente inviato da sirioo

resta il fatto che i SF con la compressione dei dati e riuscita a tenere a bada il write amplification a prescindere dal trim o dal BGC (presente sul revodrive) rispetto ad altri controller

Vero, infatti reputo i SF controller davvero ottimi.

Comunque, tenere il più basso possibile la WA è obiettivo dichiarato dei SF (per garantire affidabilità anche in caso un produttore decida di usare NAND di qualità inferiore), e quindi non i sorprende vederli applicare il TRIM in modo "rilassato".

Ciao.

[shodan]

Originariamente inviato da JackZR

Ok, giusto per chiarirmi un altro po' le idee vi faccio un altro paio di domande:
- In che cosa differiscono TRIM e GC?
- Si possono usare contemporaneamente sia TRIM che GC?
- Io lo userei come disco per OS e programmi, le prestazioni in che arco di tempo decadrebbero?

Ciao,
approssimando possiamo dire che TRIM e GC sono entrambi due sistemi per assicurarsi che le pagine di memoria flash non più in uso dal filesystem siano davvero liberate, così da garantire la massima velocità in fase di riutilizzo di quelle stesse pagine.

Il GC si occupa di pulire tali pagine quando il disco non è in uso o, comunque, quando il firmware del controller decide che è ora di intervenire. In questo modo hai un disco che si "autopulisce", senza bisogno di un intervento specifico da parte del s.o. Il contro è che il disco potrebbe scegliere il momento sbagliato per eseguire il GC, oppure l'esatto opposto, cioè ritardare troppo la pulizia.

Il comando TRIM fa essenzialmente la stessa cosa, ma su richiesta dell'utente: quando svuoti il cestino di Windows, il s.o. manda il comando TRIM al controller e gli dice di pulire quelle pagine relative ai file cancellati che a questo punto non sono più in uso. In questo modo lo svuotamento del cestino può risultare leggermente più lento, ma in teoria il disco è sempre pulito (basta appunto svuotare il cestino) e non corri il rischio che la cancellazione venga fatto in momenti sbagliati.

Implementare GC e TRIM sullo stesso controller si può, e credo che i controller Toshiba facciano proprio questo: di conseguenza, ha un disco che pulisce le pagine non più in uso non solo su richiesta, ma anche automaticamente.
Altri produttori (almeno SF, sui SF2500) hanno invece implementato il TRIM in modo che quando il disco riceve il comando, _non esegue subito_ la cancellazione, programmandola per il momento più opportuno. In questo modo hai effettivamente un ibrido tra TRIM e GC. Il motivo di questa scelta è che TRIM e GC, pur preservando le prestazioni del disco, consumano cicli di scrittura delle memorie flash.

Ovviamente ho approssimato un po' le cose; se vuoi avere un quadro più preciso, ti invito a leggere gli articoli di Anandtech linkati sopra.

Ciao.

[iorfader]

Originariamente inviato da ciocia

aZZ, mi fate venire la tentazione...il 160gb quanto costa?
sirio hai pvt per il link, grazie

dai 550€ in su

prendi il 100gb come il mio e lo trovi a 400euro e se ti serve ti dico lo shop mandami pm

edit: ma porcamiseria che prezzi in germania ed io che l'ho pagato 400 quello da 100gb che nervosooooooo

[lucusta]

Originariamente inviato da sirioo

resta il fatto che i SF con la compressione dei dati e riuscita a tenere a bada il write amplification a prescindere dal trim o dal BGC (presente sul revodrive) rispetto ad altri controller



Remember that write amplification is the ratio of NAND writes to host writes. On all non-SF architectures that number should be greater than 1 (e.g. you go to write 4KB but you end up writing 128KB). Due to SF's real time compression/dedupe engine, it's possible for SF drives to have write amplification below 1.

So how did our drives fare?

The worst write amplification we saw was around 0.6x. Actually, most of the drives we've deployed in house came in at 0.6x. In this particular drive the user (who happened to be me) wrote 1900GB to the drive (roughly 7.7GB per day over 8 months) and the SF-1200 controller in turn threw away 800GB and only wrote 1100GB to the flash. This includes garbage collection and all of the internal management stuff the controller does.


So how did our drives fare?

The worst write amplification we saw was around 0.6x. Actually, most of the drives we've deployed in house came in at 0.6x. In this particular drive the user (who happened to be me) wrote 1900GB to the drive (roughly 7.7GB per day over 8 months) and the SF-1200 controller in turn threw away 800GB and only wrote 1100GB to the flash. This includes garbage collection and all of the internal management stuff the controller does.



Over this period of time I used only 10 cycles of flash (it was a 120GB drive) out of a minimum of 3000 available p/e cycles. In eight months I only used 1/300th of the lifespan of the drive.

The other drives we had deployed internally are even healthier. It turns out I'm a bit of a write hog.

Paired with a decent SSD controller, write lifespan is a non-issue. Note that I only fold Intel, Crucial/Micron/Marvell and SandForce into this category. Write amplification goes up by up to an order of magnitude with the cheaper controllers. Characterizing this is what I've been spending much of the past six months doing. I'm still not ready to present my findings but as long as you stick with one of these aforementioned controllers you'll be safe, at least as far as NAND wear is concerned.

in effetti si nota un certo allineamento prestazionale a seconda di quanti chip SF1200 si usano:
disco da 2.5" da 64K in su'
revo da 128K in su'
revo 2x da 256K in su'

questo e' dovuto al fatto che i chip sono con bus a 64b (un SF1200 2 linee di chip da 64b ossia un bus da 128b), e che la sincronia del dato si fa sentire parecchio.
poi ci sono i chip RAID, che sicuramente hanno stripe size e stripe widht fissa (non gestibile), e addirittura sul revo X2 si ha un RAID di RAID...
il tutto condito su formattazioni a 4K, deleterie su un RAID prestazionale.

su W7 o vista non so' se il loader permette la partizione di avvio su 64K (che e' il massimo per NTFS), ma su XP si faceva l'avvio sul primo primario (da pochi MB) e si montava il sys sul secondo primario, in modo da formattarlo come ti pareva; a 64K lo spazio sprecato e' parecchio, e i vecchi dischi a piatti molte volte erano troppo lenti per sfruttarli in velocita' con quel clustering, ma su una creaturina cosi', spendere 550 euro per 250GB o per soli 200 credo che non faccia molta differenza se pero' si ritrovano prestazioni sui 4K simili a quelle sui 256K!
d'altronde e' una questione di lunghezza della word da far mangiare sia alla serie di chip RAID che ai SF1200, in modo da ottimizzare i cicli su un parametro di 64.
Remember that write amplification is the ratio of NAND writes to host writes. On all non-SF architectures that number should be greater than 1 (e.g. you go to write 4KB but you end up writing 128KB
a mio avviso non e' esattamente cosi', ma:
ricordatevi che su un 1200 usate un bus dati da 128b, in word da 1024b, e se scrivi 4K o 8K o 24K occuperai comunque il bus dati per tutti i 128b, qualsiasi sia l'algoritmo di compressione dati che si ha in precedenza, perche' sul chip flash quella dev'essere la lunghezza per scrivere qualsiasi cosa.

a questo punto sarebbe preferibile, sul REVO 2X una formattazione a 128K, con i primi RAID della serie con stripe size a 128K e il secondo a 256K, in modo da massimizzare il sequenziale (solo che bisognerebbe avere un ambito di lavoro proporzionato a quesa grandezza... al massimo elaborazioni grafiche).

comunque sarebbe interessante vedere una comparativa su NTFS a 4K e NTFS a 64K, per vedere come rispondono.

[AceGranger]

Originariamente inviato da shodan

Ciao, questo non è corretto.
Il comando TRIM può avere, anzi ha, un impatto sulla write amplification, aumentandola.

E' per questo motivo che alcuni controller (in particolare in nuovi SF25xx), anche dopo essere stati "trimmati", _non_ cancellano fisicamente le pagine di flash, ma lo fanno opportunisticamente in modo da abbassare quanto più possibile il write amplification.
Certo in questo modo il concetto di TRIM va un po' a monte ma, evidentemente, SF ha scelto di fare più attenzione all'affidabilità che alle prestazioni pure (comunque elevatissime).

Fonte: http://www.anandtech.com/show/4159/o...t-sf2500-ssd/6

Ciao.

Remember what TRIM does. The TRIM command simply tells the controller what LBAs are no longer needed by the OS. It doesn't physically remove data from the SSD, it just tells the controller that it can remove the aforementioned data at its own convenience and in accordance with its own algorithms.

The best drives clean dirty blocks as late as possible without impacting performance. Aggressive garbage collection only increases write amplification and wear on the NAND, which we've already established SandForce doesn't really do. Pair a conservative garbage collection/block recycling algorithm with you attempting to write an already full drive with tons of incompressible data and you'll back yourself into a corner where the SF-1200 continues to be bottlenecked by the block recycling path. The only way to restore performance at this point is to secure erase the drive.


l'unica parte in cui parla della write amplification e cancellazione dati è riferita solo al GC aggressivo, e presumo che si riferisca a quello degli Indilinx, che è stato anche modificato nel tempo, visto che nei vecchi firmware era molto aggressivo.

[shodan]

Originariamente inviato da AceGranger

Remember what TRIM does. The TRIM command simply tells the controller what LBAs are no longer needed by the OS. It doesn't physically remove data from the SSD, it just tells the controller that it can remove the aforementioned data at its own convenience and in accordance with its own algorithms.

Ciao, questa è la parte interessante.
Viene spiegato che il controller può scegliere di non onorare subito il comando TRIM, ma di aspettare, proprio nel tentativo di ridurre la write amplification.

Più in generale, qualsiasi operazione comporti una cancellazione fisica della flash (TRIM, GC, ecc.) ha come effetto collaterale quello di bruciare cicli _dell'intera pagina/blocco_ comportando quindi un aumento della write amplification.

C'è una scappatoia: se tutta la pagina flash contiene dati da cancellare, tecnicamente non c'è nessun write amplification (su quella pagina). E' per questo motivo che il controller può ritardare l'effetto del TRIM: aspetta che tutta la pagina flash sia da riprogrammare.

l'unica parte in cui parla della write amplification e cancellazione dati è riferita solo al GC aggressivo, e presumo che si riferisca a quello degli Indilinx, che è stato anche modificato nel tempo, visto che nei vecchi firmware era molto aggressivo.

Si, i primi firmware Indilix erano molto aggressivi col GC (almeno a quanto riportato dai siti che gli hanno testati). I Toshiba lo erano ancora di più: praticamente, ogni volta che si eliminava un file, il GC interveniva e cancellava la flash, comportandosi come un TRIM. Proprio per questo Anand faceva notare che i Mac, il cui s.o. Mac OS X non supporta(va?) ancora il TRIM, spesso montavano disci SSD Toshiba.

Ciao.