Test Test: OCZ RevoDrive

[Holt]

Die haben dort was von Gen2 geschrieben und Du setzt das jetzt gleich wieder mit der Rev. 2.0 des PCIe Standarts gleich, was sicher auch Absicht der Schreiber war, aber steht das auch da? Gen2 kann auch für die zweite Generation der Intel Implementierung eines PCIe Contollers stehen und dort könnte z.B. drinne stehen, daß diese sowohl Lanes nach der Rev2.0 als auch welche mit Features der Rev 2.0 aber nur der Geschwindigkeit der Rev 1.0 abdeckt. Ist bei SATA Controllern auch gerade der Fall, vor allem bei denen von JMircon: Diese werden mit SATA II beworben, weil die Features wie NCQ die erst im SATA II definiert wurden habe, aber von der Geschwindigkeit schaffen sie eben nur den Durchsatz von SATA I, so ca. 140MB/s.
Die Praxis zeigt in diesem Test von anandtech.com, dass die Geschwindigkeit an den PCIex4 Ports des X58 Ports eindeutig weit hinter der Bandbreite einer PCIe Rev. 2.0 Lane zurückbleibt und eben auch weit hinter Geschwindigkeit die man erzielt, wenn man die SATA3 Contollerkarte (PCIe x1, Rev 2.0) in einem der x16 Slots des Mainboards steckt: 192,9MB/s im PCIe x4 zu 342,9MB/s im PCIe x16 Slot des X58 Boards.

So, damit ist das hoffentlich erledigt, es belibt aber die Frage an die Tester:

In welchem Slot habt Ihr das Revo getestet?
Laut Bericht war das Testsystem:

Motherboard

* Gigabyte EP45-UD3P, S775, P45+ICH10R

...
Grafikkarte

* MSI 8800GTS 640MB (G80)

Gemäß den Daten im Preisvergleich:

Intel P45/ICH10 • Speicherslots: 4x DDR2 • Erweiterungsslots: 1x PCIe 2.0 x16, 3x PCIe x1, 3x PCI • Anschlüsse extern: 8x USB 2.0, 2x FireWire (TSB43AB23), 1x Gb LAN (RTL8111C), 7.1 Audio (ALC889A), 1x PS/2 Maus, 1x PS/2 Tastatur • Anschlüsse intern: 4x USB 2.0, 1x FireWire (TSB43AB23), 6x SATA II (ICH10), 2x SATA II RAID 0/1, 1x PATA, 1x Floppy, 1x CPU-Lüfter PWM, 3x Lüfter, 1x parallel, 1x seriell • Besonderheiten: All solid capacitors • unterstützt Intel Core 2 Duo/Extreme/Quad 45nm • unterstützt FSB 333MHz (1333MHz)

hat es nur einen geeigneten PCIe Slot, den PCIe 2.0x16 aber keine IGP, zumal laut Angaben zum Testbericht ja auch eine MSI 8800GTS (PCIe x16) verwendet wurde.

Wie um alles in der Welt konntet Ihr in diesem Testsystem eine PCIe x4 Karte testen?

 

[Moros]

Wie du selbst zitiert hast, kam das UD3P zum Einsatz. Das hat zwei PCIe x16 Steckplätze

1 x PCI Express x16 slot, running at x16
1 x PCI Express x16 slot, running at x8
(The PCIEx16 and PCIEx8 slots support ATI CrossFireX technology and conform to PCI Express 2.0 standard.)
3 x PCI Express x1 slot
2 x PCI slots

 

[Holt]

Ok, alles klar.

 

[WeltalsWille]

Die haben dort was von Gen2 geschrieben und Du setzt das jetzt gleich wieder mit der Rev. 2.0 des PCIe Standarts gleich, was sicher auch Absicht der Schreiber war, aber steht das auch da? Gen2 kann auch für die zweite Generation der Intel Implementierung eines PCIe Contollers stehen und dort könnte z.B. drinne stehen, daß diese sowohl Lanes nach der Rev2.0 als auch welche mit Features der Rev 2.0 aber nur der Geschwindigkeit der Rev 1.0 abdeckt.

Dass ich PCIe Gen2 mit der Rev. 2.0 des PCIe Standarts (oder besser gesagt der PCIe® Base Specification 2.0) gleichsetze, habe ich an keiner Stelle geschrieben. Eine von dir vermutete Beschneidung der 4 "verbleibenden" Lanes des IOH will ich nicht gänzlich ausschließen. Dem widerspricht allerdings, daß sich die Spezifikation aller 36 Lanes des IOH nicht unterscheidet. Ohne schlüssige Widerlegung gehe ich daher erst mal davon aus, dass auch alle die Qualität besitzen, die in den PEG-Slots implementiert ist. Der von dir zitierte Anandtech-Artikel enthält zudem ein weiteres Indiz, dass genau diese Annahme stützt. Zum getesteten Gigabyte-Board wird dort geschrieben "Gigabyte sent its X58-UD3R motherboard, which has a Marvell 6Gbps controller branching off one the X58’s PCIe 2.0 lanes." Eine solche Auslegung wäre nicht möglich, sofern entsprechend deiner These PCIe-2.0-Lanes ausschließlich für zwei PEG-Slots verfügbar sind.

Die Praxis zeigt in diesem Test von anandtech.com, dass die Geschwindigkeit an den PCIex4 Ports des X58 Ports eindeutig weit hinter der Bandbreite einer PCIe Rev. 2.0 Lane zurückbleibt und eben auch weit hinter Geschwindigkeit die man erzielt, wenn man die SATA3 Contollerkarte (PCIe x1, Rev 2.0) in einem der x16 Slots des Mainboards steckt: 192,9MB/s im PCIe x4 zu 342,9MB/s im PCIe x16 Slot des X58 Boards.

Die Performance am x4-Port des x58-Boards ist in der Tat auffällig gering. Eine ausschließliche PCIe-1.0-Auslegung der 4 "verbleibenden" PCIe-Lanes des IOH läßt sich damit aber nicht zweifelsfrei begründen. Es kann nicht ausgeschlossen werden, dass der x4-port auf PCIe-1.0-Lanes des ICH geschaltet ist und verbleibende Lanes vom IOH, wie beim oben genannten X58-UD3R, anderweitig verwendet werden.

Anbei noch 'n Intel-Dokument in dem die 4 Nicht-PEG-Lanes des IOH explizit als Verbindungen mit PCIe-2.0-Datenrate beschrieben werden http://download.intel.com/design/intarch/papers/321087.pdf , page 19, fig. 10

 

[bensen]

KEINE INTEL Plattforem bietet HEUTE PCIe Lanes außer denen für die Graka. Ein Sockel 1156 chipsatz bietet nicht mehr als 16 davon und der Rest muss sich die Bandbreite mit der "Southbridge" teilen. Ein ICH10 schafft an seinen 6 SATA2 Ports zusammen auch nicht mehr als ca. 660MB/s.

Du wirfst einiges durcheinander. 1. Verstehe ich (die Hersteller eigentlich auch) unter einer Plattform CPU+Chipsatz. Und da bietet der s1156 24 Lanes und der s1356 42 Lanes. Wofür man die nutzt ist total egal, es gibt keine extra Lanes für Grafikkarten. Auch bieten beide genug um einen x16 Slot für Grafikkarten und noch einen weiteren x4 Slot bereitzustellen.
Und es muss sich auch keine Lane mit der Southbridge die Bandbreite teilen, sondern die werden durch die Southbridge bereit gestellt.
Wenn die ein ICH10 über 600MB/s schafft ist das doch fein. Limitiert keine 2 SSDs. Das war meine Aussage. Das Revo-Drive bietet keinen Vorteil.

Dass die Lanes der Southbridge nur je 250 MB/s schaffen und die Southbridge selber nur mit 1GB/s an die Northbridge bzw. CPU angebunden ist, ist ein Nachteil bisheriger Intel-Plattformen, hat aber mit diesem Produkt hier nichts zu tun, denn das wird nicht ausgebremst.

Ganz einfach, weil die IOO der Plattform extrem limitiert ist und wer mehr will, der muss bei Intel zum Sockel 1356 greifen. Das ist so und auch so gewollt.

Was ist IOO?

Gen2 kann auch für die zweite Generation der Intel Implementierung eines PCIe Contollers stehen und dort könnte z.B. drinne stehen, daß diese sowohl Lanes nach der Rev2.0 als auch welche mit Features der Rev 2.0 aber nur der Geschwindigkeit der Rev 1.0 abdeckt.

In den Specs steht auch mal Gen2-Speed.

Die Praxis zeigt in diesem Test von anandtech.com, dass die Geschwindigkeit an den PCIex4 Ports des X58 Ports eindeutig weit hinter der Bandbreite einer PCIe Rev. 2.0 Lane zurückbleibt und eben auch weit hinter Geschwindigkeit die man erzielt, wenn man die SATA3 Contollerkarte (PCIe x1, Rev 2.0) in einem der x16 Slots des Mainboards steckt: 192,9MB/s im PCIe x4 zu 342,9MB/s im PCIe x16 Slot des X58 Boards.

Das Gigabyte Board hat den Marvell Controller an einer der 36 PCIe 2.0-Lanes des X58 angebunden. Deswegen auch die hohe Transferrate von 343,2 MB/s. Fazit des Tests: Also doch PCIe 2.0 Geschwindigkeit. Was gibt es daran zu diskutieren?
Gibt auch den Test auf HT4U, wo einmal ne x1 USB 3.0 Controllerkarte am X58 und am ICH10 getestet wird. Am ICH10 wirds ausgebremst, am X58 nicht.

Vielleicht hat Anandtech bei dem Test den x4 Port des Gigabyte-Boards genommen oder weiss der Henker, aber wie bei deiner Argumentation "alles klar" sein soll ist mir schleierhaft.

 

[WeltalsWille]

Vielleicht hat Anandtech bei dem Test den x4 Port des Gigabyte-Boards genommen oder weiss der Henker, aber wie bei deiner Argumentation "alles klar" sein soll ist mir schleierhaft.

Gemäß Testbericht hat er den x4-Port des X58-Intelboards genommen. Der müßte aber gemäß dem Produktbrief des Boards am PCIe-2.0-konformen IOH angeschlossen sein. Eventuell lag auch 'ne Inkompatibilität mit der Controller-Karte vor, aufgrund der der IOH die betreffende Lane auf reduzierte Geschwindigkeit gestellt hat.

 

[olli1783]

Das RevoDrive soll ja aus 2 Vertex 2 bestehen die zusammengefasst ein raid 0 bzw raid 1 ergeben (?) heisst das wenn man daraus 2 normale also weder raid 0 noch raid 1 macht das sie dann wieder trim unterstützen? und sich durch einmaliges vollschreiben und wiedert löschen in den urzustand der geschwindigkeit zurückversetzen? oder geht dank des silicon image controllers kein trim? z.b. bei crystaldiskinfo steht trim da!

danke für die beantwortung, olli

 

[Moros]

TRIM wird es auf dem RevoDrive wohl nie geben. Dafür müsste der Treiber von Silicon Image TRIM unterstützen und die Kommandos müssten über den Bridge-Chip einwandfrei konvertiert bzw. weitergeleitet werden.
Wenn AMD nicht mal über ein Jahr nach Einführung von TRIM unterstützt, dann kann ich mir nicht vorstellen, dass Silicon Image das für solch eine spezielle Hardware hinkriegt.

SandForce-SSDs kann man nicht mit Hilfe von TRIM in den Ursprungszustand zurück versetzen. Vollschreiben und wieder löschen bringt also überhaupt nichts. Es soll aber möglich sein unter Linux oder mit der OCZ Toolbox einen Secure Erase der einzelnen Vertex 2 auf dem RevoDrive durchzuführen. Getestet habe ich das nicht.

 

[Eggcake]

Anand hat das RevoDrive X2 kurz angeschaut:
http://www.anandtech.com/show/3997/ocz-revodrive-x2-review/1

Ausser synthetischen Tests gibt's da aber nix. Dort frühstückt es selbstverständlich die (Single-)Konkurrenz, aber wie's bei echten Applikationen aussieht haben wir ja gesehen.

 

[DoubleJ2k]

Es soll aber möglich sein unter Linux oder mit der OCZ Toolbox einen Secure Erase der einzelnen Vertex 2 auf dem RevoDrive durchzuführen. Getestet habe ich das nicht.

Geht z.b. mit einer Live-Version von Ubuntu
hdparm --security-erase /dev/sdX
(vorher RAID auflösen)

 

[Carparkescape]

Schade dass die Karte nicht Mac OS X kompatibel ist. Ein MacPro könnte von der enormen Leistung dieser Karte provitieren.

 

[olli1783]

das mit ubuntu versuch ich mal. danke ich berichte

edit so habe die live version von version 10.10 gestartet und bin im terminal meine revo drive aufgelöst vorher so das 2x55gb vertex 2 sdb sdc sind , nun will der bei dem kommando hdparm --security-erase /dev/sdb nen passwd (password) da fängt es schon an. welches denn bitte?! hilfeee!!

 

[checkman]

Einen Secure Erase kann man sehr komfortabel im BIOS des Revodrive durchführen.
Bedeutet natürlich Auflösung des RAID, Quick Erase oder Secure Erase, RAID neu erstellen.Fertig.

 

[Moros]

Das stimmt nicht. Der dortige Secure Erase entspricht der vollständigen Formatierung und nicht einem SecureErase im eigentlich Sinn.

 

[checkman]

Dann würde OCZ falsche Bezeichnungen verwenden.

Was ist denn ein SecureErase im eigentlichen Sinn?

 

[olli1783]

Richtig , das interne "Low Level Format" vom Silicon Image Raid Controller des RevoDrive bringt keinen "echten" Security Erase! sprich keine leistungs-verbesserung.

 

[Eggcake]

Dann würde OCZ falsche Bezeichnungen verwenden.

Was ist denn ein SecureErase im eigentlichen Sinn?

Was OCZ genau macht weiss ich auch nicht, aber SecureErase bedeutet bei SSDs, dass der Inhalt Zellen gelöscht wird (nicht überschrieben o.ä., sondern gelöscht).

 

[olli1783]

Hab meine Revo wieder auf volle Leistung gebracht wie bei auslieferung! Super und schnell und einfach!

einfach klasse! Danke an DoubleJ2k zwecks den HDPARM Trick!

 

[checkman]

Hi olli1783

was war jetzt mit dem Passwort und womit prüfst Du die Leistung (vorher nachher)?

 

[olli1783]

wenn man nach dieser anleitung http://www.ocztechnologyforum.com/f...ure-Erase-From-Within-Linux-For-Windows-Users geht und alles befolgt klappt alles auf anhieb mit der unbutu 10.04 live version . ich habe es mit allen programmen getestet as ssd benchmark, hd tune crystaldiskmark windows leistungs index. ist wieder bei 7,9 davor war er bei 7,7-7,8

gruss