Hoofdcategorieën
Device Settings

OCZ Vertex getest

Door Femme Taken, donderdag 9 april 2009 13:00, views: 157.513

Conclusie

OCZ levert met de Vertex eindelijk het product waarop vele tweakers sinds het verschijnen van de eerste snelle en peperdure ssd's hebben gewacht: een ssd die niet alleen betaalbaar is, maar ook presteert. Het is spijtig dat een gebrekkige kwaliteitscontrole bij OCZ sommige vroege kopers opzadelde met een product dat nog moest worden afgebakken, maar eenmaal voorzien van stabiele firmware levert de Vertex solide prestaties en toont hij zich dankzij de voortreffelijke schrijfprestaties sterk in elke discipline. Het geringe energieverbruik maakt de Vertex bovendien geschikt voor toepassing in notebooks en netbooks.

De prestaties van de Vertex blijven in de meeste benchmarks weliswaar achter bij die van de Intel X25-M, maar het verschil in snelheid wordt ruimschoots goedgemaakt door de veel lagere prijs die OCZ voor zijn drives vraagt. Voor pakweg 170 euro, een prijs die power users gewend waren te betalen voor 10.000rpm-disks met een beperkte capaciteit, biedt de Vertex voldoende opslagcapaciteit voor een Vista-installatie, applicaties en een paar games.

Binnenkort zal Tweakers.net nader onderzoek doen naar de prestaties van de Vertex in raid-0. Twee exemplaren van 60GB evenaren de prijs van de X25-M en leveren de helft meer opslagcapaciteit. Veel aanstaande ssd-kopers twijfelen tussen een Vertex in raid en een X25-M; dat maakt het interessant te bekijken hoe deze opties zich wat betreft prijs en prestaties tot elkaar verhouden.

T'rug naar huus


Inhoudsopgave

Advertentie

Reacties

«  1  2  3  4  »

Top review weer Femme, en ook bedankt voor het toevoegen van het deel mbt. de performancedegradatie (waar ik immers gisteren in je andere review iets over vroeg). Erg verhelderend !

Beetje jammer dat tweakers.net veel delen van een recent artikel van AnandTech klakkeloos over heeft genomen: zo laten ze, net als in dat artikel, het lijken alsof Anand Lal Shimpi degene was die heeft bepaald dat Vertex moest focussen om lagere latencies. Zo is het natuurlijk helemaal niet gegaan, OCZ heeft een zeer uitgebreide poll onder vele reviewers en experts gehouden.

Beetje jammer dat tweakers.net veel delen van een recent artikel van AnandTech klakkeloos over heeft genomen
Er wordt in één alinea verwezen naar een passage uit het artikel van Anand.
Zo laten ze, net als in dat artikel, het lijken alsof Anand Lal Shimpi degene was die heeft bepaald dat Vertex moest focussen om lagere latencies. Zo is het natuurlijk helemaal niet gegaan, OCZ heeft een zeer uitgebreide poll onder vele reviewers en experts gehouden.
Wie er precies verantwoordelijk is voor het wijzigen van de firmware weten we niet en lijkt me ook niet erg relevant. Het belangrijkste is dat de aanvankelijk slechte prestaties van de Vertex zijn verholpen door de schrijflatencies te verbeteren, waardoor de Vertex een ssd is geworden die in alle omstandigheden goed presteert.

Als het niet relevant is cq je het niet weet moet je ook niet de indruk wekken dat OCZ nav het beklag van Anand met een nieuwe firmware is gekomen.

Anand heeft zijn kant van het verhaal beschreven en er was voor mij geen reden om hieraan te twijfelen. Nu zijn er kennelijk mensen die aanstoot nemen aan Anand's vertelling. Wij als buitenstaanders weten niet hoe de vork precies in de steel zit en kunnen alleen op Anand's relaas afgaan (en wat negatieve reacties van gebruikers op het forum van OCZ die zichzelf het liefst de eer toeschrijven).

Ik vind het nogal een non-discussie.

Niet om je te verdedigen (niet dat ik dat niet wil, je kunt het prima zelf ) maar je hebt in mijn ogen volledig gelijk !

Dit was de review die ik nog nodig had !
Bedankt ik ben er uit , ik ga morgen een vertex bestellen !

klein vraagje nog:

Is het ook bij deze drive van belang dat je hem gaat "alignen" en de blockgrootte aan moet passen voor win xp / ntfs zoals ik over de apex en core drives heb gelezen in het ocz forum ?

Wat betreft die performance degradatie, vraag ik me af of Anandtech's methode niet simpeler en effectiever is? Voor zover ik het heb begrepen, schrijft die gewoon in 1 keer de hele SSD vol. En dan weet je zeker dat alle sectoren data bevatten. Dan een enkele delete, en je kunt je benchmark runnen...

Sneller uit te voeren, en je hebt onmiddellijk de steady state waar je als gebruiker uiteindelijk toch in terecht zult komen. (Totdat dat TRIM tooltje gereleased wordt...)

Deze methode is ook niet eerlijk omdat grote drives slechter zullen presteren dan ze in werkelijkheid doen. Een grote drive zal minder prestatieafname hebben dan een kleintje. Een steady state bestaat bij de X25-M en de Vertex niet omdat ze voortdurend aan het schuiven zijn met geheugenpages. Ik test dan liever met real world toegangspatronen.

Zou je dat toe kunnen lichten. Ik zie nml. niet 1,2,3 in waarom een grote drive dan slechter zou gaan presteren. Klein of groot, voreg of laat zit die toch echt "vol" en zal er ge-remapped moeten gaan worden. Zover ik begrijp duurt dat bij kleine en grote disks net zo lang, dus ik begrijp je uitleg dan ook niet.

Een kleine drive is eerder volgeschreven en beschikt statistisch gezien over minder mogelijkheden om te schuiven met geheugenpages. Op een grote drive is het waarschijnlijker dat er lege geheugenpages beschikbaar zijn. Ik heb inmiddels de Vertex 120GB getest en die was in de tweede en derde run duidelijk sneller dan de Vertex 30GB.

Boot & Launch StorageMark 2008 Index
Harde schijfScore (StorageMarks)
OCZ Vertex 30GB (run 1)
 
884,3
OCZ Vertex 120GB (run 1)
 
738,9
OCZ Vertex 120GB (run 3)
 
681,2
OCZ Vertex 120GB (run 2)
 
669,2
OCZ Vertex 30GB (run 3)
 
516,3
OCZ Vertex 30GB (run 2)
 
468,7

[Reactie gewijzigd door Femme op vrijdag 10 april 2009 01:11]


Dat het langer duurt eer de 120GB echt vol zit, begrijp ik. Maar hoe zijn de prestaties bij run, 6, 7 en 8 ? Blijven de prestaties dan nog steeds zo goed ?

Tot nu haalt de Vertex in de derde run telkens iets betere prestaties dan in de tweede run of is het verschil minimaal. Ik ga er dus vanuit dat de prestaties niet (significant) verder afnemen. Ik heb niet meer dan drie runs in dezelfde configuratie gedaan maar wel verschillende configuraties getest (enkele Vertex 30GB en 120GB, Vertex 30GB in raid 0 op de Intel ICH10R, Areca ARC-1220 en ARC-1280) en telkens ontwikkelen de prestaties zich op dezelfde iwjze.

Dat is ook logisch omdat de drive na de eerste run al helemaal is volgeschreven en het voordeel van het direct kunnen schrijven naar lege geheugenpages er niet meer is. Daarna variëren de prestaties tussen de runs wel meer dan bij harde schijven (die extreem consistent presteren in de RankDisk runs - afwijkingen kleiner dan een procent zijn niet ongebruikelijk) maar is er geen trend naar beneden meer waarneembaar.

Zijn deze resultaten representatief voor "real world" gebruik of is het meer een vingerwijzing van wat je verwachten kan van de prestaties ?

Heb je nog een verklaring dat de Vertex 30GB bij de eerste run beduidend beter scoort dan de 120GB uitvoering ? Dat lijkt me nml. nogal vreemd. Zowiezo zijn de 30GB scores grilliger dan bij de 120GB versie, bij de derde run presteert deze SSD weer een stuk beter dan de 2de run; terwijl de 120GB versie slechte een klein beetje winst laat zien (al is die nog steeds een stuk hoger dan de 30GB scores).

Kan je met de tot nu toe gedane benchmarks laten zien dat de trend die ik toe nu toe zie niet, of in mindere mate geld voor grotere disks.

De trend is dus dat disks optimaal presteren als ze leeg zijn, fors achteruit gaan wanneer ze meerdere keren volledig beschreven zijn (en dit is dus afhankelijk van de grootte) en uiteindelijk weer iets beter presteren en daarna stabiliseren. Jij gebruikt dezelfde traces voor alle schijven, waardoor dit lastig te meten is bij verschillende schijf groottes.

Mijn theorie is dat dit effect gelijk is voor alle schijven, maar minder opvalt bij grote schijven omdat deze in verhouding minder intensief gebruikt worden dan kleine schijven. Dat betekent dus ook dat een poweruser met een 250 GB schijf dezelfde performance degradatie ondervind als een 'normale' gebruiker bij een 30 GB schijf.

In het kort: performance degradatie is afhankelijk van mate van gebruik versus diskgrootte en een grotere disk doet naar mijn idee het effect an sich dus niet ongedaan.

In het kort: performance degradatie is afhankelijk van mate van gebruik versus diskgrootte en een grotere disk doet naar mijn idee het effect an sich dus niet ongedaan.
Dat klopt inderdaad. Ik acht het wel waarschijnlijk dat een grote ssd minder intensief (gekeken naar hoeveelheid schrijfacties ten opzichte van capaciteit) wordt gebruikt dan een kleine ssd. Het gaat immers om grote verschillen in opslagcapaciteit.
Jij gebruikt dezelfde traces voor alle schijven, waardoor dit lastig te meten is bij verschillende schijf groottes.
Grote drives zijn inderdaad in het voordeel omdat maar een klein gedeelte van de adresrange wordt gebruikt. Grote harde schijven worden effectief geshortstroked en grote ssd's worden getest alsof ze zijn ondergepartioneerd waardoor er meer vrije geheugenpages of ongeldige geheugenblokken (waarvan de pages na een erase snel beschreven kunnen worden) beschikbaar zullen zijn.

Ik denk dat ik daarom in de toekomst Intel NAS Performance Toolkit moet gaan gebruiken die het bestandssysteem test ipv de fysieke test. Dit heeft ook weer veel nadelen, maar lijkt me voor ssd's de beste methode (ook ivm de trim-ondersteuning in de toekomst).

[Reactie gewijzigd door Femme op vrijdag 10 april 2009 11:29]


Thanx voor deze extra benchmark!

Wat me wel opvalt is dat de 120GB Vertex betere theoretische lees- en schrijfsnelheden meekrijgt, maar dat in de praktijk de 30GB versie (run1) sneller is...

Heb je hier een verklaring voor? Voorheen dacht ik namelijk dat een 120GB versie de betere keus was (afgezien van het hele performance degradatie issue)

Stop er nu ook eens een raid 0 bij met 2 of meer disks (spinpoint a 69 euro vs vertex a 270 euro, dan kun je dus 4 spinpoint's in raid 0 hangen, dan heb je een redelijke vergelijking...).

Volgende keer dus aub ff die 2 spinpoint's in raid 0 gooien en kijken wat er dan gebeurd.

Deze review maakt het heel moeilijk kiezen tussen 2 van deze in raid 0 of 4 maal een goedkoop7200 toeren schijfje met raid-controller. Ik denk dat ik nog een aantal maandjes wacht :)

4 maal een HDD haalt bij lange na niet de performance van tweemaal deze SSD (twee HDD's in raid 0 geven niet dubbele prestaties, vier HDD's in RAID 0 zullen je effectief de dubbele prestatie van de langzaamste HDD geven. voor SSD's werkt een RAID 0 vele malen beter), dus als je moet kiezen, neem tweemaal OCZ vertex.

Weet ik zo net nog niet. Ik heb toevallig 2 Samsung T166 320GB schijven in Raid-0 en daarmee heb ik laatst 120MB/s gekopieerd, waarbij bron- en doel-partitie allebei op de raid configuratie stonden. Ik zou dus verwachten dat de max doorvoersnelheid ongeveer 240MB/s bedraagt (Ik zal eens een officiele tool er overheen halen en straks updaten). En dit is dan ook nog eens met een onboard raid controller. Als ik dat vergelijk hier met een enkele SSD lijkt dat zo slecht nog niet.

Ik weet dat die analyse erg kort door de bocht is, maar ik ben zou eerst een benchmark willen zien voordat ik overtuigd ben over wat je nu zegt.

Verder denk ik dat je zeker met een fatsoenlijke raid-controller, meer dan dubbele performance haalt bij raid-0 met 4 schijven. Ik ga eens kijken of ik benchmarks kan vinden.

De sequentiële transferrate zal uiteraard makkelijk opschalen in raid als je een controller gebruikt die voldoende bandbreedte haalt. Op het moment dat je voor kleinere requests naar de harde schijf gaat en er tegelijkertijd maar één zo'n request plaatsvindt zullen de harde schijven in raid 0 nauwelijks een lagere responstijd hebben. Er is pas groot verschil op het moment dat er gelijktijdige I/O plaatsvindt. In desktopomgevingen vindt er niet zo heel veel gelijktijdige I/O plaats. In normale situaties zit je op een gemiddelde van zo'n anderhalve gelijktijdige I/O.

In de praktijk kom je daarom meestal uit op een prestatieverbetering van 35 tot 45 procent als je van één naar twee schijven gaat.

Jammer dat er niet zo'n 10.000rpm desktop schijfje (Raptor) is meegenomen in de vergelijkingstest.

Had helemaal niets uitgemaakt.

Of je nou een HD met 8 of 12ms toegangstijd hebt, het blijft ordes slechter dan een SSD met 0,1 ms toegangstijd.

In de meeste systeem/applicatie benchmarks is de Raptor zelfs nauwelijks sneller dan de Spinpoint, omdat de laatste een hogere transferrate geeft.

Zie reactie van AHBdV. Ik ga wel proberen of ik een Velociraptor kan krijgen maar voor het algemene beeld zal het weinig uitmaken. Geavanceerde ssd's zoals de Vertex en de X25-M zijn een aantal factoren sneller dan harde schijven op workloads die sterk afhankelijk zijn van de toegangstijd. Het verschil tussen een Velociraptor en een grote 7200 toeren harde schijf die effectief wordt 'geshortstroked' is procentenwerk.

Inderdaad gewoon een top review en ook nog eens eindelijk een schot in de roos voor OCZ. Goed om te zien dat na al die effort er dan toch eindelijk licht aan het eind van de tunnel lijkt te zijn.

ps. de bovenste grafiek van pagina 6 lijkt de verhoudingen niet correct weer te geven.

Ondersteund deze drive dat "trim" commando nu wel of niet, gaat dat nog komen in toekomstige firmwares, of moet ik daarvoor nog wachten op een opvolger?

(Ik wil nl een ssd'tje kopen voor mn linux server (en evt een voorm mn windows 7 bak) maar wil dat dan eigenlijk wel werkend hebben.)

Er wordt in de review ook aangegeven dat je evt ook de drive deels kunt partitioneren om er voor te zorgen dat de drive weet dattie vrije ruimte heeft, dan vindt ik het een beetje jammer dat dat niet mee getest wordt?

Verder een mooie review van een mooi product!

OCZ heeft twee dagen geleden nieuwe firmware uitgegeven met ondersteuning voor het trim-commando. In theorie zou dit moeten werken onder Linux met een recente kernel. Ik wil nog kijken of ik het effect van onderpartitioneren kan testen.

Zou interessant zijn een 120GB vertex, onderpartitioneerd op 80GB, met een Intel X-25 te vergelijken...

Als je perse een RAID van 2x 60GB wil doen, dan lijkt het me ook wel interessant om dat met een enkele 120GB te vergelijken. Ook weer vanwege dezelfde reden.

Firmware voor TRIM is gereleased (versie 1.10).

Op (zeer) korte termijn volgt er ook een tooltje dat TRIM mogelijk maakt onder Vista en XP, windows gebruikers hoeven dus niet te wachten op Windows 7.

Dat gegeven ontbreekt volgens mij nog aan deze review.

heb je er misschien een linkje van waar staat dat de vertex trim zal ondersteunen onder windows 7 en vista? Dat zal me waarschijnlijk echt over de streep halen :)

voor de rest vind ik het een prima review! Ik hoop dat er binnenkort iets over de summit geschreven zal worden aangezien het weer een andere controller betreft. Ik heb al op verschillende plaatsen gelezen dat de prestaties niet echt beter waren dan die van de vertex, maar dat de prijz stukken hoger zou uitvallen... Als tweakers.net (Femme?) hier een preview/review over zou kunnen doen, zullen ook mijn laatste twijfels weggenomen worden.

Even zoeken in het forum van OCZ. Daar bericht iemand van OCZ zelf dat hij het tooltje heeft lopen op zijn Windows computer, en dat ze de laatste bugs aan het oplossen zijn.

Zeer mooie en duidelijk review ;)

Ik ben ook benieuwd naar het prestatieverschil van een vertex in raid en een x25-M van intel.

En ik volg de reactie van Derice

Ik ben idd ook erg benieuwd naar een test waarbij gekeken wordt naar een zo hoog mogelijke prestatie (al dan niet in RAID), met zoveel mogelijk beschikbare Gb's, voor een zo laag mogelijke prijs (we blijven tenslotte NL'ers, hè ;))

Binnenkort zal Tweakers.net nader onderzoek doen naar de prestaties van de Vertex in raid-0. Twee exemplaren van 60GB evenaren de prijs van de X25-M en leveren de helft meer opslagcapaciteit.

Ik hoop dat er ook word vergeleken met de Raptor/velociraptor in raid 0, dit is/was voor lange tijd een "goedkope" snelle combinatie die volgens mij door veel powerusers werd gebruikt.
Raptors kwamen geloof ik 4 jaar geleden uit en ik vermoed dat een hoop mensen nu wel in de mood zijn voor een upgrade. Ik in ieder geval wel!

De vorige generatie Raptor waar jij op doelt is trager dan de Samsung SpinPoint F1. Western Digital heeft de Velociraptor mijn inziens nogal uit de markt geprijsd. De prijs is al bijna een jaar stabiel terwijl 3,5 inch 7200 toeren schijven in rap tempo goedkoper zijn geworden en beter zijn gaan presteren. Nu ssd's ook nog veel betere boot/applicatieprestaties hebben wordt het wel erg moeilijk om nog een Velociraptor aan te bevelen.

Ik wacht even op de ATA8-ACS resultaten. Zijn de desktopbenchmarks gedaan met volgeschreven SSD's of met lege? Kon het niet zo snel uit de review halen.

Bij de Vertex en X25-M is het gemiddelde genomen van drie runs. Bij elke run werd er 146GB aan data geschven. De Vertex zat dus rap vol.

Ik heb in mijn nieuwe PC afgelopen weekend 4x 30Gb Vertex SSD's gegooid (dacht, doe eens gek ;)) en ik moet zeggen dat ik erg tevreden ben over de performance.

Wat ik me alleen erg af vroeg is wat de beste stripping size zou zijn voor Raid-0. Ik had nu 64kb genomen, maar vroeg me af of een grotere / kleinere size beter zou zijn.

Gezien het feit dat de blocksize van een ssd typisch 512kb is, heb je een goede kans dat een stripping size van 512kb ook het beste resultaat oplevert. Tenslotte is het schrijven per block het meest efficiënt bij ssd's.
Ik heb overigens geen praktijkresultaten om dat te bevestigen.

Hoewel de erase size van de flashchips in de Vertex 512KB is, kan een (gedeeltelijk) leeg block gewoon per page van 4KB beschreven worden, mits de betreffende page nog leeg is. Het is dus niet echt nuttig om je stripesize even groot als je flash block size in te stellen.
Ik zou een stripesize van 64 tot 128KB aanraden, zo profiteer je beter van de write combiningdie de Vertex biedt.
Als je je elignment dan op een veelvoud van de stripesize instelt ben je zo goed als klaar.
Als je Vista je drive laat partitioneren, houdt die standaard een 1024KB alignment aan. Dat matcht met nagenoeg elke RAID array stripe size.

Zo groot mogelijk instellen, Zoals DirkW zegt zijn SSD blocks 512KB en kan je het beste in blocks schrijven. Echter zal er bij een RAID-blocksize van 512KB 128KB per SSD worden weggeschreven omdat je RAID-0 draait met 4 disks. Een Blocksize van 2MB zou dus ideaal zijn omdat je dan altijd in in volledige blocks aan het wegschrijven bent. Helaas kan dit niet en zou het ook een hoop schijfruimte kosten.

[Reactie gewijzigd door Unagi op donderdag 9 april 2009 16:59]


Huh? Ik denk dat je wat in de war bent... De blocksize is de hoeveelheid data die op 1 disk van de RAID komt. En niet uitgesmeerd over meerdere schijven...

Maar de striping size die genoemd wordt door de original poster ?
Wordt die wel uitgesmeerd over meerdere disks en zoudie dan ten minste de blocksize van de disk maal het aantal diks moeten zijn (of een veelvoud daarvan) voor optimale performance ?

Je hebt helemaal gelijk, I stand corrected :)

Ik denk dat je met het oog op het "performance degradatie issue" het beste de striping size zo groot mogelijk kan instellen.

De reden daarvoor is dat je de kans dan groter maakt dat voor het schrijven van een file maar 1 disk gebruikt wordt ipv 4.
Daarmee zorg je dat de idle time van de andere SSDs groter wordt, waardoor ze meer performance optimalisatie kunnen doen.
(in de idle time gaan ze kijken welke delen van SSD niet meer gebruikt worden en alvast gewist kunnen worden)

Met een hele kleine stripe size kan ik me voorstellen dat de idle time te kort wordt, waardoor die optimalisatie niet uitegevoerd wordt.

Sowieso is een grote stripe size altijd aan te raden voor het verbeteren van de performance met kleine bestanden.
Een kleine stripesize gebruik je vooral om snel een grote sequentiele transferrate te halen, maar dat is toch al heel groot bij een SSD. Dus daar hoef je je niet druk om te maken.
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011