Het grote SSD topic ~ Deel 7

[Bullus]

Astennu schreef op woensdag 06 april 2011 @ 17:58:
[...]


Yep aanzienlijk. Crystal disk gebruikt oncomprimeebare data. Waardoor scores wat lager uit zullen vallen. In de praktijk zul je beide tegen komen. Maar op dat soort momenten haal je niet de spec speeds. Maar ondanks dat presteren ze nog steeds heel goed. Dus zelfs worst case zijn ze sneller dan de oude Intel G2's in de oude Vertex1 disks.

Ok thanks, dan laat ik het zo met 2 partities. Wou bijna weer een reinstall doen.

[Astennu]

Bullus schreef op woensdag 06 april 2011 @ 18:14:
[...]


Ok thanks, dan laat ik het zo met 2 partities. Wou bijna weer een reinstall doen.

Ik denk niet dat de partities veel gaan schelen als je daar een grote van maakt. Ik weet natuurlijk niet wat je pressies moet halen in Raid 0 aangezien ik het zelf niet heb. Maar als je 534mb/s haalt zit je op +-267mb/s per SSD lijkt me erg netjes voor een raid setup.

[gekke-gerrit]

Zsub schreef op dinsdag 05 april 2011 @ 11:58:
Vertex 3 120GB op een Asus P8P67 Pro:
[afbeelding]
Lijkt niet zo eindeloos veel af te wijken van de 240.

ik haal lagere waardes met 50% gevuld hoe vol staat die van jou?

[Anoniem: 269504]

Astennu schreef op woensdag 06 april 2011 @ 17:58:
[...]


In de praktijk zul je beide tegen komen.

Er is ook niet zo veel bekend over de gebruikte compressie ,en wat voor files komen in aanmerking voor compressie . Van windows is de ntfs compress ratio per bestand verschillend waarbij met xp de ratio op 33 procent ligt en met W7 op 8 procent

XP/C/WINDOWS


W7/I/WINDOWS


progje 3Dmark06 ligt op 38 procent maar een game als bf1942 staat op slechts 1 procent , waarbij de levels helemaal niet gecomprimeerd worden . Comprimeren is de kunst van het weglaten

[We Are Borg]

Mijn nieuwe intel ssd 320 120GB



De benchmark zegt mij weinig: ben erg blij met de snelle performance die je echt merkt. Na de mislukte aankoop jaren terug van een raptor is dit wel echt merkbaar

[ Voor 16% gewijzigd door We Are Borg op 06-04-2011 22:32 ]

[_H_G_]

maratropa schreef op woensdag 06 april 2011 @ 17:00:
serieus Voor 100 euro vond ik het wel een aardige deal en ik weet zeker dat ie voor mijn toepassing prima gaat zijn. 60gb is ook net goed qua formaat. Qua schrijfsnelheid heb ik ook niet echt eisen voor deze.. Maar ik ben benieuwd.. Volgens mij werkt de 25nm variant best prima in real-life..

Inderdaad Mooi prijsje.

Zou persoonlijk voor een corsair F60 zijn gegaan, al zal de ervaring niet merkbaar zijn. Da's meer de nasmaak van OCZs actie. En ik weet nog niet 100% zeker of OCZ nu wel alle 60GB versies leveren met 8 kanalen in gebruik. Misschien dat je dat eens kort kan benchen (1x50MB ofzo). Als het geen 35MB/s sequentieel is, dan zal het wel goed zitten.

Zo te zien aan de pricewatch is Corsair ook 25nm versies aan het leveren en zal OCZ wellicht gelijk hebben dat 34nm moeilijker te verkrijgen is voor de non-NAND-makers. Ze geven iig in de omschrijving en serienummer aan dat het 25nm is. Benieuwd of ze dezelfde grootte NANDs gebruiken.

edit: ik heb een stukje aan TS toegevoegd m.b.t. benchmarks. Ik kan zelf niet echt een zinnige reactie geven als men enkel een CDM benchmark plaatst (zoals hier boven). Met AS SSD hebben we iig een beeld of de alignment goed is en welke driver/chipset er ongeveer gebruikt worden. Eventueel met extra ATTO om problemen tussen Windows en een Sandforce SSD te kunnen zien. Als iemand andere ideeën heeft, graag: dan pas ik het wel aan.

[ Voor 16% gewijzigd door _H_G_ op 06-04-2011 23:00 ]

[Femme]

Anoniem: 15758 schreef op woensdag 06 april 2011 @ 17:14:
[...]

Persoonlijk lijkt mij het idee van een RAID driver met AHCI interface ipv SCSI een veel makkelijkere oplossing om alsnog TRIM-on-RAID op Windows 7 out-of-the-box zonder speciale drivers en multi-platform mogelijk te maken.

Het nadeel daarvan is dat sata command queuing niet verder gaat dan 32 openstaande commando's terwijl scsi in theorie 2^64 commando's kan queuen. Daarom zullen fabrikanten van professionele raidcontrollers, die geschikt moeten zijn voor gebruik in serveromgevingen, nooit controllers ontwikkelen die zich aan het besturingssysteem presenteren als een ahci-device. Voor een simpele vierpoorts sata-controller zal een queuinglimiet van 32 commando's denk ik niet veel bezwaren opleveren.

Ik begreep van Adaptec dat de scsi-jongens het umap-commando willen gaan gebruiken als scsi-alternatief voor trim. Ik kon daar ten tijde van de Cebit niets over vinden.

[-Moondust-]

Maakt het voor de performance nog uit of ik een Intel 320 SSD aansluit op een SATA3 of een SATA2 port? Of presteren beide porten identiek?

[Anoniem: 303530]

Beiden presteren identiek.

[Sjah]

Anand heeft zijn zoveelste Vertex3 review, net online.

[Philflow]

Da's de review van de 120GB versie:
http://www.anandtech.com/...ocz-vertex-3-review-120gb

[ Voor 44% gewijzigd door Philflow op 07-04-2011 09:22 ]

[_-= Erikje =-_]

Hmm, iemand anders ook problemen met zijn/haar Vertex2 80 gbyte? ik heb er gisteren 1tje binnen gehad, die werd niet herkend door het bios in 3 verschillende systemen. Naja kan gebeuren, ik terug naar de winkel en omgeruild voor een nieuwe. Deze doet wel iets meer (groen lampje) maar word ook niet herkend door het bios naja ik ga 'm nog maar een keer omruilen, wellicht dat ze een slechte batch gehad hebben of zo

[- J.W. -]

Sjah schreef op donderdag 07 april 2011 @ 00:44:
Anand heeft zijn zoveelste Vertex3 review, net online.

Da's wel een van de interessantere reviews anders, al het gedoe met OCZ uit de doeken.. (meer dan al bekend was)... en natuurlijk nog het 120 GB model onder de loep

[ Voor 34% gewijzigd door - J.W. - op 07-04-2011 11:20 ]

[Philflow]

_-= Erikje =-_ schreef op donderdag 07 april 2011 @ 11:17:
Hmm, iemand anders ook problemen met zijn/haar Vertex2 80 gbyte? ik heb er gisteren 1tje binnen gehad, die werd niet herkend door het bios in 3 verschillende systemen. Naja kan gebeuren, ik terug naar de winkel en omgeruild voor een nieuwe. Deze doet wel iets meer (groen lampje) maar word ook niet herkend door het bios naja ik ga 'm nog maar een keer omruilen, wellicht dat ze een slechte batch gehad hebben of zo

bekend probleem. ligt volgens mij aan de firmware. het niet herkennen zou opgelost zijn met de laatste firmware.

Zie OCZ support forums.

[_-= Erikje =-_]

Philflow schreef op donderdag 07 april 2011 @ 11:20:
[...]

bekend probleem. ligt volgens mij aan de firmware. het niet herkennen zou opgelost zijn met de laatste firmware.

Zie OCZ support forums.

Hmm, maar das lastig installeren als die al niet herkend word

[- J.W. -]

Booten vanaf HDD of live-cd en dan firmware flashen..

[_-= Erikje =-_]

doelde er meer op dat die flash tools ook gewoon zeggen dat er geen OCZ drives gevonden zijn (wat logisch is als het bios 'm al niet ziet)

[Philflow]

Voor wie het nog niet wist: Vertex 2 25nm mag gratis worden omgeruild voor 34nm exemplaren.
Verder zullen er Vertex 2 modellen komen met 34nm en Intel/Micron NAND garantie.

Bron: http://www.anandtech.com/...z-vertex-3-review-120gb/4

[Help!!!!]

- J.W. - schreef op donderdag 07 april 2011 @ 11:20:
[...]

Da's wel een van de interessantere reviews anders, al het gedoe met OCZ uit de doeken.. (meer dan al bekend was)... en natuurlijk nog het 120 GB model onder de loep

Zeker. Goed om te zien dat Anand bij dit soort issues bedrijven stevig aanspreekt.

Ik vind het publiceren, al dan niet met toestemming, van emails alleen altijd wat minder. Komt wat Story achtig over...

[Astennu]

Philflow schreef op donderdag 07 april 2011 @ 09:21:
Da's de review van de 120GB versie:
http://www.anandtech.com/...ocz-vertex-3-review-120gb

Erg nette review. Ook veel extra info over 34 vs 25nm NAND. En dat OCZ nieuwe SKU's uitbrengt om dat transparant te maken voor de consument. Echt op van Anandtech en OCZ!

Helaas wat we al vreesden zijn de smaller Capacity drivers trager. Helaas zijn de 510,320 en de M4 nog niet in een maatje kleiner getest. Maar daar zal wel een soort gelijk beeld te zien zijn. Je kunt de controllers dan niet meer optimaal benutten doordat er minder NAND devices zijn. Voor mij maakt dat niet uit omdat ik toch al een budget van 400-450 euro voor een SSD heb staan. Maar er zijn genoeg mensen die dat niet hebben.

[- J.W. -]

Philflow schreef op donderdag 07 april 2011 @ 12:11:
Voor wie het nog niet wist: Vertex 2 25nm mag gratis worden omgeruild voor 34nm exemplaren.
Verder zullen er Vertex 2 modellen komen met 34nm en Intel/Micron NAND garantie.

Bron: http://www.anandtech.com/...z-vertex-3-review-120gb/4

Apart. Het zou dan een recall van een recall worden.. Ik heb het overigens niet kunnen vinden bij OCZ op de site.

originele recall:
64 Gbit 25nm NAND --> 32 Gbit 25nm NAND

nieuwe recall (?):
32/64 Gbit NAND 25nm --> 32 Gbit 34nm NAND


De grootste schok is eigenlijk dat er dus nóg een variant bestaat: 32nm Hynix NAND.
Da's inferieur aan de 34nm én 25nm tegenhangers, verkocht in 10% van de gevallen.
Ik vind het echt ongehoord...

[ Voor 3% gewijzigd door - J.W. - op 07-04-2011 13:09 ]

[Philflow]

Er vinden geen recalls plaats, de klant moet zelf iniatief nemen.

"If you purchased a Vertex 2 and ended up with lower-than-expected performance or are unhappy with your drive in any way, OCZ committed to exchanging the drive for a configuration that you are happy with. Despite not doing the right thing early on, OCZ ultimately commited to doing what was right by its customers."

[Help!!!!]

- J.W. - schreef op donderdag 07 april 2011 @ 12:59:
[...]

Apart. Het zou dan een recall van een recall worden.. Ik heb het overigens niet kunnen vinden bij OCZ op de site.

originele recall:
64 Gbit 25nm NAND --> 32 Gbit 25nm NAND

nieuwe recall (?):
32/64 Gbit NAND 25nm --> 32 Gbit 34nm NAND


De grootste schok is eigenlijk dat er dus nóg een variant bestaat: 32nm Hynix NAND.
Da's inferieur aan de 34nm én 25nm tegenhangers, verkocht in 10% van de gevallen.
Ik vind het echt ongehoord...

Dat is het natuurlijk ook. Helaas weet bijna niemand het en daarom gaan de meeste fabrikanten er gewoon mee door. Dus wel goed van OCZ dat ze het zo oppakken.

Hetzelfde zie je ook bij televisies. Daar worden ook verschillende panels in hetzelfde type gebruikt. Extreem irritant.

[Astennu]

Help!!!! schreef op donderdag 07 april 2011 @ 13:31:
[...]

Dat is het natuurlijk ook. Helaas weet bijna niemand het en daarom gaan de meeste fabrikanten er gewoon mee door. Dus wel goed van OCZ dat ze het zo oppakken.

Hetzelfde zie je ook bij televisies. Daar worden ook verschillende panels in hetzelfde type gebruikt. Extreem irritant.

Pc schermen ook..... En ook in telefoons. Super iri maar je doet er niets aan

[- J.W. -]

@Philflow: Recall is idd te veel glorie voor OCZ.
Het heeft niet eens bij OCZ op de frontpage gestaan, alleen op hun forum in een sticky..

Je moet maar hopen dat het bij de Vertex 3 allemaal goed gaat. Al zou je denken dat ze hun lesje geleerd hebben, the hard way. Alleen als je in de geschiedenis van OCZ duikt, hebben ze al vaker dubieuze dingen gedaan.
Als je bijvoorbeeld naar Corsair kijkt, die heeft enkel Intel 34 nm NAND gebruikt in hun F-serie (zonder A), zoals het hoort.

Help!!!! schreef op donderdag 07 april 2011 @ 13:31:
[...]

Dus wel goed van OCZ dat ze het zo oppakken.

Ze hebben in den beginne alles ontkend, niks aan de hand. Na lang gezeur mocht er dan vervangen worden onder bijbetaling.. nu zijn ze onder druk van diverse sites / klanten gezwicht (als je het toevallig te weten komt).
Nee, het verdient zelfs nu niet de schoonheidsprijs, dan hadden ze met de billen bloot gemoeten en een grote recall moeten beginnen.


Maar je hebt gelijk, er zijn meerdere fabrikanten die zo werken

[ Voor 5% gewijzigd door - J.W. - op 07-04-2011 13:43 ]

[Help!!!!]

- J.W. - schreef op donderdag 07 april 2011 @ 13:40:
@Philflow: Recall is idd te veel glorie voor OCZ.
Het heeft niet eens bij OCZ op de frontpage gestaan, alleen op hun forum in een sticky..

Je moet maar hopen dat het bij de Vertex 3 allemaal goed gaat. Al zou je denken dat ze hun lesje geleerd hebben, the hard way. Alleen als je in de geschiedenis van OCZ duikt, hebben ze al vaker dubieuze dingen gedaan.
Als je bijvoorbeeld naar Corsair kijkt, die heeft enkel Intel 34 nm NAND gebruikt in hun F-serie (zonder A), zoals het hoort.


[...]

Ze hebben in den beginne alles ontkend, niks aan de hand. Na lang gezeur mocht er dan vervangen worden onder bijbetaling.. nu zijn ze onder druk van diverse sites / klanten gezwicht (als je het toevallig te weten komt).
Nee, het verdient zelfs nu niet de schoonheidsprijs, dan hadden ze met de billen bloot gemoeten en een grote recall moeten beginnen.


Maar je hebt gelijk, er zijn meerdere fabrikanten die zo werken

Ik bedoel meer: Goed dat het nu uiteindelijk zo oppikken.

Zeker ook omdat ze nu verschillende SKU's gaan gebruiken. En waarschijnlijk ook betere performance karakteristieken op de doos gaan zetten....

[_H_G_]

Help!!!! schreef op donderdag 07 april 2011 @ 14:16:
.. En waarschijnlijk ook betere performance karakteristieken op de doos gaan zetten....

Eerst zien.. Ik denk niet dat ze er iets op gaan zetten waardoor hun producten er slechter uit komen dan een concurrent die hetzelfde maakt, zoals een minimum of gemiddelde er op zetten terwijl de concurrent er een maximum op zet. Tuurlijk heeft Anand hier wel ideeën over: die wil wel z'n eigen storagebench op alle SSDs zien

Maar da's al een probleem sinds dag één. Hoe weten wij, als consument, wat beter/slechter is. Reviews met tientallen A4jes aan benchmarks en nog kan je er verschillende conclusies aan trekken.

[Astennu]

_H_G_ schreef op donderdag 07 april 2011 @ 14:37:
[...]

Tuurlijk heeft Anand hier wel ideeën over: die wil wel z'n eigen storagebench op alle SSDs zien

Nee dat is helemaal niet zo. Je moet geen dingen gaan zeggen die niet kloppen. Ze waren voor een beter meet methode ipv max snelheid die je misschien in hele ideale omstandigheden kan halen. In het artikel staat dat OCZ misschien AS SSD gaat gebruiken.

[_H_G_]

Astennu schreef op donderdag 07 april 2011 @ 14:42:
Nee dat is helemaal niet zo. Je moet geen dingen gaan zeggen die niet kloppen. Ze waren voor een beter meet methode ipv max snelheid die je misschien in hele ideale omstandigheden kan halen. In het artikel staat dat OCZ misschien AS SSD gaat gebruiken.

Zoals ik zei: ik denk niet dat ze er een minimum (AS SSD) snelheid op printen, terwijl de concurrent er max (ATTO) snelheid op print. En wat is er niet zo? Je denkt dat Anand niet graag z'n benchmark scores ziet op alle SSDs? Het is trouwens een mening: geen sprake van wel/niet kloppen.

[Help!!!!]

_H_G_ schreef op donderdag 07 april 2011 @ 15:02:
[...]

Zoals ik zei: ik denk niet dat ze er een minimum (AS SSD) snelheid op printen, terwijl de concurrent er max (ATTO) snelheid op print. En wat is er niet zo? Je denkt dat Anand niet graag z'n benchmark scores ziet op alle SSDs? Het is trouwens een mening: geen sprake van wel/niet kloppen.

OCZ is redelijk vaak slecht in het nieuws dus ik weet niet of Anand daar zo nodig zijn naam aan wil koppelen.
Sowieso denk ik niet dat Anand het daar om te doen is.

Waar het uiteindelijk op neer komt is dat SSD's performance blijkbaar ook bepaald wordt door

1. NAND proces technologie,
2. NAND merk
3. capaciteit vd drive

OCZ is in ieder geval de eerste fabrikant is die verschillende SKU's uitbrengt die 1 onderkent. Echter, volgens jouw theorie zouden ze dit nooit doen omdat anderen het ook niet doen. Daarmee is jouw argument al ontkracht. Je ziet de goede wil bij OCZ en het dus zeker niet onaannemelijk dat ze ook voor 2 en3 stappen ondernemen.

Sites als Anand testen hierop en achterhalen uiteindelijk wel hoe het echt zit. Veel (potentiele) klanten ergeren zich aan dit soort praktijken.
Je kunt uiteraard ook positieve publiciteit genereren door als eerste e.e.a. te onderkennen en er wat mee te doen.

[Vraaag]

Welke benchmarkprogramma is nou een goede om Vertex 2 60GB & Intel 320 80GB te vergelijken?

[Philflow]

Vraaag schreef op donderdag 07 april 2011 @ 16:42:
Welke benchmarkprogramma is nou een goede om Vertex 2 60GB & Intel 320 80GB te vergelijken?

Je bedoelt om een indruk te krijgen van de echte snelheid? De enige manier om dat te doen is real life benchmarks, bijv. boottimer.exe of de file copy benchmark in AS-SSD.

Een iets minder goede manier is een trace based benchmark zoals PC Mark Vantage.

Synthetische benchmarks (CDM, ATTO) geven een zeer beperkte indruk van de echte snelheid.

[Bullus]

Even de AS-SSD getest, maar volgens mij is mijn raid 0 (ocz vertex 2 60gb) echt te traag.

[Anoniem: 15758]

Als je een 25nm OCZ hebt dan lijken die scores goed te kloppen. Wat had je precies verwacht? Alleen de oudere 34nm met 32Gb NAND doet netjes 100MB/s met de 60GB versie.

Edit: hmm dit lijkt toch niet de 25nm versie te zijn; kun je dat bevestigen? Leg ook even uit wat C en F bij je is?

[ Voor 26% gewijzigd door Anoniem: 15758 op 07-04-2011 21:13 ]

[Philflow]

Ik heb totaal geen verstand van RAID maar moet de seq. write niet 2x zo hoog zijn? dit lijkt net een single drive, qua write.

De 4K read ziet er ook niet echt goed uit, zou weleens het intelppm probleem kunnen zijn.

[Anoniem: 303530]

Wat is er precies mis met zijn 4k read?

RAID heeft geen voordeel voor random snelheden met lage que depth.

[Bullus]

De ssd's zijn van sep/okt 2010 dus waarschijnlijk gewoon 34nm, heb 2 partities gemaakt in raid 0 c: en f:

Ik had nog andere benches gedraait en gepost ,maar zal ze nog ff allemaal posten

atto, lijkt me goed


cdm


Wat ik nu afvraag, zijn mijn benches nu volgens specs of onder de maat?
Volgens as-ssd presteren ze nl minder dan de single vertex 2 100gb seq./write, wat ik zo heb vergeleken bij een review.
http://www.techspot.com/r...cz-vertex2-ssd/page5.html

[ Voor 4% gewijzigd door Bullus op 07-04-2011 21:39 ]

[Philflow]

Anoniem: 303530 schreef op donderdag 07 april 2011 @ 21:24:
Wat is er precies mis met zijn 4k read?

Ik haalde 24 MB/sec, maar dat was een 120GB versie. Wat waarschijnlijk gelijk de verklaring is.

[_Arthur]

Gewoon voor de lol ook eens AS-SSD op mijn setje los gelaten;



Dit is een raid0 set van 8 maal 32GB Transcend MLC SSDs (TS32GSSD25S-M) met de niet-zo-geroemde JMicron JMF602B controller. En hangen aan een Dell Perc 5/i met 256MB cache en BBU.

Set is op dit moment bijna 3 jaar oud, van trim hebben ze nog nooit gehoord

[Anoniem: 195780]

Op verzoek verwijderd

[Philflow]

Anoniem: 195780 schreef op donderdag 07 april 2011 @ 21:53:
[...]


Ik zit ook een omruil traject en ben niet echt happy met de gang van zaken.
Na de aanschaf van de laatste Vertex2 in februari, had ik al een erg slecht gevoel, de afhandeling voor een zgn 'betere' Vertex2 maakt dat niet minder.

Deze ultrakorte uitgekiende antwoorden kreeg ik van OCZ support:
"Comment: The replacement will be a 2Xnm 32gbit die drive.
3Xnm and 2Xnm drives have the same performance and longevity."

"Comment: We can replace your current 64gbit NAND drive with another one. It will be a 2Xnm drive using 32gbit NAND chips. It will have the same performance and capacity as an older 3Xnm drive."

Ik zou er niet mee accoord gaan. In het Anandtech artikel wordt aangetoond dat de 34nm sneller is en er wordt door OCZ zelf bevestigd dat je mag omruilen voor 34nm.

[Anoniem: 303530]

Philflow schreef op donderdag 07 april 2011 @ 21:39:
[...]

Ik haalde 24 MB/sec, maar dat was een 120GB versie. Wat waarschijnlijk gelijk de verklaring is.

na 1000 tweaks los te laten op jouw P states

Als ik wat performance tweaks uitvoer haal ik ook 20% hogere random read scores met mijn postvile (u: 18.5, na tweak: 22.0) en 50% hogere random write.

[Anoniem: 195780]

Op verzoek verwijderd

[Sebazzz]

Na eindelijk een werkende Vertex 2 SSD te hebben die niet besluit read-only te worden heb ik nog performanceproblemen. Performanceproblemen die niet aan de SSD liggen, maar aan Windows.

Mijn benchmark op Ubuntu Linux 10.10 64-bit:


Mijn benchmark op Windows 7 Professional 64-bit:


Zoals je ziet is de minimale snelheid die ik in Ubuntu haal nog boven de maximum snelheid die ik in Windows kan halen!

Ergens zit er dus een bitje dwars in Windows. Ik heb echter al diverse Intel AHCI drivers geprobeerd, 9.x en 10.x (ik draai nu 10.1.0.1008) maar het scheelt hoogstens enkele megabytes.

Op het OCZ forum hebben ze het erover dat Windows gewoon een groot log beest is, en dat ik maar een schone installatie moet doen en steeds drivers moet toevoegen totdat ik achter de oorzaak kom maar ik vind dit een beetje moeilijk te accepteren. Er moet toch iets zijn wat ik nu in mijn huidige installatie kan gebruiken om te bepalen waar de bottleneck zit?

[Anoniem: 303530]

Wat voor scores krijg je met atto?

[Sebazzz]

Anoniem: 303530 schreef op donderdag 07 april 2011 @ 22:17:
Wat voor scores krijg je met atto?

Daar heb ik niet zoveel aan, aangezien ik geen equivalent daarvan hebt op Linux. (en ATTO schrijft ook, daar hou ik niet zo van). Maar hier zijn ze:



Iets wat mij opviel tijdens het benchen, is dat ik in taakbeheer zag dat ATTO af en toe 25% CPU at, en dat ik hoge kerneltijden had (de rode lijn), zeker in het begin.

[Anoniem: 303530]

Daar heb je je verklaring, ATTO en de linux benchmark lezen blijkbaar comprimeerbare data uit, hdtune doet dat niet.

[Philflow]

Anoniem: 303530 schreef op donderdag 07 april 2011 @ 22:00:
[...]

na 1000 tweaks los te laten op jouw P states

1 tweak: intelppm uitgezet.

[Sebazzz]

Heb nog een keer gebenched. Schrijven gaat sneller dan lezen...

Anoniem: 303530 schreef op donderdag 07 april 2011 @ 22:29:
Daar heb je je verklaring, ATTO en de linux benchmark lezen blijkbaar comprimeerbare data uit, hdtune doet dat niet.

Dit lijkt mij niet. De benchmark in Ubuntu (Tools -> Administration -> Disk utility) werkt namelijk exact hetzeflde als HD tune: gewoon ruw de schijf uitlezen. En bovendien, op een andere Windowsinstallatie op een andere PC haalt deze SSD gewoon hele nette snelheden. (nog steeds niet zo goed als Ubuntu, maar wel 50 MB/s sneller). Dit is gewoon een issue in mijn installatie, dat kan niet anders, maar waar zit de bug?

[Anoniem: 303530]

Toevallig een *55 chipset?

[Anoniem: 15758]

HDTune laat niet je volledige snelheid zien omdat het maar een queue depth van 1 gebruikt (raw I/O). Dat is niet realistisch en met andere benchmarks (HDtune Pro Files benchmark) en AS SSD / CDM testen op het filesystem en dan zorgt het filesystem voor voldoende queue depth bij sequentiële workloads.

De fluctuerende performance zoals te zien is in Ubuntu en HDTune is ook volkomen normaal. Als je een test doet met CDM behoor je dus hogere sequential read te krijgen.

[Femme]

We hebben vandaag een review gepost van de Samsung SSD 470 waarbij we voor de verandering eens alle varianten (64GB, 128GB en 256GB) hebben kunnen testen. Je ziet ook hier dat er redelijk wat verschil is in prestaties tussen de kleinste en grootste uitvoering. In workloads met redelijk wat schrijfacties (bijv. werken aan grote Photoshopbestanden met veel writes naar de scratchfile) loopt het prestatieverschil op tot 30 procent. De Samsung-ssd's hebben een sterke performance-degradatie naarmate er meer naar de drives is geschreven en de beschikbare capaciteit afneemt. Als met al zijn het geen aanraders.

In deze review testen we tevens de Kingston SSDNow V+100 128GB die gebaseerd is op dezelfde Tosbhia-controller die ook in de MacBook Air wordt geleverd. De geheugenchips op de Kingston-drive zijn anders dan die in de MacBook Air volgens plaatjes van iFixit. De prestaties van de drives zijn vrij aardig maar komen niet mee met de SSD 510 en de Vertex 3 240GB. Performance-degradatie is er nauwelijks: tussen de eerste run met 80GB capaciteitsgebruik en de laatste run waarin er nog maar 4GB vrij was (die tevens nodig was om de schrijfacties te kunnen uitvoeren) namen de prestaties met slechts twee tot drie procent af.

Omdat we niet tevreden waren over de low-level benchmarks in HDTune en IOMeter hebben we AS-SSD toegevoegd. Tevens zijn er metingen van het energieverbruik tijdens sequentieel schrijven toegevoegd. Dit is voor flash-ssd's het worst-case scenario. IOMeter hebben we tot nu op een ongepartioneerde drive gedraaid, abusievelijk met de standaard alignment op 512 bytes. Bij sommige drives leverde dit erg vreemde resultaten op zoals de Kingston SSDNow V+100 die bij een queue depth van 3 een 4K random write van slechts 0,21MB/s haalde. De trace-based benchmarks in NASPT wezen echter uit dat de schrijfprestaties prima in orde zijn (we krijgen uit deze benchmarks stats van zowel gemiddelde lees- als schrijfresponstijd). 4K alignment maakte voor deze drive weinig uit, bij het testen in IOMeter op een partitie ging de 4K snelheid wel omhoog naar zo'n 3,6MB/s wat nog steeds erg schamel is. In AS-SSD doet hij 38,10MB/s 4K random write. Ik moet nog uizoeken hoe IOMeter het beste gedraaid kan worden en of het uberhaupt nog nuttig is voor tests met kleine transfer sizes. Het testen op een ongepartioneerde drive had als voordeel dat je zonder het preparen van de drive meteen het hele capaciteitsbereik kunt aanspreken, wat met name nuttig is bij het testen van grote harde schijven (daarbij wil je dat de kop zich over het hele bereik van de platter verplaatst en niet over een testbestandje van bijv. slechts 8GB).

Zie de review reviews: Vier ssd's van Samsung en Kingston op de pijnbank .

Ik ben nu bezig met het testen van de Intel SSD 320 300GB. In workloads die veel reads doen lijken de prestaties niet beter dan van de Postville. De schrijfpretaties zijn wel aanzienlijk beter.

[Help!!!!]

^
Ondanks dat ik redelijk in de materie zit, blijft het hele SSD gebeuren best complex.
Er zijn behoorlijk veel factoren die een rol spelen.
Is het geen idee om in de conclusie of vlak ervoor alles in een tabel samen te vatten. ?

[ Voor 3% gewijzigd door Help!!!! op 08-04-2011 09:27 ]

[Philflow]

Femme schreef op vrijdag 08 april 2011 @ 09:15:
We hebben vandaag een review gepost van de Samsung SSD 470

Mooie review. Ik zou graag nog wat real world benchmarks zien zoals: de filecopy benchmark in AS-SSD of een gewone Windows 7 boot getimed. Dat zegt me meer dan alle synthetisch benchmarks. Dat een SSD sneller is in de boot trace benchmark is leuk om te weten, maar wat betekent dat nou in de praktijk? hoeveel seconde sneller...

[ Voor 23% gewijzigd door Philflow op 08-04-2011 10:24 ]

[Marc Rademaker]

Philflow schreef op vrijdag 08 april 2011 @ 09:57:
[...]

Mooie review. Ik zou graag nog wat real world benchmarks zien zoals: de filecopy benchmark in AS-SSD of een gewone Windows 7 boot getimed. Dat zegt me meer dan alle synthetisch benchmarks.

De trace-based benchmarks zijn zo real-world als maar mogelijk is.

Het timen van een boottijd, inclusief het opstarten van enkele apps is iets waar ik naar wil gaan kijken. Of het uberhaupt consistente meetresultaten oplevert bijvoorbeeld. Maar daar moet ik eerst een systeem voor configureren, een image van maken en op enkele ssd's proberen. Misschien iets voor over een maandje

[- J.W. -]

Marc Rademaker schreef op vrijdag 08 april 2011 @ 10:28:
[...]

De trace-based benchmarks zijn zo real-world als maar mogelijk is.

Nee, want er wordt volledige incomprimeerbare data weggeschreven en dat is niet 'real world', maar dat is enige pagina's geleden ook al besproken
In het geval van niet sandforce controllers is het wel perfect denk ik.


Klopt de IOMeter - 4K Random Read (q = 3) score wel? Intel G2 en Vertex 2 ruim boven de Intel 510 en Vertex 3? Als het door de 512 alignment komt, ook niet 'real word', is het weinig zinnig imo.

[ Voor 6% gewijzigd door - J.W. - op 08-04-2011 10:44 ]

[Philflow]

Marc Rademaker schreef op vrijdag 08 april 2011 @ 10:28:
[...]
De trace-based benchmarks zijn zo real-world als maar mogelijk is.

Er is maar 1 ding meer real world...

Marc Rademaker schreef op vrijdag 08 april 2011 @ 10:28:
Het timen van een boottijd, inclusief het opstarten van enkele apps is iets waar ik naar wil gaan kijken.

^ Dat dus.

[ Voor 8% gewijzigd door Philflow op 08-04-2011 10:48 ]

[Anoniem: 303530]

- J.W. - schreef op vrijdag 08 april 2011 @ 10:41:
[...]
Klopt de IOMeter - 4K Random Read (q = 3) score wel? Intel G2 en Vertex 2 ruim boven de Intel 510 en Vertex 3? Als het door de 512 alignment komt, ook niet 'real word', is het weinig zinnig imo.

De 510 offert random performance op voor betere schrijftijden, blijkbaar is er een bepaalde verhouding tussen random en seq. I/O waarbij de beste performance gehaald word.

Vergelijk ook eens de postvile met de 320, dezelfde controller, andere prestaties.

[Sebazzz]

Anoniem: 303530 schreef op donderdag 07 april 2011 @ 22:54:
Toevallig een *55 chipset?

Het is een Intel Cantiga PM45 chipset (southbridge is een Intel 82801IM ICH9M).

Anoniem: 15758 schreef op vrijdag 08 april 2011 @ 01:19:
De fluctuerende performance zoals te zien is in Ubuntu en HDTune is ook volkomen normaal. Als je een test doet met CDM behoor je dus hogere sequential read te krijgen.

Daar gaat het niet om, het gaat om het verschil van bijna 100 MB/s tussen Linux en Windows.

[mad_mavrick]

Vanochtend mijn Vertex 3 120 GB binnen gekregen. Dit is mijn eerste SSD dus de cijfers zeggen me niet zoveel.

Hierbij de eerste resultaten van de benchmarks.





De 4k write/reads vond ik tegenvallen persoonlijk. Maar overall ben ik er blij mee

[Anoniem: 303530]

mad_mavrick schreef op vrijdag 08 april 2011 @ 15:31:
De 4k write/reads vond ik tegenvallen persoonlijk. Maar overall ben ik er blij mee

Moet je voor de lol eens CDM op je harde schijf testen, dan schrik je je een ongeluk over de beroerde random performance.

[mad_mavrick]

Anoniem: 303530 schreef op vrijdag 08 april 2011 @ 15:43:
[...]

Moet je voor de lol eens CDM op je harde schijf testen, dan schrik je je een ongeluk over de beroerde random performance.

Ik heb CDM er na de bench direct vanaf gegooid aangezien mijn virusscanner er direct over ging piepen dat er een of ander spyware ding in zat.. altijd lekker die gratis software

[Philflow]

mad_mavrick schreef op vrijdag 08 april 2011 @ 15:50:
[...]
Ik heb CDM er na de bench direct vanaf gegooid aangezien mijn virusscanner er direct over ging piepen dat er een of ander spyware ding in zat.. altijd lekker die gratis software

Lijkt me niet kloppen. AVG wellicht? Die heeft veel false positives.

[mad_mavrick]

Philflow schreef op vrijdag 08 april 2011 @ 15:55:
[...]

Lijkt me niet kloppen. AVG wellicht? Die heeft veel false positives.

Nope, MSE en een vriend van me had het ook.

[Cobiwan]

mad_mavrick schreef op vrijdag 08 april 2011 @ 16:03:
[...]


Nope, MSE en een vriend van me had het ook.

MSE hier niet hoor.

offtopic:
Heerlijk hoe snel een virusscan op de C:\ gaat met SSD trouwens

[ Voor 19% gewijzigd door Cobiwan op 08-04-2011 16:12 ]

[Philflow]

mad_mavrick schreef op vrijdag 08 april 2011 @ 16:03:
[...]
Nope, MSE en een vriend van me had het ook.

Je hebt wel deze gedownload?
http://crystalmark.info/d...ex-e.html#CrystalDiskMark

[Anoniem: 15758]

Sebazzz schreef op vrijdag 08 april 2011 @ 11:57:
Daar gaat het niet om, het gaat om het verschil van bijna 100 MB/s tussen Linux en Windows.

Dat komt hoogstwaarschijnlijk door de beperkte queue depth die HDTune doet. De Ubuntu benchmark doet waarschijnlijk ook raw I/O op de device, maar dan met meer queued I/Os.

HDtune geeft vaak ook veel te lage waardes voor sommige RAID adapters, maar wanneer je test op het filesystem dan heb je wel goede performance. Aangezien je altijd een filesystem gebruikt zijn de scores die HDtune geeft in zo'n geval dus foutief en misleidend.

Wel kun je mooi zien waar data sequentiëel is geschreven (static data) en waar hij random met remap is geschreven (dynamic). Die laatste data zal negatieve pieken laten zien. Dat is heel normaal voor een OS disk met random writes.

[mad_mavrick]

Philflow schreef op vrijdag 08 april 2011 @ 16:15:
[...]

Je hebt wel deze gedownload?
http://crystalmark.info/d...ex-e.html#CrystalDiskMark

I rest my case

Laten we weer ontopic gaan, wat vinden jullie van de performance?

[Twister336]

Anoniem: 303530 schreef op donderdag 07 april 2011 @ 22:29:
Daar heb je je verklaring, ATTO en de linux benchmark lezen blijkbaar comprimeerbare data uit, hdtune doet dat niet.

Ik denk dat de verklaring eerder ligt bij het feit dat HD Tune standaard met blokken van 64 KB werkt.
Als je in HD Tune de blokgrootte op 1 MB instelt zouden de resultaten vergelijkbaar moeten zijn (ook rekening houden dat voor HD Tune 1 KB = 1024 bytes).
Dit zijn mijn scores met mijn Intel 80 GB in HD Tune:

64 KB: 210 MB/s max, 198 MB/s avg
1 MB: 260 MB/s max, 242 MB/s avg

Een groot verschil dus.

Anoniem: 15758 schreef op vrijdag 08 april 2011 @ 01:19:
HDTune laat niet je volledige snelheid zien omdat het maar een queue depth van 1 gebruikt (raw I/O). Dat is niet realistisch en met andere benchmarks (HDtune Pro Files benchmark) en AS SSD / CDM testen op het filesystem en dan zorgt het filesystem voor voldoende queue depth bij sequentiële workloads.

Een grotere queue diepte zorgt inderdaad voor een beter resultaat maar een grotere transfer grootte geeft doorgaans gelijkaardige resultaten. Het principe is dan eigenlijk hetzelfde. Je biedt de driver/controller een enorme hoeveelheid data tegelijk aan waardoor die de gegevens op de meest optimale manier kan lezen/schrijven.
Ik heb als test 3x de benchmark in HD Tune opgestart, dan heb je dus een queue diepte van 3 (uiteraard moet je de resultaten dan wel optellen).

Dit zijn de resultaten:
64 KB: 255 MB/s max, 225 MB/s avg
1 MB: 270 MB/s max, 231 MB/s avg

[Oxize]

mad_mavrick schreef op vrijdag 08 april 2011 @ 15:31:
Vanochtend mijn Vertex 3 120 GB binnen gekregen.

Van welke shop?

[Astennu]

mad_mavrick schreef op vrijdag 08 april 2011 @ 15:31:
Vanochtend mijn Vertex 3 120 GB binnen gekregen. Dit is mijn eerste SSD dus de cijfers zeggen me niet zoveel.

Hierbij de eerste resultaten van de benchmarks.

[afbeelding]

[afbeelding]

De 4k write/reads vond ik tegenvallen persoonlijk. Maar overall ben ik er blij mee

Ziet er goed uit. Ook die 4K vind ik niet tegenvallen. Die nieuwe 25nm NAND chips zouden optimized zijn voor 8K blocks.

[mad_mavrick]

Oxize schreef op vrijdag 08 april 2011 @ 17:26:
[...]


Van welke shop?

SI Computers uit Maassluis woensdagavond besteld en vanochtend binnen. Ik weet alleen niet wat hun voorraad nu is.

@Astennu, thanx voor de feedback, ik had geen idee of dit nu een beetje ok was

[ Voor 11% gewijzigd door mad_mavrick op 08-04-2011 18:43 ]

[Anoniem: 269504]

Twister336 schreef op vrijdag 08 april 2011 @ 16:59:
[...]

Ik denk dat de verklaring eerder ligt bij het feit dat HD Tune standaard met blokken van 64 KB werkt.
Als je in HD Tune de blokgrootte op 1 MB instelt zouden de resultaten vergelijkbaar moeten zijn (ook rekening houden dat voor HD Tune 1 KB = 1024 bytes).
Dit zijn mijn scores met mijn Intel 80 GB in HD Tune:

64 KB: 210 MB/s max, 198 MB/s avg
1 MB: 260 MB/s max, 242 MB/s avg

Een groot verschil dus.

Nu is dat helemaal geen echte snelheid , omdat die max 200MB doet,en dat is wat de meeste doen .
Behalve als je XP gebruikt , waarbij de P voor performance staat die gooit er nog 50MB bovenop

[_Christiaan_]

Weet iemand of de 180 GB Vertex 2 last heeft van het 25 nm performance probleem? Ik lees her en der dat als er een E in de productcode staat, dat je dan pech hebt. Maar ergens anders lees je weer dat de E niks zegt.

Een officiële reply van OCZ zegt dat alleen de kleinere drives dan 180 GB affected zijn: klik. Alleen die reply is al 2 maanden oud.

Echter, ergens anders lees je weer dat ook de 180 GB op 25 nm gebakken zijn. Ik moet zeggen dat ik verbazingwekkend weinig kan vinden over de 180 GB drive.

Wat moet ik nu geloven? En maakt het voor die 180 GB ook zoveel uit als die op 25 nm gemaakt is? Ik las dat die iig geen last heeft van minder geheugen... Alleen wellicht wel van mindere performance t.o.v. de 32 nm?

[Philflow]

Volgens mij gaat dat artikel over 32Gbit vs. 64Gbit. Beide zijn nog steeds 25nm.

Alleen de 34nm drives presteren echt optimaal. In die laatste review van Anandtech wordt het allemaal uitgelegd. Ook wordt daar door een VP van OCZ zwart op wit gesteld dat iedereen met een 25nm drive hem kostenloos mag omruilen voor een 34nm.

[_Christiaan_]

Dus als ik het goed begrijp is het gewoon een kwestie van pech of geluk, en is het maar gokken welk geheugen je krijgt. Er zijn zelfs 3 soorten... Had ik bijna een SSD gekocht, maar ik wacht maar even tot de storm weer geluwd is.

[Sebazzz]

Anoniem: 15758 schreef op vrijdag 08 april 2011 @ 16:18:
[...]

Dat komt hoogstwaarschijnlijk door de beperkte queue depth die HDTune doet. De Ubuntu benchmark doet waarschijnlijk ook raw I/O op de device, maar dan met meer queued I/Os.

Dat snap ik, maar verklaart niet waarom de SSD op een andere computer sneller is (maar nog steeds niet zo snel als in Ubuntu). Ik heb net even met mijn CPU lopen spelen, belasten en niet belasten en ik tikte kort de 200 MB/s aan dus er lijkt een soort throttling plaats te vinden. En dat is raar want in Ubuntu gebeurt het niet, en Ubuntu kan ook 2 keer langer mee dan Windows op de accu.

[Anoniem: 15758]

Als HDtune op de ene pc veel hogere scores geeft met dezelfde instellingen (blocksize) is dat wel raar. Mogelijk kan de Intel RST drivers hier invloed bij hebben, omdat die read-ahead en write-buffering in RAM doet. Dan krijg je betere performance in synthetische benchmarks zoals HDtune.

Het gevaar is echter dat je hierdoor aanneemt dat Intel direct sneller is. De RAM cache en buffer zullen zeker invloed op real-life performance hebben, maar dat betekent niet dat als je 150MB/s in HDtune krijgt er iets mis is. Zeker als CDM en andere filesystem-benchmarks die veel representatiever zijn wél goede resultaten geven.

Een hogere blocksize in HDtune kan wel een workaround zijn. Maar ook met relatief lage blocksize (32K) op je filesystem hoor je optimale performance te krijgen, door queue depth. Dit vereist wel dat NCQ werkt, en vereist dus een AHCI (of SAS) controller.

[_H_G_]

_Christiaan_ schreef op vrijdag 08 april 2011 @ 22:24:
Dus als ik het goed begrijp is het gewoon een kwestie van pech of geluk, en is het maar gokken welk geheugen je krijgt. Er zijn zelfs 3 soorten... Had ik bijna een SSD gekocht, maar ik wacht maar even tot de storm weer geluwd is.

Het echte probleem komt pas als er minder kanalen in gebruik zijn dan de originele versie. Dan zakt de performance aanzienlijk. Dat heb je niet bij de 180GB versie.

Benchmark performance zal wel 15-20% minder zijn, maar of je dat echt merkt.. Gebruikerservaring zal niet zoveel schelen en de prijs per GB is best lekker. Mij lijkt de vertex 2 toch een hele goede keus bij 180GB.

Philflow schreef op vrijdag 08 april 2011 @ 22:01:
Alleen de 34nm drives presteren echt optimaal. In die laatste review van Anandtech wordt het allemaal uitgelegd. Ook wordt daar door een VP van OCZ zwart op wit gesteld dat iedereen met een 25nm drive hem kostenloos mag omruilen voor een 34nm.

Dat staat er niet zwart op wit imho. Ze zeggen toe dat ze de beste oplossing proberen te vinden. Dat laat ze toch nog een deur open voor andere oplossingen (64Gb->32Gb wat bij 180GB geen optie is. Of bijbetaling om een 34nm te krijgen). Dat ze refund als optie noemen is nog wel fijn, maar als koper heb je toch een doel en niet om een paar weken later nog niks te hebben.

[ Voor 33% gewijzigd door _H_G_ op 09-04-2011 00:01 ]

[_Christiaan_]

Dit wordt verteld over de OCZ Vertex 2 180 GB:

180's are slower by design, to create a 180 you run a nand config thats slower than a 120/100 or 240

so im saying if you want the fastest drives go with what is faster by design

Dus je zit ten eerste met de grabbelton, waarbij je hoopt dat je de beste chips hebt (Intel 34 nm, Intel 25 nm, of als je echt pech hebt de Hynix 32 nm, die 30% trager is dan de Intel 34 nm). Ten tweede is de 180GB door de NAND configuratie trager. Jammer genoeg heb ik hier nog geen vergelijkende benchmarks van kunnen vinden, om uit te lichten hoe nadelig die NAND-config werkelijk is.

[Femme]

Philflow schreef op vrijdag 08 april 2011 @ 09:57:
[...]

Mooie review. Ik zou graag nog wat real world benchmarks zien zoals: de filecopy benchmark in AS-SSD of een gewone Windows 7 boot getimed. Dat zegt me meer dan alle synthetisch benchmarks. Dat een SSD sneller is in de boot trace benchmark is leuk om te weten, maar wat betekent dat nou in de praktijk? hoeveel seconde sneller...

Onze trace-based benchmarks zijn niet synthetisch. Ze lezen data van bestanden en schrijven data naar bestanden op dezelfde wijze als applicaties uit de echte wereld. De enige beperking is dat dat de data die geschreven wordt geen real world data is maar random gegereerde data. Daardoor worden drives met SandForce-controllers wat benadeeld. Vooral in de beeldbewerkingstrace met veel writes op de Photoshop-scratchfile zal de SandForce-controller in de praktijk een hoge compressie kunnen halen.

Een nadeel van applicatiegebaseerde benchmarks is dat het erg moeilijk is om complexe gebruikscenario's op identieke wijze te herhalen. Windows en eventueel wat applicaties opstarten is natuurlijk makkelijk keer op keer te herhalen. Het wordt moeilijk als je de responstijden wilt weten van Photoshop tijdens het bewerken van grote bestanden terwijl er in de achtergrond allerlei applicaties draaien die de drive benaderen. Tevens zit je met andere onderdelen in het systeem die de prestaties beïnvloeden. Als je een ssd wilt testen vind ik dat je dat met tests moet doen waarin er zo min mogelijk bottlenecks zijn buiten I/O. Anders ben je namelijk bezig met een systeembenchmark.

In een trace kun je de disk I/O van complexe gebruiksscenario's vastleggen. Het resultaat van een trace-based benchmarks wordt bijna geheel bepaald door de I/O performance van het systeem, zodat je een zuiver oordeel kunt vellen over de prestaties van een drive.

[Philflow]

_H_G_ schreef op vrijdag 08 april 2011 @ 23:51:
[...]
Dat staat er niet zwart op wit imho.

Heb je wel een punt ja. Uit Anand's woorden maakte ik het wel op:

If you purchased a Vertex 2 and ended up with lower-than-expected performance or are unhappy with your drive in any way, OCZ committed to exchanging the drive for a configuration that you are happy with.

Ik ben benieuwd hoe dit gaat uitpakken in de praktijk. Als OCZ mensen hun 25nm niet laat omruilen voor 34nm is dat een fail imo.

Femme schreef op zaterdag 09 april 2011 @ 00:59:
[...]
Onze trace-based benchmarks zijn niet synthetisch. Ze lezen data van bestanden en schrijven data naar bestanden op dezelfde wijze als applicaties uit de echte wereld. De enige beperking is dat dat de data die geschreven wordt geen real world data is maar random gegereerde data.

Volgens mij is er nog een nadeel (tenzij ik het verkeerd begrijp) aan trace based benchmarken. In zo'n benchmark jaag je er een scenario door op maximale snelheid waardoor er maximale stress ontstaat op het storage systeem. Deze stress is echter hoger dan wat je doorgaans in de praktijk zal tegenkomen.

DriveBench produces a trace file for each workload that includes all IOs that made up the session. We can then measure performance by using DriveBench to play back each trace file. During playback, any idle time recorded in the original session is ignored—IOs are fed to the disk as fast as it can process them. This approach doesn't give us a perfect indicator of real-world behavior, but it does illustrate how each drive might perform if it were attached to an infinitely fast system

http://techreport.com/articles.x/19079/6

Gevolg van dit probleem is dat de verschillen die ontstaan in de resultaten van de trace based benchmark mogelijk niet (of anders) terug te vinden zijn in de praktijk.

Ik hou er van hoe Hardwareheaven hun reviews doet, dat vind ik echte real world benchmarks:
http://www.hardwareheaven...review-install-times.html

[ Voor 64% gewijzigd door Philflow op 09-04-2011 08:41 ]

[Philflow]

dubbel

[ Voor 98% gewijzigd door Philflow op 09-04-2011 08:15 ]

[Femme]

Philflow schreef op zaterdag 09 april 2011 @ 07:25:
[...]

Volgens mij is er nog een nadeel (tenzij ik het verkeerd begrijp) aan trace based benchmarken. In zo'n benchmark jaag je er een scenario door op maximale snelheid waardoor er maximale stress ontstaat op het storage systeem. Deze stress is echter hoger dan wat je doorgaans in de praktijk zal tegenkomen.

Je hebt inderdaad gelijk dat dit een mogelijk nadeel is van trace-based benchmarks. In de tool die wij gebruiken (Intel NAS Performance Toolkit) heb je de mogelijkheid om traces full speed of met behoudt van de originele timing uit te voeren. Full speed wil zeggen dat NASPT bij elke gelegenheid die zich voordoet een volgende I/O richting de drive douwt. De drive wordt dan continu maximaal belast. Bij behoudt van de originele timing wordt een I/O uitgevoerd op het moment dat dit in de originele trace ook gebeurde.

Met uitzondering van de data workload traces (met file copy acties e.d.) draaien we alle traces met behoudt van de originele timing. Om tijd te besparen heb ik de pauzes tussen opeenvolgende transacties bij het converteren van de traces (van Process Monitor naar een formaat dat geschikt is voor NASPT) wel beperkt tot 250 milliseconde. 250ms is een eeuwigheid voor een ssd en ook ongeveer tien keer de maximale toegangstijd van een harde schijf.

[Philflow]

^ Interessant, dat stelt weer gerust. En weet je toevallig of Anandtech zijn Storage 2011 benchmarks ook uit voert met behoudt van originele timing?

[ Voor 8% gewijzigd door Philflow op 09-04-2011 09:56 ]

[Twister336]

Anoniem: 15758 schreef op vrijdag 08 april 2011 @ 23:50:
Als HDtune op de ene pc veel hogere scores geeft met dezelfde instellingen (blocksize) is dat wel raar. Mogelijk kan de Intel RST drivers hier invloed bij hebben, omdat die read-ahead en write-buffering in RAM doet. Dan krijg je betere performance in synthetische benchmarks zoals HDtune.

Het gevaar is echter dat je hierdoor aanneemt dat Intel direct sneller is. De RAM cache en buffer zullen zeker invloed op real-life performance hebben, maar dat betekent niet dat als je 150MB/s in HDtune krijgt er iets mis is. Zeker als CDM en andere filesystem-benchmarks die veel representatiever zijn wél goede resultaten geven.

Een hogere blocksize in HDtune kan wel een workaround zijn. Maar ook met relatief lage blocksize (32K) op je filesystem hoor je optimale performance te krijgen, door queue depth. Dit vereist wel dat NCQ werkt, en vereist dus een AHCI (of SAS) controller.

Ik denk niet dat er veel gecached kan worden in de benchmark van HD Tune. De data wordt van het begin tot eind van de schijf gelezen/geschreven, nooit hetzelfde dus.

Het verhaal over de queue depth als magische prestatieverhoger is voor mij heel onduidelijk. Een queue depth is gewoon de lengte van de wachtrij. Ideaal is die altijd minder dan 1.
Nu kun je de queue depth heel eenvoudig bestuderen met perfmon (zit gewoon bij Windows). Als je dan de test in HD Tune uitvoert krijg je een queue depth van ongeveer 1, doe je de (file) test in CDM dan krijg je eveneens een queue depth van 1.
Die QD32 test in CDM is onzin. Als er constant 32 I/O operaties in de wachtrij staan is er iets grondig mis met de systeemconfiguratie. De prestaties van zo'n situatie meten lijkt me dan ook vrij nutteloos.
Als ik verschillende programma's snel na elkaar opstart krijg ik een maximale queue depth van 2,7. Bij normaal gebruik gebeurt het maar zelden dat de queue depth boven de 1 uitkomt.

[Anoniem: 303530]

Dat komt omdat veel programma's gebruik maken van blocking I/O, ofwel, je vraagt een bestand van de schijf en vervolgens komt het process tot stilstand totdat deze data is geleverd dan wel weg is gescheven.

Een fatsoenlijk programma doet aan assychronous i/o, ofwel, er word een bestand gelezen van de scijf en ondertussen werkt het programma gewoon door, bijvoorbeeld om nog een bestand van de schijf af te halen.

Maar merk op, als ik aan windows vraag een bestand van 8KB, verschijnt er een que depth van 1 in resource monitor, maar de disk vat dat op als 2 requests (of dat door de disk zelf gebeurt, of dat windows I/O requests altijd 4KB maakt is mij onduidelijk, ik geloof dat windows altijd met block I/O werkt), een bestand van 32KB kan je dus opvatten als een i/o actie met een que depth van 8 (32KB/4KB).

In het ideale geval staan al die 8 blokken op een andere flash cel, in het slechtste geval op dezelfde flash cel. Een QD van 64 garandeert meestal dat er van alle cellen tegelijk word gelezen.

[330d]

Eergister toch besloten om win7 opnieuw te installeren op mijn postville stripe. Had wat foutmeldingen van windows en op ene of ander manier met de backup van Paragon tijd geleden is mijn array volle 149GB (had ondergepartitioneerd tot slechts 125GB). Alles staat er nu op, en windows start weer vliegensvlug op, dus geen merkbare degradatie . Dit keer Acronis sector-by-sector backup gemaakt met exacte partition table incl de ondergepartitioneerde unallocated space. Dit keer moet het goed gaan met restoren mocht het nodig zijn

[Twister336]

Anoniem: 303530 schreef op zaterdag 09 april 2011 @ 12:54:
Maar merk op, als ik aan windows vraag een bestand van 8KB, verschijnt er een que depth van 1 in resource monitor, maar de disk vat dat op als 2 requests (of dat door de disk zelf gebeurt, of dat windows I/O requests altijd 4KB maakt is mij onduidelijk, ik geloof dat windows altijd met block I/O werkt), een bestand van 32KB kan je dus opvatten als een i/o actie met een que depth van 8 (32KB/4KB).

Hoe zie je dat dan? Als ik de output van diskmon bekijk zie ik een hele hoop requests met verschillende groottes, varierend tussen 512 bytes en 1 MB.
Zijn die 4K requests niet gewoon van de pagefile? Die werkt volgens mij altijd met blokken van 4 KB dus requests naar de pagefile worden denk ik altijd opgedeeld in stukken van 4 KB.

In het ideale geval staan al die 8 blokken op een andere flash cel, in het slechtste geval op dezelfde flash cel. Een QD van 64 garandeert meestal dat er van alle cellen tegelijk word gelezen.

Het heeft toch geen enkele zin om requests in kleine stukjes op te delen. Als je 1 enkele request van 32 KB doet gaat de SSD intern de data uit de juiste cellen halen. Windows weet helemaal niet in welke cellen de gegevens staan. Het enige wat je bereikt met het opdelen is extra overhead.
Bij SSD's is de I/O zo snel dat het meestal geen bottleneck meer vormt en er dus geen of weinig requests in de wachtrij staan. De SSD bombarderen met I/O requests zoals de QD32 test in CDM is dan ook niet echt realistisch. Je krijgt dan misschien wel mooie grote getalletjes maar of je dat in de praktijk ook gaat zien...

[Anoniem: 303530]

Twister336 schreef op zaterdag 09 april 2011 @ 14:25:
[...]

Hoe zie je dat dan? Als ik de output van diskmon bekijk zie ik een hele hoop requests met verschillende groottes, varierend tussen 512 bytes en 1 MB.

Niet, maar storage is voor zover ik weet altijd opgedeeld in blokken van 4k. Een bestand in windows is altijd een veelvoud van 4KB (lam excuus, i know)

De rest van je post weet ik ook niet zo snel te beantwoorden.

[Dj-sannieboy]

Anoniem: 303530 schreef op vrijdag 08 april 2011 @ 15:43:
[...]

Moet je voor de lol eens CDM op je harde schijf testen, dan schrik je je een ongeluk over de beroerde random performance.

Vanmorgen CMD gedraait met een WD Velicio Raptor 300GB. De 4k write/reads kwamen geloof ik niet boven de 1MB uit.

[Anoniem: 15758]

Twister336 schreef op vrijdag 08 april 2011 @ 16:59:
[...]
Een grotere queue diepte zorgt inderdaad voor een beter resultaat maar een grotere transfer grootte geeft doorgaans gelijkaardige resultaten. Het principe is dan eigenlijk hetzelfde. Je biedt de driver/controller een enorme hoeveelheid data tegelijk aan waardoor die de gegevens op de meest optimale manier kan lezen/schrijven.

Voor writes maakt queue depth niet zoveel uit; de QD32 zal maar iets hoger zijn dan de QD1, zeker bij hardeschijven. Bij SSDs hangt het af hoeveel data ze kunnen bufferen; sommigen niet zoveel en dus krijg je wel een redelijk verschil omdat dan de latency toeneemt en je niet alle beschikbare kanalen kunt 'vullen'.

Voor SSDs is queue depth enorm belangrijk met name voor random reads. In tegenstelling tot writes kunnen reads niet gebuffered worden. Bij qd=1 kun je maar één kanaal gebruiken, vergelijkbaar met single-threaded programma's/games die maar één CPU core gebruiken. Dat gebeurt vaak met blocking I/O, wat je veel ziet bij booting en application launch.

In de praktijk zal de queue depth sterk wisselen bij realistische workloads; sequential reads + random reads + een paar random writes. Dat maakt dat vaker meerdere NAND kanalen kunnen worden gebruikt, en je dus wel degelijk nut hebt van de RAID0-achtige structuur van meerdere NAND kanalen die parallel I/O kunnen verrichten. In benchmarks zijn de performance-effecten van meerdere kanalen nagenoeg gelijk aan wat een RAID0 driver met meerdere SSDs zou geven. 4 SSDs van 10 kanalen kun je dus zien als een SSD van 40 kanalen. Bij random reads is een hoge queue depth dan wel belangrijk; bij writes véél minder.

Ik heb als test 3x de benchmark in HD Tune opgestart, dan heb je dus een queue diepte van 3 (uiteraard moet je de resultaten dan wel optellen).

Maar niet contiguous, dus wordt dat een multistream sequential read benchmarks. De queued I/Os zijn dan namelijk niet contiguous; opeenvolgende LBA. Maar bij de meeste SSDs merk je dat geeneens; lezen is bloedje snel van een moderne SSD ook al doe je meerdere streams en wat random I/O tussendoor.

Twister336 schreef op zaterdag 09 april 2011 @ 12:23:
[...]
Ik denk niet dat er veel gecached kan worden in de benchmark van HD Tune. De data wordt van het begin tot eind van de schijf gelezen/geschreven, nooit hetzelfde dus.

Bij sequentiële workloads (contiguous I/O) wordt door de driver of storage device zelf read-ahead toegepast. Als je LBA 0 leest en daarna 1, dan zal elke moderne HDD ook 2, 3, 4, 5, 6, 7, 8 alvast gaan lezen en in de cache chip zetten. Dan kan als daadwerkelijk 2 opgevraagd worden het mechanische gedeelte doorwerken. Als dat stil komt te liggen moet je wachten op een rotational delay, dus read-ahead is absoluut noodzakelijk en een primaire functie van elke moderne HDD.

Bij SSDs werkt het iets anders; Intel SSDs gebruiken de cache-chip niet om data op te slaan; alleen voor de mapping table. De data zelf staat in een 384KiB SRAM buffer geïntegreerd in de controller. Dit maakt dat de Intel controller erg lage latencies kent. Of SSDs read-ahead toepassen weet ik niet, want de latency van SSDs is zo laag dat je zelfs zonder read-ahead al goede leesprestaties krijgt, in tegenstelling tot hardeschijven.

Maar doordat read-ahead zo noodzakelijk was voor vele jaren, is dit geïntegreerd in ALLE filesystems (FAT16/32, NTFS, Ext2/3/4, XFS, JFS, UFS, ZFS). Zelfs DOS had een read-ahead en write buffer driver, ben de naam even vergeten. Zonder die driver was Windows 2000 installeren een 4-uur durende operatie door de trage disk I/O.

Dus als je HDTune gebruikt, doe je I/O die in de praktijk niet voorkomt. Dan kun je verschillen zien tussen drivers die dit intern al toepassen (Intel RST drivers, HDDs, hardware RAID) en storage die dat niet doet (vele RAID drivers, mogelijk ook SSDs).

Het verhaal over de queue depth als magische prestatieverhoger is voor mij heel onduidelijk.

Queue depth stelt de SSD in staat om meerdere kanalen te benutten, net zoals twee programma's tegelijkertijd twee CPU cores kunnen gebruiken. Als je dat niet doet gaat de extra potentiele performance dus naar de haaien. De overige channels krijg je gratis; de performance van de overige I/O wordt er niet door vertraagd.

Bij qd=1 ofwel blocking reads zal de SSD maar één kanaal kunnen gebruiken van de totaal 10 bij Intel. Daarom dat het verschil tussen 4K en 4K32 max een factor 10 is voor Intel en 8 bij Sandforce. Sommige kleine capaciteit modellen hebben minder kanalen (4 bij sandforce, 5 bij intel) en daardoor schaalt de QD32 random reads ook veel minder goed.

Nu kun je de queue depth heel eenvoudig bestuderen met perfmon (zit gewoon bij Windows). Als je dan de test in HD Tune uitvoert krijg je een queue depth van ongeveer 1, doe je de (file) test in CDM dan krijg je eveneens een queue depth van 1.

Omdat de controller de I/O ook even hard weer wegtrekt, heb je geen directe indicatie hoeveel I/Os er gemiddeld gelijktijdig naar de SSD gaan; de effectieve queue depth.

Die QD32 test in CDM is onzin. Als er constant 32 I/O operaties in de wachtrij staan is er iets grondig mis met de systeemconfiguratie.

Als ik mijn VMs opstart op mijn ZFS machine zie ik voor al mijn 4 SSDs een queue depth van 255; de max. Hoe meer queue depth je kunt veroorzaken; des te beter je systeemconfiguratie. Vergelijkbaar met een programma wat multithreaded geschreven is om optimaal gebruik te maken van meerdere CPU cores. Deze vergelijking is wel een beetje kort door de bocht; maar de essentie dat je overige kanalen hebt die je gratis kunt benutten is zeker gelijkwaardig aan het verhaal met CPU cores.

Queue depth veroorzaken is echter een stuk eenvoudiger. Je zult wel zien dat desktop OSen veel minder queue depth veroorzaken dan server-achtige I/O. Blocking reads komen vaak voor op een desktop, en dus zit je voor een deel vast aan de 4K qd=1 performance. Maar dat is nog steeds heel erg goed als je daar 20MB/s kan doen; daarom starten applicaties ook zo snel op vergelijken met HDDs die moeite hebben om 1MB/s te halen en in extreme situaties nog veel minder.

[maratropa]

Grappig, merken jullie ook op dat nu het eigenlijk er minder toe doet (omdat SSD's sowieso rap zijn), men op dit soort fora nog dieper de stof in duikt?

Ik heb het idee dat sinds er SSD's zijn de babbel nog technischer en complexer is geworden, terwijl de te behalven winst procentueel kleiner is qua gevoels-snelheid..

[R2-D2]

maratropa schreef op zaterdag 09 april 2011 @ 20:12:
Grappig, merken jullie ook op dat nu het eigenlijk er minder toe doet (omdat SSD's sowieso rap zijn), men op dit soort fora nog dieper de stof in duikt?

Daarom heet het ook Tweakers.net

[alt-92]

_H_G_ schreef op vrijdag 08 april 2011 @ 23:51:
[...]
Het echte probleem komt pas als er minder kanalen in gebruik zijn dan de originele versie. Dan zakt de performance aanzienlijk. Dat heb je niet bij de 180GB versie.

Benchmark performance zal wel 15-20% minder zijn, maar of je dat echt merkt.. Gebruikerservaring zal niet zoveel schelen en de prijs per GB is best lekker. Mij lijkt de vertex 2 toch een hele goede keus bij 180GB.

Bij al het vertex2 25/34nm gedoe hoor ik eigenlijk nooit wat over de Agility2 series...
Hoe is het eigenlijk daarmee gesteld?
(heb voor 210 euro een pricewatch: OCZ Agility 2 SATA II 3.5" SSD 180GB te pakken, vandaar)

[ Voor 13% gewijzigd door alt-92 op 10-04-2011 00:19 ]

[Philflow]

alt-92 schreef op zondag 10 april 2011 @ 00:15:
[...]

Bij al het vertex2 25/34nm gedoe hoor ik eigenlijk nooit wat over de Agility2 series...
Hoe is het eigenlijk daarmee gesteld?
(heb voor 210 euro een pricewatch: OCZ Agility 2 SATA II 3.5" SSD 180GB te pakken, vandaar)

Voor zover ik weet precies hetzelfde verhaal. Is ook geswitched naar 25nm en gebruikt meestal IMFT NANDs.

Zou dus ook onder de omruil regeling moeten vallen.

[ Voor 71% gewijzigd door Philflow op 10-04-2011 00:23 ]

[alt-92]

Aan de andere kant: het is een 180GB dus die zou dan weer qua aantal kanalen weer mee moeten vallen.
En voor 210 euro is het ook niet echt een totale miskoop als je nu met een brakke 120G sata2 drive zit.

[Philflow]

Je zult mij ook niet horen zeggen dat het een miskoop is. Ook met 25nm NAND is het een snelle SSD. Ik denk niet dat iemand in de praktijk het verschil zal merken tussen 25nm en 34nm.

Bovendien staat er nu het verhaal op Anandtech dat je gratis zou mogen omruilen. Ik heb dit overigens nog niet bevestigd gezien.

[ Voor 9% gewijzigd door Philflow op 10-04-2011 05:45 ]

[Phuncz]

maratropa schreef op zaterdag 09 april 2011 @ 20:12:
Grappig, merken jullie ook op dat nu het eigenlijk er minder toe doet (omdat SSD's sowieso rap zijn), men op dit soort fora nog dieper de stof in duikt?

Ik heb het idee dat sinds er SSD's zijn de babbel nog technischer en complexer is geworden, terwijl de te behalven winst procentueel kleiner is qua gevoels-snelheid.

Eigenlijk apprecieer ik de overdaad aan technische input juist enorm, die vooral komt van CiPHeR. Het lijkt nu misschien overdaad omdat de technologie alle kanten opgaat maar vergeet niet bij HDD's dat we nooit compleet beeld van de werking ervan hadden, simpelweg omdat je ze niet zomaar even kon opendraaien om te zien wat erin zat. Ook zijn de zelftoetsende factoren mbt. benchmarking veel strenger dus eindelijk is het gedaan dat men enkel keek naar transferrate. Dankzij de uitgebreide input kunnen we nu en later geschikter zoeken naar een goede SSD voor de toepassing.

Ik hoop ook dat de kennis samengevat wordt bij de topicstarts om het overzichtelijk te houden

[Anoniem: 303530]

En we gaan hier verder:

Het grote SSD topic ~ Deel 8