Het grote SSD topic ~ Deel 7

[Sebazzz]

Verwijderd 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.

[Verwijderd]

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

[Philflow]

Verwijderd 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...

Verwijderd 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?

[Verwijderd]

Toevallig een *55 chipset?

[Verwijderd]

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 ]

[Verwijderd]

- 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]

Verwijderd 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).

Verwijderd 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

[Verwijderd]

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]

Verwijderd 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

[Verwijderd]

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]

Verwijderd 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.

Verwijderd 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 ]

[Verwijderd]

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]

Verwijderd 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.

[Verwijderd]

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]

Verwijderd 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.

[Verwijderd]

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]

Verwijderd 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...

[Verwijderd]

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]

Verwijderd 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.

[Verwijderd]

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

[Verwijderd]

En we gaan hier verder:

Het grote SSD topic ~ Deel 8