Tweakers.net vernieuwt testprotocol voor ssd's

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)

[aTmosh]

Een goede ontwikkeling, maar:

1. hoe houd je rekening met SSD's die een flinke overprovisioning hebben zoals de Vertex LE of Vertex 2 100 GB (128 GiB -> 28% OP)?

2. sommige SSD's hebben meerdere snelheden, voor Sandforce geldt b.v. dat er een 'verse' snelheid is die af fabriek (of na een secure erase) reikt totdat alle flash cellen één keer zijn beschreven (>128 GiB gecomprimeerde data voor 100 GB modellen met 28% OP), een ca. 35% tragere 'gebruikte' snelheid en een nog lagere 'overgebruikte' snelheid waarbij de firmware de rem erop zet om levensduur binnen de garantieperiode te kunnen garanderen. Dit laatste hangt weer af van hoe snel je een niet nader gespecificeerde hoeveelheid (oncomprimeerbare) data achter elkaar schrijft - en iets waar de lagere capaciteiten eerder last van zullen hebben.

3. voor controllers die aan compressie doen zullen je traces mogelijk nooit werkelijk de volledige fysieke capaciteit beschrijven waardoor de verse snelheid behouden blijft (stel dat die 188 GB tot een derde te comprimeren is (63 GB), dan zal een SSD met 28 GB overprovisioning slechts voor het verschil (63-28=35 GB) op de 'gebruikte' snelheid draaien, wat een vertekend beeld geeft van normaal gebruik, waarbij de gebruiker na het schrijven van effectief 128 GiB nooit meer de verse snelheid zal halen (op een secure erase na, wat je zelden gaat doen).

Daarom is het misschien een idee om eerst de volledige capaciteit (incl. OP) een keer te beschrijven (met verder oncomprimeerbare data) voordat aan testen wordt begonnen. Nadeel hiervan is wel dat het weer afhankelijk is van controller en firmware of en hoe snel daarna b.v. garbage collection wordt uitgevoerd (dit zou je weer kunnen minimaliseren door met low level tools te schrijven zodat zowel filesystem bitmap snooping als trim niet werken).

[Reactie gewijzigd door aTmosh op 23 juli 2024 05:20]

[Femme]

1. hoe houd je rekening met SSD's die een flinke overprovisioning hebben zoals de Vertex LE of Vertex 2 100 GB (128 GiB -> 28% OP)?

Deze ssd's zullen waarschijnlijk geen performance-degradatie hebben, zoals dat ook in de praktijk het geval is.

2. sommige SSD's hebben meerdere snelheden, voor Sandforce geldt b.v. dat er een 'verse' snelheid is die af fabriek (of na een secure erase) reikt totdat alle flash cellen één keer zijn beschreven (>128 GiB gecomprimeerde data voor 100 GB modellen met 28% OP), een ca. 35% tragere 'gebruikte' snelheid en een nog lagere 'overgebruikte' snelheid waarbij de firmware de rem erop zet om levensduur binnen de garantieperiode te kunnen garanderen. Dit laatste hangt weer af van hoe snel je een niet nader gespecificeerde hoeveelheid (oncomprimeerbare) data achter elkaar schrijft - en iets waar de lagere capaciteiten eerder last van zullen hebben.

Het volschrijven van een ssd voordat we met de tests beginnen vind ik geen realistische manier van testen. In de praktijk stoppen mensen een nieuwe ssd in hun systeem en installeren ze er hun OS op. De beschreven capaciteit op de ssd zal langzaam toenemen. Iemand die na een jaar nog maar tweederde van de capaciteit gebruikt zal een ssd hebben die ruim voldoende vrije geheugenblokken heeft en goed zal presteren.

Wat we nu doen is in drie stappen op de gebruikte capaciteit verhogen tot er nog maar 10GB over is. Voor de laatste run is de totale capaciteit plus ongeveer 70GB aan data naar de ssd geschreven en wordt er in de derde run nog eens 37GB naar geschreven. De meeste moderne ssd's (ook de OCZ Vertex 2 met een SandForce SF-1200-controller) presteren dan nog prima ondanks de 37GB aan schrijfacties die we per run op de ssd's afvuren. Performance-degradatie is niet echt een issue meer.

3. voor controllers die aan compressie doen zullen je traces mogelijk nooit werkelijk de volledige fysieke capaciteit beschrijven waardoor de verse snelheid behouden blijft (stel dat die 188 GB tot een derde te comprimeren is (63 GB), dan zal een SSD met 28 GB overprovisioning slechts voor het verschil (63-28=35 GB) op de 'gebruikte' snelheid draaien, wat een vertekend beeld geeft van normaal gebruik, waarbij de gebruiker na het schrijven van effectief 128 GiB nooit meer de verse snelheid zal halen (op een secure erase na, wat je zelden gaat doen).

NAS Performance Toolkit genereert willekeurige data die door 7zip in zip-formaat nauwelijks gecomprimeerd kan worden maar op een of andere manier wel goed in het eigen 7zip-formaat. Het is aannemelijk dat de SandForce-controllers niet on the fly even efficient kunnen comprimeren als 7zip waardoor SandForce-controllers nauwelijks zullen profiteren van datacompressie en de-dupe. In de praktijk bevatten veel bestanden, bijvoorbeeld foto's en video's, gecomprimeerde data. Schrijfacties op de pagefile en de scratchfile in Photoshop zijn waarschijnlijk wel goed comprimeerbaar. Helaas kunnen wij dat effect niet testen omdat we vastzitten aan de data generator van NASPT die voor elk type bestand hetzelfde werkt.

[aTmosh]

Het volschrijven van een ssd voordat we met de tests beginnen vind ik geen realistische manier van testen.

Het is niet ideaal maar als je het niet doet zul je niet de prestaties meten die gebruikers op den duur ervaren. Als je je bewust bent van de feiten vind ik het onverantwoord om het vertekende beeld te laten bestaan, net als dat je geen ATTO meer kan/mag gebruiken als je weet dat het snelheden laat zien die in de werkelijkheid niet gehaald zullen worden i.c.m. comprimerende controllers.

Iemand die na een jaar nog maar tweederde van de capaciteit gebruikt zal een ssd hebben die ruim voldoende vrije geheugenblokken heeft en goed zal presteren.

Zo iemand is geen typisch gebruiker (je kan ook zeggen dat een typische gebruiker nog geen dure SSD koopt) maar waarschijnlijk iemand die er een HDD naast heeft voor opslag en de SSD alleen voor boot/OS gebruikt. Het is ook niet een laptopgebruiker (1 bay), of gamer, of downloader. Als je om de maand een redelijk nieuwe game installeert (zeg 2x DVD aan data) en elke maand één blu-ray film downloadt/uitpakt (2x20 GB) ben je er in iets meer dan twee maanden doorheen voor een 100 GB model. Let wel: met trim krijg je geen 'verse' blokken terug bij Sandforce omdat het voor maximale levensduur gaat en 'JIT' blokken vrijmaakt (trims worden niet direct uitgevoerd, alleen ack op gegeven!). Gewiste blokken onstaan alleen in het geval dat oncomprimeerbare data vervangen wordt door comprimeerbare waardoor tijdens consolidatie van sectoren erase blocks vrijkomen én er OP pressure bestaat, dus maximaal tot 28% (7% voor 'E' modellen), danwel volledig met een secure erase. Maar dit is alleemaal tijdelijk.

En al duurt het anderhalf jaar voordat een gebruiker over de drempel gaat zal hij vanaf dat moment een merkbare vertraging ondervinden wat betreft schrijfacties - iets wat niet uit de review blijkt. Ik vermoed dat niet iedereen een prijzige SSD elke anderhalf jaar vervangt (of om de haverklap secure erased).

De meeste moderne ssd's (ook de OCZ Vertex 2 met een SandForce SF-1200-controller) presteren dan nog prima ondanks de 37GB aan schrijfacties die we per run op de ssd's afvuren.

Dat zal welhaast moeten komen omdat de data nog te comprimeren is of in zijn totaliteit niet over de 128 GiB reikt (voor een 100 GB Vertex 2). Het is een keiharde feit dat de (oncomprimeerbare sequentiële) schrijfsnelheid van 133 MB/s naar 85 MB/s omlaaggaat als je meer dan 128 GiB hebt geschreven, en dit is simpel te testen met een dd if=/dev/urandom of=/dev/shm/foo bs=1M count=1 en een for loop om de SSD zeg 1,5x vol te schrijven met deze data. Voor de derde snelheidstrap ('hammered state') heeft OCZ staff gezegd dat zij bij het bakken van de firmware kunnen bepalen wanneer deze optreedt (snelheid afgezet tegen flash levensduur variabele). Verder geeft men er geen ruchtbaarheid aan maar ook in dagelijks gebruik kan je hier tegenaanlopen. Dit zal een steeds groter probleem worden met afnemende P/E cycles van steeds kleinere procesgroottes.

Performance-degradatie is niet echt een issue meer.

Je hoeft maar naar de vele threads op het OCZ forum te kijken die dit tegenspreken (standaardantwoord luidt dan "maar.. je hebt te veel gebenchmarked!"), pas de Vertex 3 (SF-2xxx) schijnt hier minder last van te hebben.

Het komt er op neer dat vanwege een steeds intelligentere en adaptievere firmware je niet meer op recht toe recht aan traces kan vertrouwen, tot en met de mogelijkheid dat deze zich tijdelijk aan benchmarks aanpast. Je zou zo'n test eigenlijk met trending uit moeten breiden, d.w.z. blijf de benchmarks doen tijdens gewoon gebruik danwel baseer de benchmark op metingen tijdens gewoon gebruik.

[Femme]

Het is niet ideaal maar als je het niet doet zul je niet de prestaties meten die gebruikers op den duur ervaren. Als je je bewust bent van de feiten vind ik het onverantwoord om het vertekende beeld te laten bestaan, net als dat je geen ATTO meer kan/mag gebruiken als je weet dat het snelheden laat zien die in de werkelijkheid niet gehaald zullen worden i.c.m. comprimerende controllers.

Wij draaien drie runs waarbij de ssd in de eerste run met 80GB aan data wordt volgeschreven. Voor het begin van de tweede run wordt de helft van de totale capaciteit minus 90.000MB (de partitie waarop getest wordt en waarop die 80GB aan data staat) volgeschreven met random data. Vervolgens wordt in de derde run ook nog de tweede helft volgeschreven. Op de partitie van 90.000MB is dan nog ongeveer 10GB vrij en voor de rest staat de ssd vol. Tijdens de runs zelf wordt er voor 37GB aan data naar de ssd's geschreven. De prestaties die we in de reviews rapporteren zijn de gemiddelden van deze drie runs.

Om inzicht te krijgen in performance degradatie draaien we eventueel ook nog een vierde run waarin er nog maar 4GB vrij is op de ssd. Die 4GB is zo ongeveer het minimum dat nodig is om de runs te kunnen draaien. Er worden tijdens de runs namelijk nieuwe bestanden op de drives geschreven.

Ik vind dat we hiermee een aardig realistische test doen van performance degradatie op ssd's. Na drie runs is er door de trace-based benchmarks al 220GB geschreven op een 120GB-ssd. Dat is nog exclusief schrijfacties van HDTune, IOMeter en PCMark Vantage. Na die tests formatteren we de drive en is het aan de drive om iets te doen met de trim-commando's die hij ontvangt bij het formatteren.

Zo iemand is geen typisch gebruiker (je kan ook zeggen dat een typische gebruiker nog geen dure SSD koopt) maar waarschijnlijk iemand die er een HDD naast heeft voor opslag en de SSD alleen voor boot/OS gebruikt. Het is ook niet een laptopgebruiker (1 bay), of gamer, of downloader. Als je om de maand een redelijk nieuwe game installeert (zeg 2x DVD aan data) en elke maand één blu-ray film downloadt/uitpakt (2x20 GB) ben je er in iets meer dan twee maanden doorheen voor een 100 GB model.

Ik heb al ruim een jaar een 120GB ssd in mijn laptop en ik heb nog 40GB vrij. Mijn MacBook Air heeft na 3,5 maand nog bijna 80GB vrij. Niet iedereen hamstert films en games. Mensen die een systeem gebruiken om er op te browsen, emailen, tekstverwerken, developen en te photoshoppen kunnen lang vooruit met een niet al te krappe ssd van bijv. 120GB. De hardcore downloaders doen dat naar harde schijven omdat de prijs/capaciteit-verhouding van ssd's ongunstig is.

Let wel: met trim krijg je geen 'verse' blokken terug bij Sandforce omdat het voor maximale levensduur gaat en 'JIT' blokken vrijmaakt (trims worden niet direct uitgevoerd, alleen ack op gegeven!).

Trim zorgt er wel voor dat een ssd over meer dan voldoende vrije geheugenblokken kan beschikken. Dat er een erase gedaan moet worden voordat ze beschreven kunnen worden is veel minder problematisch dan het uitvoeren van een noodzakelijke read-erase-program-cyclus op geheugenblokken met gedeeltelijk valide gegevens. Dit probleem hebben moderne ssd's niet.

Dat zal welhaast moeten komen omdat de data nog te comprimeren is of in zijn totaliteit niet over de 128 GiB reikt (voor een 100 GB Vertex 2).

Op een ssd die niet vooraf een erase doet van geheugenblokken die zijn vrijgekomen na een trim-actie of deel uitmaken van de reservecapaciteit heb je onderscheid tussen twee niveaus van degradatie. De eerste treedt op als alle geheugenpages eenmaal beschreven zijn. De tweede als er onvoldoende volledig vrije geheugenblokken (blokken waar data in gebruik is) beschikbaar zijn waardoor de ssd genoodzaakt is om te schrijven naar gefragmenteerde geheugenblokken die gedeeltelijk valide gegevens bevatten. Dat laatste levert een zware performance-penalty op omdat eerst de nog valide gegevens in een geheugenblokken ingelezen moeten worden, het geheugenblok vervolgens gewist moet worden en dan pas beschreven kan worden, waarbij er effectief dus maar een deel van de inhoud verandert. Dit probleem doet zich bij moderne ssd's niet meer voor gezien de marginale of geheel afwezigde performance-degradatie in onze benchmarks.

Dat de schrijfsnelheid bij een SandForce SF-1200 afneemt als het geheugen eenmaal volledig beschreven is, is iets waar je je als gebruiker niet druk om moet gaan maken. Je doet er niets tegen. Na het installeren van het besturingssysteem, wat applicaties en twee weken van regelmatig gebruik kun je op een 120GB-ssd al zover zijn. Wij schrijven al zoveel data naar de ssd's dat deze afname van schrijfprestaties niet of nauwelijks meetbaar is. Wel zie je dat de schrijfprestaties van ssd's met de SandForce SF-1200 ver achterblijven bij ssd's met een Marvell 88SS9174-controller, die kennelijk een wat pro-actievere garbage collection doen of hogere doorvoersnelheden hebben als er een erase moet plaatsvinden voordat een blok beschreven kan worden.

In alle moderne ssd's die we tot nu toe hebben getest is performance-degradatie geen issue meer, zelfs als de ssd tot 4GB van zijn maximum capaciteit wordt gevuld en er dan grote bestanden op geschreven worden. Kennelijk is de gangbare overcapaciteit van zeven procent in combinatie voldoende om problemen te tekorten van vrije geheugenblokken te ondervangen.

[Reactie gewijzigd door Femme op 23 juli 2024 05:20]

[aTmosh]

Wij draaien drie runs waarbij de ssd in de eerste run met 80GB aan data wordt volgeschreven.

Als dit te comprimeren is moet je er van uitgaan dat SF dat ook kan omdat er geen reden is om aan te nemen dat zij een of meerdere algoritmes niet in hardware kunnen implementeren.

Als tijdens de drie runs datasets worden hergebruikt moet je er van uitgaan dat SF deze kan dedupliceren.

Aangezien de datasets niet openbaar zijn kan dit niet onafhankelijk geverifieerd worden.

schrijfacties van HDTune, IOMeter en PCMark Vantage

ATTO, HDTune en standaard IOMeter schrijven nullen, PCMark Vantage schrijft grotendeels comprimeerbare data. Nullen zijn volledig weg te comprimeren en meet je de SATA bandbreedte i.p.v. de SSD. Gezien je in werkelijkheid nauwelijks flash cellen beschrijft zal een format/trim ook weinig effect hebben, je meet nog steeds verse snelheid voor overige schrijfacties.

Ik heb al ruim een jaar een 120GB ssd in mijn laptop en ik heb nog 40GB vrij.

Mocht het om Sandforce gebaseerde SSD's gaan dan gaat het er niet om hoeveel ruimte op bestandssysteemniveau vrij is omdat de SF-12xx controller fs agnostisch is. Het gaat er om hoeveel data cumulatief geschreven is (ook naar dezelfde LBA's) omdat SF lazy trim doet (en dat alleen over OP, dus afhankelijk van model over 7 of 28%, en dat alleen bij OP pressure, dus als je op dat moment sequentieel oncomprimeerde data schrijft zal de snelheid verder kelderen - 'hammered state').

Met andere woorden als je 80 GB in gebruik hebt (waarvan misschien een fractie aan fysiek flash vanwege compressie) heb je misschien toch ruim de totale capaciteit al een keer geschreven. Van deze hoeveelheid zal alles behalve 80 GB (min compressie) getrimd zijn (MacOS doet volgende versie pas trim BTW). Nogmaals, bij SF betekent een trim niet dat er werkelijk gewist wordt, maar dat de controller de trim ontvangt en bevestigt, vervolgens wordt volgens een black box algoritme werkelijk aan consolidatie/GC gedaan, maar omdat de controller uit levensduur overwegingen zo weinig mogelijk wist zal maximaal 7 danwel 28% van de totale capaciteit werkelijk vrijgehouden worden. Maximaal omdat SF geen details geeft over hoe dat precies werkt (kan dus minder zijn of over langere periode tot stand komen), maar het vermoeden is dat het zich afstemt op gebruikspatroon. Met als gevolg dat als deze een keer een piek vertoont je flink snelheid in kan leveren omdat er geen verse blokken meer zijn. Zelfde geldt voor consolidatie en data shuffling i.v.m. wear leveling.

Hoe dan ook, er gebeurt zo veel meer onder de motorkap dan dat je met de huidige test rekening lijkt te houden dat de gebruikerservaring compleet anders kan zijn dan een hierop gebaseerde review doet vermoeden.

Voor de Vertex 2 (Intel AHCI driver, 34 nm, 32 Gbit chips, 100 GB capaciteit; 25 nm is 10-30% trager, 64 Gbit chips zijn bij lagere capaciteiten tot 50% trager) zijn er een drietal vuistregels: haal je meer dan 133 MB/s schrijvend, dan is je data comprimeerbaar. Haal je minder dan 85 MB/s, dan heeft de firmware de rem erop gezet i.v.m. erase before write danwel levensduur throttle. Zit je er tussenin dan heb je nog verse blokken over en/of je data is comprimeerbaar.

Dat de schrijfsnelheid bij een SandForce SF-1200 afneemt als het geheugen eenmaal volledig beschreven is, is iets waar je je als gebruiker niet druk om moet gaan maken.

Tenzij dat niet in de review terugkomt natuurlijk

Wij schrijven al zoveel data naar de ssd's dat deze afname van schrijfprestaties niet of nauwelijks meetbaar is.

Deze plotselinge afname moet duidelijk merkbaar zijn tenzij je dataset ruim comprimeerbaar is of de benchmark dergelijke pieken en dalen vertoont dat het niet te duiden is, maar je zou op zijn minst een gedaalde gemiddelde moeten zien voor en na (worst case 35% voor oncomprimeerbare data, b.v. ATTO daarentegen zal niet afnemen omdat de SATA bus de bottleneck is).

In alle moderne ssd's die we tot nu toe hebben getest is performance-degradatie geen issue meer

Dit moet flink gekwalificeerd worden, omdat het ook in dagelijkse gebruiksscenario's niet waar hoeft te zijn (filmbestanden kopiëren b.v.). Ook zal iedereen die niet over trim beschikt (Windows XP b.v.) dit vrij snel kunnen reproduceren.

[Anoniem: 15758]

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.

[Femme]

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.

[Cergorach]

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 ;-)

[Femme]

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.

[Red hot]

Ik zie ook graag een 160GB X25-M terug in de test.

[freakandel]

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 23 juli 2024 05:20]

[Femme]

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.

[afraca]

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

[Femme]

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.

[N11]

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.

[Femme]

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 23 juli 2024 05:20]

[Punkie]

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.

[Plague]

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.

[mux]

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!

[narotic]

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.

[Pixeltje]

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)

[bredend]

Ik zou wel een benchmarkprogramma willen hebben die gedurende een periode alle lees en schrijfacties bijhoudt en dat vervolgens op SSD's kan herhalen.

[ArmouredSPony]

Een goede zaak, de nieuwe methode is inderdaad beter. Ik kijk al uit naar de eerstvolgende SSD review.

[Eagle Creek]

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.

[cedal]

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

[Femme]

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.

[Fauna]

Inderdaad, ik kijk al uit naar goede SSD benchmarks en reviews, en niet te vergeten de nieuwe generaties SATA/SAS controllers.

[et36s]

Klinkt erg goed. Binnenkort eens kijken of mijn Intel X25-m nog mee kan komen met de beste

[TvMoorsel]

ik wacht wel even totdat ze wat goedkoper worden. Dan maar een HDD..
Goede review!