Testresultat: Olika QD och paketstorlek
Som vanligt så tittar vi också på hur enheterna beter sig när vi testar den vid olika QD. QD betyder ”Queue Depth” och i praktiken så skickar man flera förfrågningar till enheten, parallellt. Vi tog därför och körde ett antal test i IOMeter för att se hur prestandan utvecklade sig när vi ställde in en högre QD. De allra flesta SSD-enheter presterar som bäst vid QD32 (ibland högre) men belastning hos vanliga datoranvändare överstiger sällan QD4 och de allra flesta stannar vid QD1. Vi tog därför vårt 4K Random write-test och körde det i olika QD för att se hur enheten reagerar.
Vid ren slumpmässig skrivning så ser vi att MX200 tar ett klart övertag över BX100. Vid QD1 så är MX200 också betydligt snabbare än MX100 men efter det så ligger de båda MX-enheterna på ungefär samma nivå. BX100 är överlag den sämsta av dessa enheter.
Vid slumpämässig läsning så presterar enheterna väldigt lika men MX200 är fortfarande den snabbare av de två. BX100 slåss tappert mot OCZ Arc 100.
Sekventiell skrivprestanda är också väldigt lika mellan de två modellerna. Alla MLC-baserade enheter presterar ungefär lika bra. Det är egentligen bara den TLC-baserade Sandisk Ultra 2 som presterar sämre.
Vid sekventiell läsning så är det istället BX100 som tar kommandot, och det ganska rejält. Silicon Motions kontrollerkrets har tidigare visat sig vara riktigt snabb på läsprestanda och det bekräftas här av våra tester.
Till er som äger Crucial diskar och har stora prestandaproblem i Windows! Det finns en lösning. Har skrivit en guide på Crucials forum.
http://forum.crucial.com/t5/Crucial-SSDs/Solution-Crucial-V4-runs-fast-in-linux-Benchmarks-Manual/td-p/162462
Sammanfattningsvis är lösningen: linux, ext4 och ext4-flaggan ‘barrier=0’. Barrier kommer leda till en “fsync operation relaxation”, vilket Crucials Micron kontroller är dålig på att utföra.
You’re welcome!