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

Meer informatie

Door , , reacties: 32, views: 24.137 •

Tweakers.net heeft in het verleden baanbrekend werk verricht op het gebied van storage-benchmarks, maar soms moet je jezelf opnieuw uitvinden. Dit was het geval voor onze testprocedure voor ssd's en harde schijven. Onze nieuwe testmethodiek is het resultaat van vele jaren ervaring met het testen van harde schijven, raidadapters en solid state drives. De kern van ons nieuwe testprotocol is een uitgebreide set trace-based benchmarks, waarin opnames van de diskactiviteit van echte applicaties wordt teruggespeeld op de te testen drive. In deze .plan lees je alles over het hoe en waarom van de nieuwe benchmarks.

Low-level benchmarks: ongeschikt

Het testen van opslagproducten is van oudsher een discipline waarvoor nauwelijks goede kant-en-klare benchmarks beschikbaar zijn die de prestaties op een realistische manier meten. De meeste hardeschijfbenchmarks zijn synthetische tests voor low-level karakteristieken, zoals de media- en bufferdoorvoersnelheden, de toegangstijden en de random i/o-prestaties. ATTO Disk Benchmark, HDTune, HDTach en CrystalMark zijn bekende voorbeelden van dergelijke benchmarks.

Synthetische benchmarks genereren workloads die weinig overeenkomsten met de praktijk hebben en zijn daarom geen goede methode om de prestaties van een opslagapparaat te testen. In de praktijk krijgen harde schijven en solid state drives een mix van sequentiële, random en cachebare i/o voor hun kiezen. In een desktopomgeving zal er vaak sprake zijn van een geringe belasting, maar als de gebruiker actief wordt, zal het regelmatig voorkomen dat een drive ineens door meerdere applicaties tegelijkertijd wordt benaderd. De prestaties worden door een combinatie van de volgende factoren bepaald:

  • Media: de doorvoersnelheid en latency van het fysieke medium, zoals flashgeheugen of magnetische schijven;
  • Cache: het vermogen van lees- en schrijfbuffers om gegevens te cachen en de doorvoersnelheid en latency van deze buffers. Het gaat daarbij niet alleen om de cache van drives, maar ook van bijvoorbeeld raidadapters;
  • Parallelliteit: het vermogen om meerdere gelijktijdige i/o's uit te voeren, bijvoorbeeld door meerdere drives in raid te draaien of door een combinatie van command queuing en meerkanaals flashgeheugen; en
  • Interface: de latency en de bandbreedte van interfaces en i/o-processors, zoals de pci-express- en sata-interfaces en i/o-processors op raidadapters.

Low-level benchmarks zijn nuttig om inzicht te krijgen in de prestaties van een drive, maar in de praktijk tonen ze alleen factoren die de prestaties positief of negatief beïnvloeden, en niet de prestaties zelf. Om een goed idee te krijgen van de real-world prestaties van een drive is er maar één goede manier, en dat is om de disk-i/o van echte applicaties op de drive los te laten.

Er zijn twee methoden om tot een realistische belasting van de drives te komen. De eerste is het gebruik van applicatiebenchmarks, die de tijd meten waarbinnen een applicatie een bepaalde taak uitvoert. De tweede methode is het vastleggen van de disk-i/o van workloads met een zogeheten trace, die vervolgens eindeloos op exact dezelfde wijze teruggespeeld kan worden. De prestaties kunnen vervolgens gemeten worden aan de hand van de gemiddelde responstijd of de doorvoersnelheid.

Trace-based benchmarks: geschikt

Aan het gebruik van applicatiebenchmarks kleven allerlei nadelen. Zo is het niet eenvoudig om complexe handelingen steeds op exact dezelfde wijze te herhalen, helemaal als ook multitasking-scenario's nagespeeld moeten worden. Een minstens zo groot nadeel is dat de prestaties niet enkel door het opslagsysteem worden bepaald, maar ook door factoren als de snelheid van de processor, het geheugen en de videokaart. Dat is prima als we de totale systeemprestaties willen meten, maar onwenselijk als we de prestaties van individuele componenten - in dit geval: harde schijven of solid state drives - willen vergelijken.

We willen immers weten hoe deze drives in vergelijking tot elkaar presteren, zonder dat er allerlei externe bottlenecks meespelen, die voor elke gebruiker anders zijn. Trace-based benchmarks zijn de perfecte oplossing voor dit probleem. Zij maken het mogelijk om realistische workloads na te bootsen die uitstekend repetitief uitgevoerd kunnen worden en enkel de prestaties van het opslagsubsysteem meten. De kern van ons nieuwe testprotocol wordt daarom opnieuw gevormd door een uitgebreide set trace-based benchmarks.

De beschikbaarheid van trace-based benchmarks voor ssd's en harde schijven is beperkt. PCMark Vantage is een veelgebruikte trace-based benchmark, maar heeft een tamelijk beperkte omvang. In het verleden heeft Tweakers.net ook de Intel Ipeak Storage Performance Toolkit gebruikt om traces op te nemen en af te spelen. Ipeak SPT was een zeer krachtige tool waarmee een diepgaande analyse gemaakt kon worden van de prestaties van opslagapparatuur. Helaas is er sinds 1999 geen nieuwe versie meer uitgekomen. Het recentste besturingssysteem waarop Ipeak SPT draait, is de 32bits versie van Windows XP. Het moge duidelijk zijn dat dit pakket niet langer gebruikt kan worden.

Gelukkig heeft Intel een paar jaar geleden onder de naam NAS Performance Toolkit een nieuwe tool voor het draaien van trace-based benchmarks uitgebracht. Hoewel de naam suggereert dat deze software alleen geschikt is voor het testen van nas-apparatuur, leent deze toolkit zich ook uitstekend voor het benchen van harde schijven, solid state drives en raidadapters. Hoewel NASPT de mogelijkheid biedt om traces af te spelen, ontbreekt een tool om traces op te nemen. Tweakers.net heeft daarom een eigen conversietool gebouwd om traces van de Process Monitor om te zetten naar een formaat dat de NAS Performance Toolkit snapt.

Een belangrijk verschil tussen de NAS Performance Toolkit en de Ipeak Storage Performance Toolkit is dat de eerste het bestandssysteem test, terwijl de laatste direct block devices aanspreekt. De cache van het bestandssysteem heeft in NASPT daardoor invloed op de prestaties. Dit is onwenselijk, omdat enkel ongecachete benadering van het bestandssysteem in de traces is opgenomen. Om het effect van filesystemcaching te beperken wordt er getest op een systeem dat softwarematig is gelimiteerd op 1,5GB geheugen. Overigens bestaat dit systeem uit een H67-moederbord met een cpu uit Intels Sandy Bridge-line-up: de Core i5 2500K.

Een voordeel van de NAS Performance Toolkit is dat we eenvoudig de positie waarop een drive wordt getest kunnen variëren met behulp van de partitie-indeling. Dit is nuttig bij harde schijven die, naarmate de schijf meer naar de binnenkant van de platter wordt benaderd, minder presteren. De omtrek van de sporen op de platter is daar immers kleiner waardoor er per omwenteling minder gegevens ingelezen of weggeschreven kunnen worden.

In ons nieuwe testprotocol draaien we voor hdd's drie runs van onze benchmarks. De eerste begint op de buitenste sporen van de schijf, de tweede op eenderde van de capaciteit en de derde op tweederde van de capaciteit. Met de Ipeak Storage Performance Toolkit hadden we die mogelijkheid niet: daar werden altijd vaste blokadressen benaderd. Omdat de traces waren opgenomen op een Raptor van 73GB, werd in de praktijk alleen de eerste 70GB van harde schijven getest. Bij de grote harde schijven van tegenwoordig is dat niet meer realistisch. Van een 2TB-harddisk zou alleen de eerste vijf procent van de capaciteit getest worden, waar de prestaties het hoogst zijn.

Onze methodiek

Bij het testen van ssd's draaien we eveneens drie runs, maar schuiven we niet met partities. Wel testen we in de drie runs met verschillende hoeveelheden beschreven capaciteit op de drives. Bij de eerste run wordt er een partitie van 90GB gemaakt, die met circa 80GB aan data wordt beschreven. Dit is de data die tijdens de tests daadwerkelijk benaderd wordt. Voor het begin van de tweede run wordt de helft van de resterende ongepartioneerde capaciteit volgeschreven met willekeurige data. Voor de derde run wordt de resterende ongepartitioneerde capaciteit beschreven. Er resteert dan nog ongeveer 10GB vrije capaciteit op de drive, waarvan tijdens de tests ongeveer 4GB gebruikt wordt. Met de tweede en derde run simuleren we dat de drive tijdens zijn levenscyclus voller raakt; zo zien we eventueel prestatieverlies als gevolg van een afnemend aantal vrije geheugenblokken.

In de praktijk is het aannemelijk dat gebruikers van een ssd met een capaciteit van 120GB of groter minstens 10GB capaciteit zullen vrijlaten. Om de effecten van een extreem lage hoeveelheid vrije capaciteit te testen, voeren we eventueel nog een vierde run uit, waarin nog eens 6GB van de testpartitie wordt volgeschreven. Er resteert dan 4GB vrije ruimte, precies het minimum om de tests te kunnen uitvoeren. De resultaten van deze run worden niet meegewogen in het prestatiegemiddelde van de drive.

De tests zelf bestaan uit 23 traces waarin de volgende activiteiten plaatsvinden:

  • Boot trace: twee traces van het booten van Windows 7 en het starten van diverse applicaties op twee verschillende systemen;
  • Desktop workload: het opvragen van websites met veel afbeeldingen, het doorzoeken van een 5GB grote mailbox, het openen van documenten in een tekstverwerker, het bekijken van grote pdf-documenten, het bekijken van kleine afbeeldingen in Photoshop, bestanden comprimeren, muziek beluisteren in iTunes en het doorzoeken van een iTunes-collectie;
  • Graphics workstation: het bewerken van meerdere zeer grote bestanden in Photoshop CS5, het importeren van 25-megapixelfoto's in Lightroom 3 en het browsen door een Lightroom-catalogus;
  • Video-editing workstation: het editen van een uitgebreid project in Sony Vegas Pro 9.0 met lossless gecomprimeerde full hd-video;
  • Software install: het op de achtergrond installeren van Photoshop CS5, terwijl de gebruiker op de voorgrond zijn e-mailarchief gebruikt, websites bekijkt en bestanden downloadt;
  • Data workloads: traces van handelingen waarin uitsluitend met data gewerkt wordt. Bevat een bestandscompressietrace, een trace met uitsluitend de activiteit op de datapartities van de Graphics en Video-editingworkstationtraces, en file copy traces voor respectievelijk grote, middelgrote en kleine bestanden op drie manieren: naar disk, van disk en op disk, waarbij bron en doel op dezelfde drive staan; en
  • Gaming: traces van het opstarten en het laden van levels in de games Call of Duty: Black Ops, Call of Duty: Modern Warfare 2, Dawn of War, Dirt en Stalker: Call of Pripyat.

In totaal wordt er voor deze 23 traces 43,2GB aan data gelezen en 36,8GB aan gegevens geschreven. Bij het voorbereiden van de testdata wordt er 77,6GB aan bestanden naar de drive geschreven. Tijdens de voorbereiding en in de drie testruns wordt dus in totaal 188GB geschreven en 129GB gelezen. Ook wordt tussen de runs door de ongebruikte capaciteit van de drive minus 10GB volgeschreven met willekeurige data.

De NAS Performance Toolkit schrijft willekeurig gegenereerde data weg, die met een eenvoudig compressiealgoritme nauwelijks gecomprimeerd kan worden. Dit is van belang omdat ssd's met een SandForce-controller datacompressie gebruiken. In de praktijk is veel data van bijvoorbeeld jpeg-afbeeldingen en h.264-video's al zodanig gecomprimeerd dat een SandForce-controller hier geen winst op kan behalen.

Verder biedt de NAS Performance Toolkit de mogelijkheid om traces terug te spelen op 'full speed' of juist met behoud van de originele timing. In het eerste geval wordt de drive maximaal belast en wordt er bij elke gelegenheid een i/o op de drive afgevuurd. Het resultaat is in dat geval meetbaar als doorvoersnelheid in megabytes per seconde. Bij het behoud van de originele timing wordt een request gedaan op hetzelfde moment als bij het opnemen van de trace. Als een drive de timing van de originele trace niet kan bijhouden, wordt getracht om de verloren tijd later in te halen. Als resultaat wordt hier de gemiddelde responstijd van de requests gemeten. De NAS Performance Toolkit geeft ook de gemiddelde responstijden van de afzonderlijke lees- en schrijfrequests. Hiermee kunnen we inzicht krijgen in de relatieve lees- en schrijfprestaties van een drive.

De resultaten van de 23 traces zijn veel te gedetailleerd om in een review behandeld te worden. In plaats daarvan verwerken we de prestaties van de traces in vijf prestatie-indices: Boot StorageMark 2011, Office StorageMark 2011, Workstation StorageMark 2011, Gaming StorageMark 2011 en Data StorageMark 2011. De laatste index bevat enkel data workloads en is voornamelijk bedoeld om de prestaties van externe harde schijven en nas-apparaten te vergelijken.

Net als in de eerdere versies van ons StorageMark-testprotocol staat het indexgetal 100 gelijk aan de prestaties van de Western Digital Raptor WD360GD. Deze eerstegeneratie-Raptor was als eerste 10.000-toeren sata-drive destijds een mijlpaal in de geschiedenis van de harde schijf. Door de indexcijfers op de prestaties van deze drive te baseren, zijn de resultaten van onze nieuwe testsuite in elk geval enigzins vergelijkbaar met oudere tests.

Reacties (32)

Een goede zaak, de nieuwe methode is inderdaad beter. Ik kijk al uit naar de eerstvolgende SSD review.
Inderdaad, ik kijk al uit naar goede SSD benchmarks en reviews, en niet te vergeten de nieuwe generaties SATA/SAS controllers.
Het bericht is geplaatst om 09.00 en jij post om 09.02 dat de methode beter is??? :+
Doe mij ook zo'n cursus speed reading :/

-------------------------

Wat ik voornamelijk goed vind is dat Tweakers nadenkt, en niet de weg van de gebaande paden volgt. Dit soort dingen maakt nu net waarom Tweakers koploper is.

Verder is een goede test zeker belangrijk. Theoretische performance is nuttig om te weten, maar als in de praktijk niets overblijft van een testresultaat heb je er niets aan, en zal je productimago er ook niet beter van worden.

Ik hoop ook dat fabrikanten wellicht dit soort dingen oppikken, en weten dat sites als Tweakers ""weten"" hoeveel procent van de snelheidsclaims hout snijdt.
off topic @Eagle Creek,
Ik had hem ook wel ongeveer in 2 minuten uit hoor... ik weet niet wat er mis mee is?

on topic:
gaat tweakers.net gewoon vanaf nu bezig met de nieuwe methodiek, of doen ze dat al? (er staat .plan dus het zal nog wel gebeuren (of zijn die transcend SDD's ook al hiermee getest?))

ik ben het wat de beloftes van fabrikanten idd wel met Eagle eens. We zullen zien wanneer ze eindelijk reŽle claims ze doen
De Transcend-review is de eerste waarin de nieuwe benchmarks gebruikt worden. We zijn op dit moment volop bezig met het testen van ssd's. Reviews van onder andere de Intel SSD 510 en de OCZ Vertex 3 volgen binnenkort.
Klinkt erg goed. Binnenkort eens kijken of mijn Intel X25-m nog mee kan komen met de beste :)
Goed doordacht en goed uitgelegd; ik ben benieuwd of er nu grotere verschillen gaan ontstaan tussen SSD's en HDD's onderling. Over het algemeen zijn de meeste schijven uit dezelfde prijsklasse vaak erg vergelijkbaar (== saai ;) ). Misschien dat daar nu wat verandering in komt. (lees: realistischer getest dus misschien schijven die beter zijn in bepaalde tests dan andere schijven)
ik wacht wel even totdat ze wat goedkoper worden. Dan maar een HDD..
Goede review!
Overigens bestaat dit systeem uit een H67-moederbord met een cpu uit Intels Sandy Bridge-line-up: de Core i5 2500K.
Voor hoe lang zal dit het referentie systeem blijven?

In de tekst wordt genoemd dat alleen storage getest wordt en niet het systeem (proc + mem etc.). Hoe wordt gegarandeerd dat dit ook echt het geval is? Kan me voorstellen dat een overgeclockte i7 toch net wat betere resultaten neerzet als een i3 bijvoorbeeld.
Dat is dus het hele idee (als ik het goed begrijp): een real-world benchmark doet daadwerkelijk iets met de data. Daarvoor heb je dus een stevig systeem nodig. Deze benchmark is een simulatie van real-world gebruik: de data wordt wel gelezen en geschreven, maar verder niet verwerkt door de processor ofzo. Het lees- en schrijfpatroon wordt opgenomen zeg maar, en wordt daarna nagespeeld door het test-systeem zonder dat er daadwerkelijk op het scherm iets gebeurt.
In theorie zal een systeem met een snellere processor en sneller geheugen lagere responstijden leveren. De hoeveelheid geheugen zal eerder invloed hebben op de prestaties dan de snelheid van de processor. NASPT meet de responstijd in microseconden. De toegangstijd van het geheugen is nog wel een factor 15 lager dan een microseconde, dus het zal niet snel tot meetbare verschillen leiden.

Om te voorkomen dat deze factoren en andere factoren zoals de prestaties van de sata-controller buiten de vergelijking te houden zullen alle harde schijven en ssd's getest worden op hetzelfde moederbord met dezelfde processor.

[Reactie gewijzigd door Femme op 14 maart 2011 11:59]

Meten is weten. Het zou daarom een goed idee zijn om met verschillende stukken hardware te testen wat de invloed is, maar vooral, om die resultaten ook te publiceren. Een test is maar zo betrouwbaar als zijn testmethode. De invloed van de componenten meten, meten waar de bottleneck zit en bij welke waarden een component zijn invloed verliest is ook relevante informatie.
Woei, laat Tweakers de eerste site zijn die nietszeggende low-level benchmarks definitief afschrijft! Ook Anandtech gebruikt nu een vergelijkbare test, nadat ze teleurgesteld waren in de hoeveelheid data waarmee PCMark Vantage benchte.

Het probleem met Anandtech is dat ze enkel opgeven hoe de I/O's gedistribueerd zijn (een percentage 4k, een percentage 16k en een percentage sequentieel, met een gemiddelde QD van x). Met andere woorden: je kunt hun tests niet onafhankelijk bevestigen, wat betekent dat je ze op hun woord moet geloven. Het zou dus helemaal wetenschappelijk correct zijn als jullie op z'n minst jullie NASPT conversie-tool vrijgeven om door anderen te worden gebruikt, of misschien (ondanks de pittige grootte van 80GB) zelfs jullie hele trace. Dan kunnen andere tweakerts de kwaliteit van jullie reviews verifiŽren en verder verbeteren!
Ook als ze de tool vrijgeven is het nog niet 'wetenschappelijk helemaal correct'. Om het wetenschappelijk aan te pakken zou elke meting meerdere keren gedaan moeten worden, gevolgd door enkele statistische tests. Helaas kom je vrijwel geen benchmarks tegen die wat statistiek gebruiken om conclusies te staven. Waarom is mij een raadsel, aangezien van wat extra tijd voor meerdere metingen kost het slechts een eenmalige moeite om de juiste tests te vinden en te implementeren. Wetenschappelijk gezien blijft dit nieuwe protocol dus gewoon natte vinger werk, ook als de tools vrijgegeven worden.
Gaan we oude SSDs (zoals bv. de X-25M G2 160GB) ook zien met de nieuwe test methode? Ik zou graag zien hoe 'oudere' hardware het opneemt tegen de nieuwe, als ik bv. de testresultaten van de nieuwe Intels zet tegenover de 'oude' Intels dan ben ik zwaar teleurgesteld in Intels nieuwe kroost.

Ik zie de 80GB Intel terugkomen, maar de 160GB is een stukkie sneller en is/was heel populair onder de Tweakers. En als jullie dan toch bezig zijn, dan zou een Mtron Mobi leuk zijn als referentie materiaal ;-)
De Intel X25-M G2 80GB hebben we opnieuw getest met de nieuwe benchmark. Deze ssd hebben we zelf in bezit. Ik heb zelf vier Mtron's Mobi 3000 16GB in mijn systeem maar die zijn vanwege de geringe capaciteit wel erg tijdrovend om te testen.

Eind van de week zullen we een review van de Intel SSD 510 publiceren. Hierin zullen resultaten opgenomen zijn van de OCZ Vertex, OCZ Vertex 2, Intel X25-M G2, Plextor PX-256M2S en de Corsair Force F120.
Ik zie ook graag een 160GB X25-M terug in de test.
Vraagje: Is of komt de testtool ook beschikbaar voor het publiek? Ik heb sinds kort een OCZ SSD (Vertex 2 180 GB) in m'n Dell Laptop en ben wel benieuwd naar de performance. ATTO testen geven een positiever resultaat dan dat ik zelf ervaar. Ook al is het nog wel merkbaar sneller dan m'n 'oude' Hitachi 500 GB 7200 toeren HDD.

Edit: typo

[Reactie gewijzigd door freakandel op 14 maart 2011 15:32]

Je kunt NAS Performance Toolkit hier downloaden. Er zitten een paar standaard traces bij.

De traces die wij gebruiken zijn opgenomen op m'n eigen laptop en workstation en leggen gedeeltelijk de directory- en bestandsnamen van mijn systeem bloot. Mede om die reden ga ik ze liever niet verspreiden.
Uiteraard lof voor de "zelfkritiek" , maar blijkbaar zijn jullie je nog steeds niet dusdanig bewust van jullie positie als uitstekende tech-site dat jullie hadden kunnen voorspellen dat er naar die traces gevraagd werden... Hiermee maak je elke vorm van verificatie onmogelijk (verificatie != wantrouwen ) , en je kan niet je eigen benchresultaten vergelijken met T.net benches...
Dat er naar gevraagd wordt verbaast me niet. Onze oude traces voor IPEAK SPT kunnen gedownload worden via de BenchDB, alleen was die benchmark moeilijker om te runnen. Ik wil er met Wilbert over hebben of het zinvol is om de traces beschikbaar te stellen. Directory- en bestandsnamen kunnen gehashed worden. Dan ook zit er nog wel wat werk achter voordat de resultaten nuttig zijn voor de bezoekers. We moeten de BenchDB dan zou gaan verbouwen dat de importtool voor de csv-bestanden van NASPT ook via de front-end werkt. Je wordt anders niet veel wijzer van alle getallen die NASPT uitpoept. In het verleden hebben we gezien dat als je het niet erg makkelijk maakt om een benchmark te runnen de gebruikers het niet gebruiken.
Ik zou wel een benchmarkprogramma willen hebben die gedurende een periode alle lees en schrijfacties bijhoudt en dat vervolgens op SSD's kan herhalen.
Femme, ik ben wel benieuwd of je kunt aantonen dat benchmarks als AS SSD en CrystalDiskMark geen goed algemeen beeld geven van de sequential en random I/O prestaties van SSDs.

Mijn ervaring is namelijk dat goede SSDs vrijwel alleen transfer-capped zijn, en veel benchmarks die heel lichte random I/O doen zijn dat eigenlijk verkapte sequential I/O tests voor SSDs die van een paar seeks meer of minder niet omkijken. Het gevolg is dat SSDs met lagere random I/O snelheden maar hogere sequential write (indilinx bijvoorbeeld) onevenredig goed uit de zogenaamde 'real world' testen komt, terwijl low-level benchmarks een lage random I/O snelheid laten zien en we heel duidelijk het verschil tussen Indilinx en Intel kunnen zien.

Bovendien is een kaal geinstalleerde Windows 7 niet zo gefragmenteerd als in de praktijk met een installatie die na meerdere maanden van gebruik duidelijk langzamer wordt door fragmentatie. Het effect hiervan zal veel minder zijn op SSDs, maar het is maar een argument om aan te tonen dat benchmarken gewoon eigenlijk heel lastig is. Het gevaar is dat de benchmarks je een onvolledig of misleidende conclusie aanpraten, en dus heb ik geleerd heel voorzichtig te zijn met het maken van conclusies uit enkele benchmarks.

Toch kijk ik erg uit naar je volgende artikelen. :)
AS-SSD en CrystalDiskMark lijken me prima benchmarks om de sequentiŽle doorvoersnelheid en de random I/O-prestaties te meten. Het probleem met die benchmarks is dat er in de real world geen I/O wordt uitgevoerd die langdurig enkel sequentieel of willekeurig is.

Dat in de praktijk de sequentiŽle doorvoer van een ssd van grotere invloed is dan de random I/O-performance vind ik niet gek. In een desktopomgeving vinden er geen grote hoeveelheid 4K random I/O's plaats, al helemaal niet bij de hoge queue depths waar sommige benchmarks mee testen. Dit is ook wel te zien in de transfergrootte in onze traces. Die is gemiddeld 45KB. Het percentage sequentiŽle I/O verschilt heel erg per trace maar is vaak niet groter dan 20%.

Bestandsfragmentatie heeft inderdaad geen invloed in onze benchmarks. Alle bestanden worden netjes achter elkaar geschreven. Het is niet eenvoudig om bestandsfragmentatie na te bootsen op een wijze die repetitief is.

Een ander zwak punt is dat de data die binnen een trace wordt opgevraagd bij de meeste traces niet verder dan 6GB uit elkaar zal liggen. NASPT reconstrueert alleen bestanden die tijdens de trace worden benaderd. Harde schijven doen daardoor geen full stroke seeks. In de praktijk denk ik dat de zoekafstand bij harde schijven van meerdere terabytes ook wel zal meevallen. Bij een 2TB harde schijf waarvan de toegangstijd in een low-level benchtool zoals IOMeter wordt getest zal de gemiddelde zoekafstand 1TB zijn. De gemiddelde 7200 toeren drive heeft daar ongeveer 8,5ms voor nodig plus 4,2ms voor de rotatie. In de praktijk lijkt me dat het zoekbereik meestal minder is dan 50GB (alle data voor het besturingssysteem en de applicaties die vlak na installatie van het OS zijn geÔnstalleerd zullen dichtbij elkaar staan). In theorie blijft er van de zoektijd dan nog maar ongeveer 0,4ms over als de zoekafstand 50GB is. Daar komt nog een vaste gemiddelde omwentelingswachttijd van 4,2ms bij. De invloed van de zoektijd is dan al een stuk kleiner en verschilt minder ten opzichte van de situatie in onze benchmarks.
Is deze benchmark/dataset ook te verkrijgen ergens? Zij het als download, zij het op hdd, zij het op wat blue ray discs? Niet dat ik ze zelf zou willen hebben, maar op die manier kunnen derden in ieder geval de resultaten (prberen te) reproduceeren.

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Tablets Luchtvaart Samsung Crash Smartphones Microsoft Apple Games Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013