Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 44 reacties, 13.183 views •

OCZ heeft een opgefriste versie van de Vertex 3-ssd's aangekondigd. De Vertex 3.20, zoals de nieuwe serie gaat heten, maakt gebruik van nand-flash dat gebakken is op 20nm. De snelheid van de ssd's lijkt er niet noemenswaardig op vooruit te zijn gegaan.

De nieuwe chips zitten vooralsnog alleen in de 120GB- en 240GB-versie van de Vertex 3.20. De 480GB-variant van de Vertex 3.20 volgt binnenkort. Ten opzichte van de vorige generatie Vertex 3-ssd's levert de Sandforce SF-2200-controller nog steeds een maximale leessnelheid van 550MB/s. De maximale sequentiële schrijfsnelheid zou iets gestegen zijn; van 500MB/s naar 520MB/s. Uit onderstaande cijfers, die afkomstig zijn van OCZ zelf, lijkt vooral de 4KB random-writesnelheid van de Vertex 3.20 120GB er op achteruit te zijn gegaan.

 Vertex 3.20 120GBVertex 3.20 240GBVertex 3 120GBVertex 3 240GB
Max. leessnelheid 550MB/s 550MB/s 550MB/s 550MB/s
Max. schrijfsnelheid 520MB/s 520MB/s 500MB/s 500MB/s
4KB random read 20.000 IOPS 35.000 IOPS 20.000 IOPS 40.000 IOPS
4KB random write 40.000 IOPS 65.000 IOPS 60.000 IOPS 60.000 IOPS

Het is onduidelijk of de veranderde snelheden toegeschreven kunnen worden aan het nieuwe geheugen of dat OCZ de snelheden op een andere manier gemeten heeft. Het is eveneens onduidelijk of het duurdere broertje van de Vertex 3, de Vertex 4, ook nieuwe flash-chips zal krijgen. Momenteel huizen er nog 25nm-chips in de Vertex 4.

Het gebruik van een nieuw soort chips heeft over het algemeen weinig gevolgen, hoewel OCZ er in het verleden slechte ervaringen mee heeft gehad. Bij de overstap van 34nm- naar 25nm-geheugen bleek de vernieuwde Vertex 2-serie slechter te presteren. Bovendien bleek de nieuwe ssd minder capaciteit te hebben, omdat OCZ een groter deel van het geheugen ontoegankelijk had gemaakt.

OCZ Vertex 3.20

Reacties (44)

Reactiefilter:-144044+126+21+30
Moderatie-faq Wijzig weergave
omdat er een keer een foutje wordt gemaakt hoeft zo'n fabrikant niet meteen te worden afgeschreven.
Maar als deze laat zien dat zij niet dénken aan verbetering is dat de enige manier, wat tevens een signaal is richting de anderen. Dit is een typisch geval van een voorheen goed bedrijf die te maken kreeg met te omvangrijke problemen rond een product en verkeerde beslissingen gingen nemen te bescherming van de korte termijn inkomsten. In hun geval lijkt de ophef deels gewerkt te hebben, zij hebben uiteindelijk Indilinx moeten overnemen o.a. vanwege de problemen met Sandforce: dit geeft ze namelijk een sterkere onderhandelingspositie, wat contracten met betere SLA's mogelijk maakt - wat jij en ik merken in snellere oplossing van "minder belangrijke (consumenten)bugs".

Overigens zijn de bedenkingen wat betreft OCZ zeer terecht. In 2010 was hun SSD uitvalpercentage rond de 3% tegenover 0,6% van Intel. Dat kan gebeuren met nieuwe technologie, maar OCZ maakte achter elkaar dezelfde fouten:
- zij ontkenden zowel het probleem als diens omvang rond de SF contracten (b.v. NDA waardoor slechte communicatie richting klant) en firmware. Andere fabrikanten die vanwege hun achtergestelde contracten bepaalde features niet hadden gingen zover om beta firmware buiten contract te gebruiken (die weer andere problemen had).
- ze bezigden pappen en nat houden: de problemen met de eerste generatie SF controllers werden anderhalf jaar lang niet opgelost terwijl de gevorderde kopers als betatesters werden gebruikt (ontwerp was gestoeld op enterprise, consumenten versies zonder caps waren eigenlijk ongeschikt voor gebruik in veel systemen i.c.m. hybernate/afsluiten).
- ze ontzegden support omdat een generatie "eigenlijk experimenteel/niet bedoeld voor laptops is", zoals in het geval van de Vertex LE
- ze hetzelfde deden met de praktisch identieke Vertex 2 serie totdat de nieuwe generatie controllers kwam, toen zij iedereen achtten te upgraden, ondanks dat vele van dezelfde problemen ook in de tweede gen (SF-2xxx/Vertex 3) terug bleken te komen
- het support forum werd gecensureerd op basis van "politieke" overwegingen
- op een geveven moment het halve forum onder het mom van opruiming zelfs uit het archief is verwijderd. Zo is er nauwelijks een record van de werkelijke mate van ontevredenheid en omvang van problemen.

Wat dat betreft heeft OCZ net als Sony (o.a. rootkit, ontkennen, rechtszaken tegen devs) het verdiend om geboycot te worden. Blijkbaar werkt het, vandaar nu een "3.20" i.p.v. een stilzwijgende "upgrade" van 34 naar 25nm zoals voor de 2 serie toendertijd.
De eerste Vertex gebruikte een Indilinx controller, de problematische series waren voorzien van Sandforce.
onzin ik heb de vertex 3 nu in verschillende pc's gebouwd en het zijn gewoon retegoede ssd's die gewoon constant hun snelheid vasthouden.
Schrijven wordt fundamenteel trager op het moment dat je alle flash cellen tenminste 1 keer hebt gebruikt, omdat latere schrijfopdrachten eerst de pages moeten wissen.

Dit wordt door Sandforce controllers afgevangen door een overprovisie gedeelte (7% bij OCZ), de firmware probeert deze zo veel mogelijk van te voren te wissen zodat een schrijfopdracht altijd zonder de inherente vertraging gaat, ook al is je 'schijf' vol.

Dit gaat goed zolang de controller de hoeveelheid in 1 keer geschreven data voor kan blijven door vrijgekomen OP blokken in de achtergrond te wissen, wat bij normaal gebruik meestal het geval is. Dit wordt mede geholpen doordat SF controllers compressie toepassen, en de werkelijke hoeveelheid geschreven data daardoor ook nog flink kan dalen, afhankelijk van je gebruikspatroon.

Feit is dat als je b.v. versleuteling toepast (Bitlocker, Truecrypt, of een standaard beveiligde homedir onder Linux e.d.), of veel met grote video bestanden werkt je al snel tegen deze limiet aan zal lopen en je schrijfacties inderdaad significant trager worden. Dit effect was met de eerste generatie SF controllers (Vertex LE/2) nog duidelijker, zo ging het schrijven in de praktijk terug van ~130 MB/s naar 85 MB/s, waar de specs (op basis van compressie) van 200+ MB/s uitgingen.

De juiste manier om dit probleem te omzeilen is natuurlijk om genoeg parallelisme toe te passen zodat ook bij de laagste (write/erase) snelheid het totaal boven de gebruikte bussnelheid (ca. 255 MB/s voor SATA2, 550 voor SATA3) blijft. Dat zal bij lagere capaciteiten moeilijker zijn omdat er minder chips/dies zijn, dat verklaart ook waarom die doorgaans trager zijn.

De OCZ/SF combinatie kreeg de meeste kritiek op dit vlak omdat toen zij nog voorop liepen vanwege de toegepaste compressie helaas ook marketing voor lieten gaan op feiten en bovendien de proces-snelheidsvermindering ontkenden bij de overstap van 34 naar 25nm (brachten o.a. nieuwe modellen uit zonder typenummer verandering), omdat bij doorsnee gebruikspatroon deze door de compressie verhuld werd. Zo moesten zij op een geveven moment toegeven aan forum druk en mensen die een tragere SSD kregen na een RMA alsnog eentje met de snellere 34nm flash op te sturen.

Wat dit nieuwsartikel onvermeld laat is dat met een kleinere procestechnologie ook het aantal P/E cycles achteruitgaat, afhankelijk van de kwaliteit van de gebruikte flash b.v. van 3000 naar 1500, dus de theoretische levensduur van je opslag kan dan gehalveerd worden. Ook hier geldt dat die levensduur voor het meeste gebruik geen probleem zal zijn, maar het is wel interessant om te vermelden voor degenen die dat wel van belang is.
Een LSI 9266 kan tot 2GB/s halen. Weliswaar met SAS-schijven, maar met SATA moet je een heel eind komen. Zet de stripesize op 256KB, forceer het inschakelen van de controllercache (standaard wordt die alleen geactiveerd bij een geladen BBU) en schakel de cache van de schijven in.

In /sys/block/sda zet je de I/O scheduler op deadline en de readahead op 8MB.

Probeer dan nog maar eens.
Dan vaag ik me af waarom het dan geen 590MB/s is. Dat zou ik nog wel geloven. Je maakt mij niet wijs dat er 50MB/s feitelijk door je neus geboord wordt, wat bijna 10% is van wat je overhoudt. Dat is veel te veel voor "overhead". Dat soort overhead heb je in een LAN, waar je bits door 10 moet delen om bytes te krijgen. We hebben het hier over een interne interface, en de enige bekabeling die gebruikt wordt, zit binnenin de kast en hoeft niet speciaal "handig" te zijn (en SATA-kabels zijn ook een drama).

Volgens mij moet je op SATA600 makkelijk 590MB/s kunnen halen, maar zijn de controllers (in de computers dus) gewoon niet toereikend. Ditzelfde probleem heeft USB 2.0 ook - de controllers zijn altijd brak geweest, er is er niet één die de beloofde snelheid haalt. Maar als je een USB 2.0 apparaat op 3.0 aansluit, haal je opeens wél de beloofde USB 2.0-snelheid.

Het lijkt wel alsof het normaal wordt om ons te laten denken dat het "nodig" is om een nieuwe techniek te nemen, omdat de oude het niet meer redt, terwijl de oude techniek in werkelijkheid nog prima meekan als ie beter geimplementeerd wordt.
mijn vertex 3 was ten tijde van aankoop toch echt sneller dan de crucial drives. het was de snelste drive die er was (juni vorig jaar dacht ik)
en de crucial had een lagere reserve ruimte op de disk waardoor hij eerder zou overleiden en ook nog eens asynchroon geheugen ipv synchroon geheugen op de vertex 3.

de vertex 3 was/is dus de betere keuze wat mij betreft.
wel weer iets trager snap niet waarom ze een tragere disk uit zouden willen brengen...
onzin ik heb de vertex 3 nu in verschillende pc's gebouwd en het zijn gewoon retegoede ssd's die gewoon constant hun snelheid vasthouden.

mijn revo en vertex 3 hebben een tijd compleet vol gezeten omdatmijn 2tb aan het overlijden was en de snelheig blijft gewoon hoog dus weet niet waat je je info vandaan heb maar het is onzin.
leuk hoor die snelheid maar die Vertex 3 SSD,s zijn ruk
zodra 50% opslag in gebruik is word de ssd 50% trager en gaat hij zo rond de 250mbps zitten

OCZ levert ruk software voor hun SSD's imho
en dan verkopen ze het als een Indilinx SSD chip terwijl er geen indilinx chip maar een brakke marvel chip inzit

[Reactie gewijzigd door firest0rm op 20 februari 2013 15:32]

Je vergeet 8b/10b encoding, daarom heb je niet de volledige 6Gbit maar hou je maar 4,8Gbit(ofwel 600MB/s) over, waar je denk ik in je handjes mag knijpen als ze het tot ver over de 580MB/s krijgen.
die losse parts zoals jij ze noemt kun je dus prima terug vinden in bv de 4K benches, of bv in het aantal IOPS.

Alhoewel OCZ 65K IOPS specificeert, haal je dat nooit. Desalniettemin haal je in de praktijk alsnog wel rond de 5K IOPS, en dat is een stuk meer dan de 300 die je haalt met bv 15K RPM SAS disks, of de 150 die je haalt met consumenten schijfjes.
zeker heeft het wel met mechanische onderdelen te maken. Doe dezelfde test maar eens op 2x SAS 15K RPM enterprise drives. Die halen sequentieel ook wel 300MB/s, maar met 4K reads zakken ze tot onder de 1 MB/s
ik heb een stuk of 30 Intel 520's in productie draaien op zwaar belaste db servers. Deze gebruiken ook een SF controller, uitval tot nu toe: 0. Ik heb ook een stuk of 10 vertex3's gehad, ook met 0 uitval. Dus het ervaringen verschillen behoorlijk.
@A87 Ik zit er achter!! :D
Ik snap wel waarom dat 4K in IOPS wordt uitgedrukt.

Dit staat een stuk 'sneller'. 20.000 max i/o operations /sec = max 78MB.
En dit haal je in de praktijk nooit. Dit viel mij zwaar tegen na aanschaf van mijn SSD's...

Heb me vaak afgevraagd hoe dit eigenlijk zit.
Er zitten toch geen mechanische onderdelen meer in de seektime zou je verwachten : seq. =~ random.

Uit de praktijk: 2x 512 GB OCZ Vector in Raid 0, Win8, DiskMark (Crystal):

ReadValues in MB/sec
Sequential: 1092MB, Random QD32: 528, Random 4K: 26 !!
Dus omdat er geen mechanische onderdelen in zitten denk je dat sequentieel geordende data evensnel moet gelezen moet kunnen worden dan random verspreide data? Het is toch logisch dat het eerste sneller gaat dan het 2de, random data moet evenzeer bijeen gezocht worden. Dat heeft niets te maken met mechanische onderdelen of niet.
Je hebt altijd wat overhead.
OCZ and SF, not even once
600MB/sec is het theoretische maximum van SATA3. Die ga je in de praktijk waarschijnlijk toch al niet echt halen.
Waarom niet? 600 is toch 600? Het is niet alsof er 40 meter kabel tussen zit.
Edit:Laat maar, ik begrijp dat Nas T het over de verchillen in de SSD's onderling had.
...

Maak daar nog maar iets meer van. ;)

Enkele maanden terug de mechanishe, 500GB Seagate Momentus HDD van mijn laptop (Asus K55a) vervangen voor een 256GB Samsung 830 SSD.

Geschatte batterijduur op 100% lading met HDD: 3 uur en 57 minuten.
Geschatte batterijduur op 100% lading met SSD: 5 uur en 08 minuten.


Verder is de laptop exact hetzelfde geconfigureerd, zelfde schermhelderheid, zelfde max CPU belasting, etc.

[Reactie gewijzigd door Majoras Waker op 20 februari 2013 22:25]

Wat betreft gebruikers ervaring zit de 'traagheid' in kleine sub 16k reads. Vier crucial m4's in raid0 op een LSI 9266-8i haalt bijvoorbeeld maar 240MB/200MB in atto (default instellingen) op 8k.

Op dit item kan niet meer gereageerd worden.



HTC One (M9) Samsung Galaxy S6 Grand Theft Auto V Microsoft Windows 10 Apple iPad Air 2 FIFA 15 Motorola Nexus 6 Apple iPhone 6

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True