Supersnelle Vertex 3 .... of toch niet ?

[GtaDomii]

Hallo medetweakers,

Ik heb al een paar weken in het bezit van een Vertex 3 120GB.
De SSD voelt snel aan, ik dacht.. laat ik eens een benchmarkje draaien, toen werd ik een beetje verdrietig.

[/url]

Hij is aangesloten op een Sata 600 poort die op mijn moederbord zit, wat kan het probleem zijn dat mijn SSD 'maar' 150MB/S leest ? (hij moet dik 500MB/S+ aankunnen..)

Gtadomii

[omgwtfbbq]

Wat zijn de specs van de rest van je PC? Ik weet dat sommige SSD's op een Marvell SATA3 controller slechter presteren dan op een SATA2 controller.

[Verwijderd]

HDtune gebruikt raw i/o, op een SSD werkt dat bijzonder slecht, daarom haal je vrijwel altijd slechte scores in HDtune.

Je kan beter testen met cristaldiskmark (3x50MB, de rest standaard instellingen) of AS SSD.

[GtaDomii]

omgwtfbbq schreef op donderdag 05 mei 2011 @ 20:42:
Wat zijn de specs van de rest van je PC? Ik weet dat sommige SSD's op een Marvell SATA3 controller slechter presteren dan op een SATA2 controller.

De specs zijn :

Core i7 870
8gb corsair 1600mhz
P7P55D-E (daar zit hij op aangesloten)
Asus GTX460 top
2x 2TB Samsung
LG Blu-Ray brander

Het lijkt me dat mijn pc die snelheid makkelijk moet kunnen halen?

Verwijderd schreef op donderdag 05 mei 2011 @ 20:45:
HDtune gebruikt raw i/o, op een SSD werkt dat bijzonder slecht, daarom haal je vrijwel altijd slechte scores in HDtune.

Je kan beter testen met cristaldiskmark (3x50MB, de rest standaard instellingen) of AS SSD.

Daar haal ik dezelfde snelheden mee

[ Voor 27% gewijzigd door GtaDomii op 05-05-2011 20:46 ]

[Verwijderd]

Dat is gek, hoe snel is hij met ATTO?

Edit: of nog beter, een screenshot van de AS SSD compressietest.

[ Voor 48% gewijzigd door Verwijderd op 05-05-2011 21:02 ]

[Philflow]

Is dit een clean install?
Heb je Intel RST geinstalleerd?

[HMeijer]

Probeer de SSD eens aan te sluiten op de SATA II poort en probeer dan nog eens.

[leuk_he]

Zie je onder info van hdtune ook dat het SATA III is? (geen idee waar je dat ziet precies eigenlijk)

Staaat hij in de bios als ACHI (zal nu wel op auto staan... geen idee of dat ACHI of IDE is)

met name de marvel 9123 controller.

De 2 sata poorten naast de IDE controller zijn de 6 Gbit poorten he?

[GtaDomii]

Ik weet 100% zeker dat hij op IDE mode staat, dat kon ik namelijk met die controller niet veranderen??

[Verwijderd]

Voordat je nu allemaal dingen gaat veranderen, test eerst eens met een goede benchmark:

AS SSD
of
CrystalDiskMark (nieuwe 3.x versie)

Dan krijg je vast en zeker al veel betere resultaten. Pas dan kun je vergelijken wat eventuele tweaks of veranderde settings uithalen. Anders zit je maar een beetje te kloten zonder te weten wat het effect is van de veranderde instellingen, IMO.

[Philflow]

^ Ja CDM. En zet de BIOS gelijk op AHCI.

[GtaDomii]

Ik kon hem niet op AHCI zetten, ik kon alleen de intel controller op AHCI zetten, dit heb ik wel gedaan.

[leuk_he]

De Marvel zou ik echt op ACHI zetten. En uiteraard zeker weten dat je hem aan de marvel poort aansluit. Volgens de manual moet je echt kunnen kiezen en staat hij standaard op IDE. (windows moet je wellicht wel opnieuw installeren als je boot van die schijf)

Er zijn echt meetbare verschillen. (en ergens hier op het forum heb ik spectaculariere verschillen gezine dan de benchmark hieronder.

http://benchmarkreviews.c...d=38&limit=1&limitstart=7

Echter jouw snelheid lijkt eerder of je op een SATA-I poort hebt aangesloten. maar die zitten er niet op. .. toch...

[Verwijderd]

Dit ligt gewoon aan je moederbord want hij heeft alleen 2 x SATA 6.0 Gb/s ports (Gray) van Marvell. De rest is 3.0 Gb/s.
Buiten dat heb ik ook de Vertex 3 120GB(Max IOPS) op een Maximus 4 Extreme en hiermee haal ik makkelijk een read van 500MB/s en 356MB/s write.

[omgwtfbbq]

Mijn SSD doet op de Marvell controller (IDE of AHCI) het slechter dan op een de SATA2 controller van Intel. Heb je 'm al eens geprobeerd op een SATA2 poort?

[GtaDomii]

Verwijderd schreef op vrijdag 06 mei 2011 @ 07:25:
Dit ligt gewoon aan je moederbord want hij heeft alleen 2 x SATA 6.0 Gb/s ports (Gray) van Marvell. De rest is 3.0 Gb/s.
Buiten dat heb ik ook de Vertex 3 120GB(Max IOPS) op een Maximus 4 Extreme en hiermee haal ik makkelijk een read van 500MB/s en 356MB/s write.

Ik heb 4 Sata 600 poorten, ik heb ook nog zo'n Asus kaartje er in zitten, maar ik zal hem morgen eens op de Sata 3.0Gb/s doen, eens kijken wat er dan gaat gebeuren.

Wat trouwens ook vreemd is.. HD tune en andere programma's geven aan dat de SSD 128 graden is, maar volgens mij zit er helemaal geen temperatuur sensor in een ssd?

[ Voor 58% gewijzigd door GtaDomii op 06-05-2011 11:33 ]

[Verwijderd]

GtaDomii schreef op vrijdag 06 mei 2011 @ 11:26:
[...]

Ik heb 4 Sata 600 poorten, ik heb ook nog zo'n Asus kaartje er in zitten, maar ik zal hem morgen eens op de Sata 3.0Gb/s doen, eens kijken wat er dan gaat gebeuren.

Wat trouwens ook vreemd is.. HD tune en andere programma's geven aan dat de SSD 128 graden is, maar volgens mij zit er helemaal geen temperatuur sensor in een ssd?

There is no working temp sensor on the drive.
http://www.ocztechnologyf...-with-the-C2(Temperature)

[Twister336]

Verwijderd schreef op donderdag 05 mei 2011 @ 20:45:
HDtune gebruikt raw i/o, op een SSD werkt dat bijzonder slecht, daarom haal je vrijwel altijd slechte scores in HDtune.

Gelukkig klopt dat niet want raw I/O is het enige wat een SSD begrijpt.
Anders zou je nooit deze resultaten krijgen:
http://thessdreview.com/o...iew-hdtune-pro-benchmark/
De raw benchmark van HDTune geeft dus exact hetzelfde resultaat als de file benchmark van HD Tune, CDM en AS SSD.
Het voordeel van een raw benchmark is dat je geen kostbare write cycles verspilt met het testen van de leessnelheid.

Je kan beter testen met cristaldiskmark (3x50MB, de rest standaard instellingen) of AS SSD.

TS zegt dat hij dezelfde resultaten krijgt met CDM.
Ik vind de benchmarkmethodes die hier vaak voorgesteld worden op zijn minst vreemd.
Iemand krijgt onverwachte (lage) resultaten met benchmark A en wordt aangeraden om benchmark B te gebruiken.Zijn die resultaten ook niet goed? Geen probleem: op naar benchmark C en zo maar verder testen tot er uiteindelijk een programma wordt gevonden die resultaten geeft die aan de verwachtingen voldoet.

[Verwijderd]

Twister336 schreef op vrijdag 06 mei 2011 @ 22:07:
De raw benchmark van HDTune geeft dus exact hetzelfde resultaat als de file benchmark van HD Tune, CDM en AS SSD.

Dat is niet waar. Met HDtune kan je raw van de sectoren lezen, wat gebeurt er als je iets leest waar nog nooit eerder iets is geschreven? De SSD doet dan geen moeite het flash te bereiken, hij stuurt gewoon een lading nullen terug.

Hij gebruikt ook nog eens eeu que depth van 1, met mijn postvile krijg ik in CDM veel hogere resultaten dan DHtune.

[Verwijderd]

Wat Darkstone zegt is correct; HDTune is een zéér synthetische benchmark die I/O op een manier uitvoert die in de praktijk nooit voorkomt. Sequential I/O zonder read-ahead of write-buffering komt gewoon nergens voor behalve in dit soort synthetische benchmarks.

Gevolg is dat sommige storage die intern al read-ahead / write buffering uitvoert geen enkel verschil zal laten zien, maar andere storage wel en HDTune een véél te laag resultaat laat zien wat je nooit zult ervaren wanneer je normaal op je filesystem werkt.

Ik heb overigens nog geen CDM of AS SSD screenshot gezien. Jammer, want zodra je allemaal instellingen gaat veranderen kun je niet meer controleren of dat nu effect heeft gehad. Het is namelijk prima mogelijk dat in het begin HDtune wel slechte performance aangaf, maar benchmarks die op filesystem-niveau werken zoals AS SSD en CDM (en alle échte programma's) wél correcte performance krijgen.

[Philflow]

Twister336 schreef op vrijdag 06 mei 2011 @ 22:07:
[...]
Iemand krijgt onverwachte (lage) resultaten met benchmark A en wordt aangeraden om benchmark B te gebruiken.Zijn die resultaten ook niet goed? Geen probleem: op naar benchmark C

Dat zie je verkeerd imo. Mensen met SSDs wordt vrijwel altijd CDM of AS-SSD aangeraden, met reden (zie hierboven). Mensen met Sandforce SSDs wordt ook regelmatig aangeraden om ATTO te draaien om even te kijken of de juiste doorvoer wordt gehaald (dit kan ook met CDM 0-fill).

HDTune was ontworpen met traditionele harde schijven in gedachten en biedt te weinig info.

[ Voor 9% gewijzigd door Philflow op 07-05-2011 09:33 ]

[Cocytus]

500MB/s read haal je sowieso niet. Ja, misschien in sequential reads bij hogere transfersizes en hogere QDs. 350MB/s write haal je ook nooit, alleen met sterk comprimeerbare data. Installeer eens CrystalDiskInfo en kijk dan in welke transfer mode je SSD zit.

@Hieronder: je hebt gelijk. Met Sandforce SSDs haal je de opgegeven schrijfsnelheid niet in AS-SSD.

[ Voor 169% gewijzigd door Cocytus op 07-05-2011 13:23 ]

[Philflow]

AS-SSD werkt met random data, dat is geen optimaal scenario voor Sandforce SSDs. ATTO en CDM met 0 fill zijn optimaal voor Sandforce.

[Twister336]

Verwijderd schreef op vrijdag 06 mei 2011 @ 23:35:
Wat Darkstone zegt is correct; HDTune is een zéér synthetische benchmark die I/O op een manier uitvoert die in de praktijk nooit voorkomt. Sequential I/O zonder read-ahead of write-buffering komt gewoon nergens voor behalve in dit soort synthetische benchmarks.

Hier zit je er dus naast. CDM, AS SSD, ATTO en alle ander benchmarks gebruiken ook geen buffering, die wordt expliciet uitgeschakeld bij het lezen/schrijven van de testbestanden. Logisch, anders zou je de cache aan het testen zijn want alle operaties worden op dezelfde bestanden gedaan.
Hier is bv. een write operatie van CDM:



Zo'n I/O operaties komen in de praktijk nooit voor. CDM en AS SSD zijn dus ook zeer synthetisch. Maar synthetisch is net goed, want dan test je de hardware en niet het besturingssysteem.
Een niet-synthetische benchmark zou aangeven dat mijn mechanische HDD ruim 10.000 IOPS haalt wat dus niet het geval is.

Gevolg is dat sommige storage die intern al read-ahead / write buffering uitvoert geen enkel verschil zal laten zien, maar andere storage wel en HDTune een véél te laag resultaat laat zien wat je nooit zult ervaren wanneer je normaal op je filesystem werkt.

Dat is dus niet het probleem. Als HDTune lagere resulaten weergeeft zal het wellicht zijn omdat de blokgrootte nog op 64 KB ingesteld staat. Als die in de opties op 1 MB wordt gezet zouden de resultaten identiek of beter (geen file system overhead) moeten zijn.
Optimalisaties die de SATA driver (bv. de Intel RST driver) en de SSD doen worden zowel door HD Tune als file benchmarks gebruikt.

Ik heb overigens nog geen CDM of AS SSD screenshot gezien. Jammer, want zodra je allemaal instellingen gaat veranderen kun je niet meer controleren of dat nu effect heeft gehad. Het is namelijk prima mogelijk dat in het begin HDtune wel slechte performance aangaf, maar benchmarks die op filesystem-niveau werken zoals AS SSD en CDM (en alle échte programma's) wél correcte performance krijgen.

Niet dus. 'Echte' programma's gebruiken read-ahead en write-buffering. CDM en AS SSD niet.

[Verwijderd]

Twister336 schreef op zaterdag 07 mei 2011 @ 14:32:
[...]

Hier zit je er dus naast. CDM, AS SSD, ATTO en alle ander benchmarks gebruiken ook geen buffering, die wordt expliciet uitgeschakeld bij het lezen/schrijven van de testbestanden.

Jij hebt het over RAM caching; dat is wat anders dan read-ahead en write buffering.

Write buffering is alleen zo uit te schakelen:
HOW TO: Manually Enable/Disable Disk Write Caching

CDM en AS SSD zijn dus ook zeer synthetisch.

Nee, CDM en AS SSD gebruiken dezelfde API calls als échte programma's. Zeker voor sequential I/O is dit dus een heel realistische test.

Dat is dus niet het probleem. Als HDTune lagere resulaten weergeeft zal het wellicht zijn omdat de blokgrootte nog op 64 KB ingesteld staat. Als die in de opties op 1 MB wordt gezet zouden de resultaten identiek of beter (geen file system overhead) moeten zijn.

Dat klopt, maar de crux is dat zelfs met 64KiB blocksize maar mét read-ahead cq. write buffering je ook optimale performance krijgt. Daar zorgt je filesystem voor. Bij BSD is het ook zo dat 1MiB requests automatisch worden gesplit in meerdere 128K requests; dus hoger kan sowieso niet. Door de hogere queue depth merk je daar niets van.

Niet dus. 'Echte' programma's gebruiken read-ahead en write-buffering. CDM en AS SSD niet.

Programma's gebruiken dat niet - filesystems gebruiken dat. Programma's hoeven zich daar niet mee bezig te houden.

Sorry Twister, maar hier zit je echt niet bij het juiste einde. Ik kan er aan toevoegen dat ik uitgebreide benchmarks heb verricht juist omtrent dit punt. Als je meer over I/O wilt leren kan ik je Solaris/BSD met D-trace aanraden, dan kun je exact zien wat je filesystem doet en wat een synthetische benchmark zoals dd op een raw device node doet, en leer je waarom het een kunstmatig is en het ander niet.

[Twister336]

Verwijderd schreef op zaterdag 07 mei 2011 @ 14:52:
[...]

Jij hebt het over RAM caching; dat is wat anders dan read-ahead en write buffering.

Write buffering is alleen zo uit te schakelen:
HOW TO: Manually Enable/Disable Disk Write Caching

Hoe schakelt HD Tune die cache dan uit?

Ik had het over de OS caching wat softwarematig eenvoudig kan uitgeschakeld worden en wat zowel CDM, AS SSD als HD Tune doen.
Dit is de beschrijving die Microsoft hierover geeft:
The system opens a file with no system caching. This flag does not affect hard disk caching.
Over welke cache heb jij het dan?

Nee, CDM en AS SSD gebruiken dezelfde API calls als échte programma's. Zeker voor sequential I/O is dit dus een heel realistische test.

Start process explorer eens op en kijk welke API calls HD Tune gebruikt: CreateFile, ReadFile en WriteFile.
Exact dezelfde als échte programma's gebruiken (file is een zeer ruim begrip in Windows).

Dat klopt, maar de crux is dat zelfs met 64KiB blocksize maar mét read-ahead cq. write buffering je ook optimale performance krijgt. Daar zorgt je filesystem voor.

Hoe verklaar je deze resultaten dan?
Philflow in "Het grote SSD topic ~ Deel 8"
Een verschil van 145 MB/s tussen 64K en 1MB requests. ATTO is een file benchmark.

Sorry Twister, maar hier zit je echt niet bij het juiste einde. Ik kan er aan toevoegen dat ik uitgebreide benchmarks heb verricht juist omtrent dit punt. Als je meer over I/O wilt leren kan ik je Solaris/BSD met D-trace aanraden, dan kun je exact zien wat je filesystem doet en wat een synthetische benchmark zoals dd op een raw device node doet, en leer je waarom het een kunstmatig is en het ander niet.

Aangezien dit toch specifiek over Windows benchmarks gaat denk ik niet dat het echt relevant is wat bv. dd doet.
Ik heb onder Windows uitgebreide benchmarks gedaan, ook met rauwe trace data. Wat het lezen betreft geven de benchmarks (ook HD Tune) exact de 'echte performantie' weer.
Bij het schrijven geven de traces doorgaans veel hogere snelheden (door de cache neem ik aan).

Het is niet mijn bedoeling kost wat kost gelijk te krijgen maar de zaken die jij hier vertelt komen niet overeen met de resultaten die ik krijg.

[Verwijderd]

Twister336 schreef op zaterdag 07 mei 2011 @ 16:14:
Hoe verklaar je deze resultaten dan?
Philflow in "Het grote SSD topic ~ Deel 8"
Een verschil van 145 MB/s tussen 64K en 1MB requests. ATTO is een file benchmark.

Wat bedoel je daarmee? ATTO gebruikt een que depth van 4, met een request van 64KiB krijg je dan een que depth van 4 op het opslagmedium, dat is bij lange na niet genoeg om een Sandforce (8 kanalen) of een intel (10 kanalen) optimaal te benutten.

[Verwijderd]

Twister336 schreef op zaterdag 07 mei 2011 @ 16:14:
[...]

Hoe schakelt HD Tune die cache dan uit?

HDTune doet RAW I/O, dus helemaal geen filesystem API maar het openen van een ruwe disk. Dat wordt ook door sommige systeemprogramma's gedaan die persé niet op filesystem mogen werken.

AS SSD en CrystalDiskMark gebruiken API calls net zoals echte programma's dat doen. Je hebt wel gelijk dat ze flags gebruiken om filesystem caching uit te schakelen, anders zou het net weggeschreven bestand nog in RAM staan en bij het lezen je de RAM testen ipv de storage.

Ik had het over de OS caching wat softwarematig eenvoudig kan uitgeschakeld worden en wat zowel CDM, AS SSD als HD Tune doen.

Caching werkt op filesystem-niveau; je OS cached geen raw disk I/O. HDtune hoeft dus niets uit te schakelen. Het spreekt je schijf op een totaal andere manier aan dan CDM en AS SSD. Overigens heeft HDtune Pro wel een "Files" benchmark, die wel op je filesystem wordt uitgevoerd.

Dit is de beschrijving die Microsoft hierover geeft:
The system opens a file with no system caching. This flag does not affect hard disk caching.
Over welke cache heb jij het dan?

Ik heb het over read-ahead and write buffering, dat is heel wat anders dan RAM caching wat je filesystem gebruikt om bestanden (geen ruwe blocks) te cachen. In feite wordt alle RAM die ongebruikt is door programma's als filecache gebruikt. Dit kun je eenvoudig zien in Task Manager, klik op Performance tab en zie onder de "Cached" hoeveelheid RAM. Dit kan heel groot worden, maar heeft als voordeel dat als programma's meer RAM nodig hebben dit snel wordt weggedonderd en dus wel degelijk beschikbaar geheugen betreft.

Start process explorer eens op en kijk welke API calls HD Tune gebruikt: CreateFile, ReadFile en WriteFile.
Exact dezelfde als échte programma's gebruiken (file is een zeer ruim begrip in Windows).

API calls naar je filesystem kunnen niet bepalen waar de data naartoe wordt geschreven of van gelezen. HDtune doet raw I/O zelfs als er geen filesystem is. Sterker nog, om de write test uit te voeren moet je verplicht je filesystem wegdonderen als beveiliging omdat het dan willekeurig LBA zal overschrijven en zonder die beveiliging je filesystem corrupt raakt.

Hoe verklaar je deze resultaten dan?
Philflow in "Het grote SSD topic ~ Deel 8"
Een verschil van 145 MB/s tussen 64K en 1MB requests. ATTO is een file benchmark.

10% verschil ofzo, dat klopt dus aardig. Met HDtune kun je verschillen krijgen van 80%; waarbij dus op filesystem-niveau je 5x hogere performance krijgt dan in HDtune. Dit komt het meest voor bij FakeRAID zoals Silicon Image / JMicron en andere softwarematige RAID die zelf geen read-ahead toepast. HDtune laat dan erg lage performance zien (bij 64KiB) blocks terwijl ATTO zich daar niets van aan trekt omdat het filesystem zorgt voor een hogere queue depth (cq. read-ahead).

Bij kleine request grootte zoals onder de 64KiB is je CPU vaak een bottleneck. Vooral onder Windows platform omdat Windows alle I/O single threaded uitvoert; bij een quadcore met hyperthreading ben je dus CPU-bottlenecked op 12,5%.

[ Voor 3% gewijzigd door Verwijderd op 07-05-2011 16:36 ]

[GtaDomii]

Nou, na even gekeken te hebben in de bios.. heb ik gezien dat hij wel in AHCI-mode staat.


Als het om deze chip gaat?

Als dit goed staat, wat kan het probleem dan zijn ?

[_Arthur]

GtaDomii schreef op zondag 08 mei 2011 @ 12:06:
Als dit goed staat, wat kan het probleem dan zijn ?

Dat je geen CDM benchmark plaatje post
Dat je geen AS-SSD benchmark plaatje post
Dat je een Marvell controller gebruikt
Etc.

[Masterkale1]

Voor het mooie moet je gewoon een intel controler gebruiken.
http://www.ocztechnologyf...te-Tweaks-amp-Utilities-*

Daar kan je de stappen langslopen om de boel te optimaliseren.

Met mijn vertex 3 max iops (p8p67deluxe) kom ik hier op uit:

[GtaDomii]

Zie hier mijn Crystaldiskmark score, waarvan overigens mijn halve pc van vast loopt als ik hem draai..


Zijn er meer mensen die problemen hebben met slechte snelheden met de marvell controller ?

[ Voor 21% gewijzigd door GtaDomii op 08-05-2011 13:19 ]

[Verwijderd]

Daar mag je best om huilen; de 4K read - de belangrijkste spec voor OS disks - is nog lager dan hardeschijven. Dat duidt op een serieus probleem. Dat kan om een driverprobleem gaan; de driver kun je met AS SSD zien. Het kan ook zijn dat je SSD verkeerd aligned is. Ook dat kun je met AS SSD zien ("OK" of "BAD").

Na die AS SSD benchmark geopend te hebben en bovenstaande gecontroleerd te hebben, kun je twee dingen proberen:
- nieuwe Marvell drivers downloaden en installeren
- je SSD op je veel betere Intel controller zetten (ja 3Gbps; maar sneller dan je 6Gbps Marvell) en nogmaals de benchmark draaien.

Overigens hoef je in CDM niet 5x 1000MB te testen. 1x 50MB en dan twee of drie keer draaien lijkt me veel beter.

[Twister336]

GtaDomii schreef op zondag 08 mei 2011 @ 13:18:
Zie hier mijn Crystaldiskmark score, waarvan overigens mijn halve pc van vast loopt als ik hem draai..
[afbeelding]

Zijn er meer mensen die problemen hebben met slechte snelheden met de marvell controller ?

Ja, ik. Bij het testen van de random access test zit er op bepaalde reads een vertraging van exact een minuut als mijn SSD op de Marvell controller is aangesloten.
Dus mijn ervaring zegt me dat die Marvell controller het probleem is.
Jouw SSD zit trouwens al voor 88% vol wat ook niet bepaald ideaal is.

Verwijderd schreef op zaterdag 07 mei 2011 @ 16:34:
[...]
Ik heb het over read-ahead and write buffering, dat is heel wat anders dan RAM caching wat je filesystem gebruikt om bestanden (geen ruwe blocks) te cachen.

Read ahead, write back cache (aka. lazy write) worden allemaal behandeld door de Windows cache manager. En het is die cache manager die door benchmarks wordt omzeild.
Programma's kunnen trouwens de read ahead en lazy write afzonderlijk uitschakelen bij hun file I/O. Dat is niet meer dan een vlag specifieren bij het openen van het bestand.

10% verschil ofzo, dat klopt dus aardig.

Geen 10% maar 35% verschil bij de leesprestaties.

De resultaten zijn toch wel duidelijk. CDM geeft exact dezelfde resultaten als HD Tune, wat de TS al na 10 minuten had gemeld. Hij had gerust 5 GB writes kunnen besparen wat niet zo'n slecht idee is op een bijna volle SSD.

[Verwijderd]

Twister336 schreef op zondag 08 mei 2011 @ 19:21:
De resultaten zijn toch wel duidelijk. CDM geeft exact dezelfde resultaten als HD Tune, wat de TS al na 10 minuten had gemeld. Hij had gerust 5 GB writes kunnen besparen wat niet zo'n slecht idee is op een bijna volle SSD.

Hoe verklaar je dan dat ik hogere scores haal met CDM dan met HDtune?





Dat noem ik niet dezelfde resultaten..

[Twister336]

Dat ligt dus aan 64 KB vs 1 MB reads. CDM gebruikt altijd 1 MB blokgroottes bij de sequentiele test, bij HD Tune kun je dat instellen (standaard is dit 64 KB).

64K read:


1M read


Bij ATTO kun je het verschil tussen 64 KB en 1 MB reads ook duidelijk zien: