OCZ Octane 1.13 Firmware Update: Förbättrar 4KB Random Write Performance

Det enda som OCZ har saknat i så många år är äntligen en av dess häftklamrar: fokus. Samma företag som sysslade med allt från hjärnmöss till Gör-det-själv-anteckningsböcker är nu nästan uteslutande ett SSD-företag som säljer strömförsörjning på sidan. OCZ:s förkärlek för att aggressivt prova nya saker har dock inte försvunnit. Som SSD-tillverkare är OCZ för närvarande eller kommer inom en snar framtid att leverera enheter baserade på kontroller från tre olika leverantörer – var och en med sina egna styrkor. OCZ:s relation med SandForce fortsätter och Vertex 3 är fortfarande OCZ:s högst presterande erbjudande. Ett nyligen genomfört partnerskap med Marvell ger OCZ tidig erfarenhet av inbyggda PCIe-baserade SSD-enheter, erfarenhet som är extremt viktig när industrin går mot en ny PCIe-baserad gränssnittsstandard för SSD-enheter (SATA Express). Äntligen finns det OCZs egen kontroller, Indilinx Everest, som den snabbt bygger fart bakom. Det är uppenbarligen i OCZ:s bästa intresse att ha sina egna kontroller i huvuddelen av de enheter som den gör, men man bygger inte bara en bättre kontroller än alla andra vid första försöket.

Everest har ett löfte. Dess övergripande prestanda är konkurrenskraftig med SandForce-baserade lösningar, men arkitekturen har verkliga begränsningar när det kommer till långsiktig slumpmässig skrivprestanda. I mina egna interna tester mätte jag en värsta skrivförstärkning på över 50x i högt ködjup 4KB slumpmässiga skrivningar. Diagrammet nedan ger dig en uppfattning om uppskattad skrivförstärkning för ett antal kontroller i en mycket slumpmässig arbetsbelastning:

I våra recensioner av OCZ:s Everest-baserade Octane SSD:er nämnde jag att den höga skrivförstärkningen egentligen bara är ett problem för företagsarbetsbelastningar. Eftersom OCZ har höga ambitioner för att vara en spelare i företags-SSD-utrymmet är det tydligt att arbete behövde göras för att göra Everest företagsvärt.

På CES visade OCZ mig Everest 2, som den hävdade skulle få skrivförstärkning ner till cirka 10x. OCZ skulle inte gå in på detaljer annat än att säga att det skulle komma genom en kombination av firmware- och kontrollerförbättringar. Med Everest 2 som kommer ut i sommar, tänkte jag att vi inte skulle se mycket framsteg på Everest 1-fronten under tiden. Jag hade fel.

För några veckor sedan släppte OCZ en firmwareuppdatering för sina Octane-enheter som lovade en betydande ökning av 4KB slumpmässig skrivprestanda. Octanes ursprungliga 4KB slumpmässiga skrivprestanda var inte så hög men den var tillräckligt bra för de flesta klienters arbetsbelastningar. Det man ska tänka på när det kommer till slumpmässig prestanda är att även de bästa hårddiskarna bara är bra för ett par hundra slumpmässiga IO:er per sekund. Varje klientarbetsbelastning som krävde nära hundra tusen IOPS skulle helt enkelt inte fungera på alla hårddiskbaserade system. Att kunna leverera runt 20 – 40K IOPS verkar istället vara den bästa platsen för klient-SSD:er tills vi flyttar till en hel-SSD-värld och utvecklare verkligen kan börja dra nytta av alla tillgängliga IOPS på dessa enheter.

En fördubbling av slumpmässig IO-prestanda skulle säkert få benchmarks att se bättre ut, men jag misstänker att den här nya firmwaren har mer att göra med Everest 2 och förbereder sig för ett inträde på företagsmarknaden snarare än att förbättra klientens Octane-upplevelse. Om du tittar på uppskattad skrivförstärkning när du kör en mycket slumpmässig arbetsbelastning, har den nya firmwaren en enorm inverkan på befintliga Octane-enheter. Även om det inte är riktigt så lågt som jag skulle vilja, är det klart att den nya firmwaren är bättre om du kör ett högt ködjup, mycket slumpmässig arbetsbelastning. Precis sånt som en företagskund skulle leta efter.

Du kan uppdatera Octanes firmware från Windows med hjälp av OCZ:s verktygslåda, förutsatt att det inte är ditt operativsystem/startenhet. Det finns inget stöd för alternativa flash-rutter för närvarande, även om OCZ säger att en Linux-baserad uppdatering kommer.

OCZ börjar med att varna dig om att firmware 1.13 är en destruktiv blixt. Det finns ett antal anledningar till varför en SSD-uppdatering skulle bli av med all din data, allt från slarvig kodning hela vägen upp till betydande förändringar i firmwarearkitektur. Om du ändrar hur LBA mappas till NAND-sidor så har du ett intressant problem. Rensar du de befintliga mappningstabellerna och börjar från början, vilket garanterar bästa möjliga prestanda, eller försöker du långsamt migrera de gamla mappningarna till den nya layouten, bevara data men potentiellt minska prestandan avsevärt? Användare av den ursprungliga X25-M kan vara bekanta med effekterna av den senare. Om du hade mycket data på din X25-M och körde den första stora uppdateringen, skulle du ha märkt mycket högre latens IO när enheten försökte omorganisera delar av sig själv med varje skrivning. Om OCZ ändrade balansen i sin hybridsida/block-mappade arkitektur lite, och mappade fler LBA:er direkt till NAND-sidor, var det troligtvis lättare att bara bygga om tabellerna snarare än att ta itu med det extra arbetet med att migrera arkitekturer med livedata.

OCZ:s verktygslåda försöker avgöra om din Octane är en startenhet eller inte genom att titta på enhetens ID-nummer som räknas upp av ditt system. Teorin är att enhet 0 ska vara din startenhet, medan allt annat är förbrukningsbart. Detta är uppenbarligen en felaktig teori eftersom diskuppräkning beror på mer än det enkla valet av SATA-port. Det är möjligt att få en sekundär enhet att detekteras först och därmed verkar vara enhet 0 till Windows. Om detta händer, och din sekundära enhet räknas upp som enhet 0, tillåter inte OCZ:s verktygslåda dig att uppdatera den fasta programvaran. Det enklaste sättet att komma runt denna begränsning är att helt enkelt starta upp din enhet utan en SATA-kabel ansluten (låt ström vara ansluten) och bara koppla in enheten efter att du är i Windows. Uppenbarligen har notebook-användare otur eftersom den här metoden inte kommer att fungera, även om du kan försöka hotplugga din enhet medan din bärbara dator är på (du kan teoretiskt skada din enhet på detta sätt, fortsätt på egen risk). Även om detta tar dig runt begränsningen för enhet 0, kommer verktygslådan inte att se din enhet om du har Intels RST-drivrutiner laddade – du måste använda Microsofts AHCI-drivrutiner. Jag förstår att OCZ inte har den mjukvaruingenjörspersonal som Intel och Samsung har, men båda dessa företag låter sina verktygslådor fungera med Intels drivrutiner installerade och som en konkurrent måste OCZ erbjuda en liknande användarupplevelse.

Med alla krav uppfyllda och Octane som dyker upp som enhet 1, kunde jag uppgradera firmware. OCZ ändrade sitt numreringsschema för firmware, denna nya uppdatering är nu version 1.13 jämfört med 1463, dess omedelbara föregångare. Mitt i uppdateringen får du detta meddelande:

Ah ha! OCZ ändrar sin LBA-mappningsalgoritm. Efter att ha väntat ett par minuter på att tabellerna ska avsluta kartläggningen måste du stänga av din maskin (en mjuk återställning fungerar aldrig för mig med Octane och firmwareuppdateringar) och slå på den igen. Efter allt detta är Octane nu uppe i 1,13 och jag kunde börja testa.

Med tanke på att uppdateringens fokus var att adressera slumpmässig IO med små block är det troligt att OCZ flyttade till en mer granulär mappningsalgoritm där varje LBA nu mappar antingen direkt till en enda NAND-sida eller en mindre grupp av sidor. Ett annat alternativ skulle vara om OCZ använder en hybridsida/blockmappningsalgoritm där endast en procentandel av LBA:er är sidmappade medan resten mappas till block. Om så är fallet kunde OCZ helt enkelt ha justerat balansen mellan sid- och blockmappade LBA:er. Det sista alternativet är en kombination av de två möjligheterna.

Med tanke på hur Octane har massor av DRAM ombord (512MB) borde kontrollern inte ha några problem med att upprätthålla sekventiell prestanda även med fler mappningsposter att hålla reda på. Låt oss titta på siffrorna för att se hur den nya firmwaren förändrar saker och ting.

Testet