För två år sedan släppte Samsung bomben genom att släppa den första TLC NAND-baserade SSD:n. Jag minns fortfarande tydligt Anands reaktion när jag berättade för honom om SSD 840. Jag var i Korea för lanseringsevenemanget och satt i ett pressrum där Samsung höll tillkännagivandet. Samsung hade bara provat oss och alla andra med 840 Pro, så 840 och dess inälvor hade förblivit som ett mysterium. Så fort Samsung lyfte på gardinen för 840-specifikationerna, skickade jag ett meddelande till Anand som berättade för honom att den var TLC NAND-baserad. Anledningen till att jag fortfarande minns detta så tydligt är för att jag var tvungen att säga till Anand tre gånger att “Ja, jag är helt säker och skojar inte” innan han tog mitt ord.
I nästan två år var Samsung den enda tillverkaren med en SSD som använde TLC NAND. De flesta av de andra tillverkarna har pratat om TLC SSD-enheter på ett eller annat sätt, men ingen har kommit på något detaljvärdigt… förrän nu. För en månad sedan intog SanDisk scenen och presenterade sin Ultra II, företagets första TLC SSD och den första TLC SSD som inte är från Samsung. Självklart finns det mycket att diskutera, men låt oss börja med en snabb översikt över TLC och marknadslandskapet.
Det finns en mängd olika anledningar till Samsungs försprång i TLC-spelet. Samsung är den enda kund-SSD-tillverkaren med en helt integrerad affärsmodell: allt inuti Samsung SSD är designat och tillverkat av Samsung. Det är unikt i branschen eftersom även om sådana som SanDisk och Micron/Crucial tillverkar NAND och utvecklar sin egen anpassade firmware, så förlitar de sig på Marvells kontroller för sina klientenheter. Tredje parts kisel skapar alltid vissa begränsningar eftersom det är designat utifrån behoven hos flera kunder, medan internt kisel kan designas för en specifik applikation och firmware-arkitektur.
Dessutom är Samsung den enda NAND-tillverkaren förutom SK Hynix som inte ingår i ett NAND-samriskföretag. Utan en partner har Samsung full frihet att ägna så mycket (eller så lite) resurser och fantastiskt utrymme till TLC-utveckling och produktion som behövs, medan SanDisk måste samordna med Toshiba för att säkerställa att båda företagen är nöjda med utvecklings- och produktionsstrategin.
Vad jag har hört har de två stora problemen med TLC varit sen produktionsuppgång och låg volym. Med andra ord, det har tagit ytterligare två eller tre fjärdedelar för TLC NAND att bli tillräckligt mogen för SSD:er jämfört med MLC NAND vid samma nod, vilket innebär att en ny MLC-nod redan samplar och kommer att vara tillgänglig för SSD-användning inom ett par av fjärdedelar. Det har helt enkelt varit vettigt att vänta på att den mindre och mer kostnadseffektiva MLC-noden blir tillgänglig istället för att fokusera utvecklingsresurser på en TLC SSD som skulle bli föråldrad inom några månader.
SanDisk och Toshiba verkar dock ha reviderat sin strategi, eftersom deras andra generationens 19nm TLC redan är SSD-klassad och produktionen av både MLC- och TLC-smaker från 15nm-noden ökar allt eftersom. Kanske håller TLC äntligen på att bli en förstklassig medborgare i den fantastiska världen. Dagens recension kommer att hjälpa oss att berätta mer om tillståndet för TLC NAND utanför Samsungs värld. Jag tänker inte täcka de tekniska aspekterna av TLC här eftersom vi har gjort det flera gånger tidigare, så ta en titt på länkarna ifall du behöver en uppdatering om hur TLC fungerar och hur det skiljer sig från SLC/MLC.
Ultra II finns i fyra kapaciteter: 120 GB, 240 GB, 480 GB och 960 GB. 120GB- och 240GB-modellerna levereras redan, men de större 480GB- och 960GB-modellerna kommer att finnas tillgängliga om ungefär en månad. Alla kommer i en 2,5″ 7 mm formfaktor med en 9,5 mm distans ingår. Det finns inga mSATA- eller M.2-modeller tillgängliga och vad jag fick höra finns det inte några i pipelinen heller (åtminstone för detaljhandeln). SanDisk har alltid varit ganska konservativa med sin återförsäljarutbud och de har inte varit intresserade av de små nischer som mSATA och M.2 erbjuder för närvarande, så det är ett logiskt beslut att hålla fast vid 2,5″ för tillfället.
| SanDisk Ultra II-specifikationer | |||||
| Kapacitet | 120 GB | 240 GB | 480 GB | 960 GB | |
| Kontroller | Marvell 88SS9190 | Marvell 88SS9189 | |||
| NAND | SanDisk 2nd Gen 128Gbit 19nm TLC | ||||
| Sekventiell läsning | 550 MB/s | 550 MB/s | 550 MB/s | 550 MB/s | |
| Sekventiell skrivning | 500 MB/s | 500 MB/s | 500 MB/s | 500 MB/s | |
| 4KB slumpmässig läsning | 81K IOPS | 91K IOPS | 98K IOPS | 99K IOPS | |
| 4KB slumpmässig skrivning | 80K IOPS | 83K IOPS | 83K IOPS | 83K IOPS | |
| Idle Power (Slumber) | 75mW | 75mW | 85mW | 85mW | |
| Max effekt (läs/skriv) | 2,5W / 3,3W | 2,7W / 4,5W | 2,7W / 4,5W | 2,9W / 4,6W | |
| Kryptering | N/A | ||||
| Garanti | Tre år | ||||
| Detaljhandelsprissättning | 80 USD | 112 $ | 200 USD | 500 USD | |
Det finns två olika kontrollerkonfigurationer: 120GB- och 240GB-modellerna använder 4-kanals 9190 “Renoir Lite”-kontrollern, medan modellerna med högre kapacitet använder den fulla 8-kanaliga designen 9189 “Renoir”-kisel. Såvitt jag vet är det ingen skillnad förutom kanalantalet (kanske även i interna cachestorlekar), och “Lite”-versionen är billigare. SanDisk har gjort detta tidigare med X300s till exempel, så att ha två olika kontroller är egentligen inget nytt och det är vettigt eftersom de mindre kapaciteterna inte kan dra full nytta av alla åtta kanalerna ändå. Observera att 9189/9190 inte är den nya TLC-optimerade 1074-kontrollern från Marvell – det är samma kontroller som till exempel används i Crucials MX100.
I likhet med resten av SanDisks klient-SSD-sortiment erbjuder Ultra II inget krypteringsstöd. För tillfället erbjuder SanDisk endast kryptering i X300s, men i framtiden kommer TCG Opal 2.0 och eDrive-stöd med stor sannolikhet också att ta sig till klientdiskarna. DevSleep stöds inte heller och SanDisk sa att orsaken är att nischen för eftermarknaden DevSleep-aktiverade SSD:er är praktiskt taget obefintlig. Nästan alla plattformar som stöder DevSleep (vilket faktiskt är väldigt få) kommer redan med SSD, t.ex. bärbara datorer, så DevSleep är inte en funktion som köpare tycker är värdefull.
nCache 2.0
Ultra II erbjuder ganska imponerande prestandasiffror för en TLC-enhet eftersom även den minsta 120GB-modellen klarar av 550MB/s läsning och 500MB/s skrivning. Hemligheten bakom prestandan är nya nCache 2.0, som tar SanDisks pseudo-SLC-cacheläge till en nästa nivå. Medan den ursprungliga nCache huvudsakligen designades för att cachelagra NAND-mappningstabellen tillsammans med några små skrivningar (<4KB), cachar 2.0-versionen alla skrivningar oavsett storlek och typ genom att öka kapaciteten för pseudo-SLC-delen. nCache 1.0 hade en SLC-del mindre än 1 GB (SanDisk avslöjade aldrig den faktiska storleken), men 2.0-versionen kör 5 GB av NAND i SLC-läge för varje 120 GB användarutrymme.
| nCache 2.0 Översikt | ||||
| Kapacitet | 120 GB | 240 GB | 480 GB | 960 GB |
| SLC-cachestorlek | 5 GB | 10 GB | 20 GB | 40 GB |
Det intressanta med SanDisks implementering är det faktum att varje NAND-matris har ett fast antal block som körs i SLC-läge. Fördelen är att när data måste flyttas från SLC till TLC-delen kan överföringen göras internt i tärningen, vilket är en funktion som SanDisk anropar On Chip Copy. Detta är en egenutvecklad design och använder en speciell form, så du kommer inte att se några konkurrenskraftiga produkter som använder samma arkitektur. Normalt skulle SLC till TLC-överföringen göras som vilken annan slitageutjämningsoperation som helst genom att använda NAND-gränssnittet (Toggle eller ONFI) och DRAM för att flytta runt data internt från matris till matris, men nackdelen är att en sådan design kan avbryta värden IO-bearbetning eftersom de interna operationerna upptar NAND-gränssnittet och DRAM.
OCZ:s “Performance Mode” är ett bra exempel på en konkurrerande teknologi: när den snabba bufferten är full sjunker skrivhastigheten till hälften, eftersom förutom värd-IO:erna måste enheten nu flytta data från SLC till MLC/TLC, vilket ökar som hörs eftersom det finns ytterligare belastning på styrenheten, NAND-gränssnitt och i själva NAND. Prestanda återställs när kopierings-/omorganiseringsoperationerna är klara.
SanDisks tillvägagångssätt introducerar minimal overhead eftersom allt görs i formen. Eftersom ett SLC-block är exakt en tredjedel av ett TLC-block, viks tre SLC-block helt enkelt till ett TLC-block. Uppenbarligen finns det fortfarande en viss extra latens om du försöker komma åt en sida i ett block som är mitt i vikningsoperationen, men effekten av det är mycket mindre än vad en die-to-die-överföring skulle orsaka.
On Chip Copy har en fördefinierad tröskel som kommer att utlösa vikmekanismen, även om SanDisk sa att den är adaptiv i den meningen att den också kommer att titta på datatypen och storleken för att bestämma den bästa åtgärden. Inaktiv tid kommer också att utlösa On Chip Copy, men det finns ingen fastställd tröskel för det heller från vad jag fick veta.
I vårt 240GB-exempel är SLC-cachestorleken 10GB och eftersom sexton 128Gbit (16GiB) NAND-matriser behövs för den råa NAND-kapaciteten på 256GiB, ser cachen per dies ut att vara 625MB. Jag gissar att det i verkligheten finns 32GiB TLC NAND som körs i SLC-läge (dvs. 2GiB per tärning), vilket skulle innebära 10,67GiB SLC, men tyvärr kunde SanDisk inte dela de exakta blockstorlekarna för TLC och MLC med oss av konkurrensskäl .
Prestandafördelarna med SLC-läget är uppenbara. Ett TLC-block kräver att flera iterationer programmeras eftersom fördelningen av spänningstillstånden är mycket snävare, så det finns mindre utrymme för fel, vilket kräver en längre och mer komplex programmeringsprocess.
Jag körde HD Tach för att se hur prestandan är för alla LBA:er. Med sekventiell data verkar tröskeln för On Chip Copy vara cirka 8GB eftersom prestandan efter det sjunker från 400MB till ~230MB/s. För genomsnittliga klientarbetsbelastningar är det mer än tillräckligt eftersom användare vanligtvis inte skriver mer än ~10 GB per dag och med vilotid kommer nCache 2.0 också att flytta data från SLC till TLC för att säkerställa att SLC-cachen har tillräckligt med utrymme för alla inkommande skrivningar.
Den förbättrade prestandan är inte den enda fördelen med nCache 2.0. Eftersom allt skrivs till SLC-delen först, kan data sedan skrivas sekventiellt till TLC. Det minimerar skrivförstärkningen på TLC-delen, vilket i sin tur ökar uthålligheten eftersom det blir mindre redundanta NAND-skrivningar. Med sekventiell skrivning är det vanligtvis möjligt att uppnå skrivförstärkning på mycket nära 1x (dvs minimum utan komprimering) och SanDisk hävdar faktiskt en skrivförstärkning på cirka 0,8x för typiska klientarbetsbelastningar (för TLC-delen, det vill säga). Det beror på att inte all data kommer till TLC i första hand – en del data kommer att raderas medan den fortfarande finns i SLC-cachen och kommer därför inte att orsaka något slitage på TLC. Kom ihåg att TLC i allmänhet bara är bra för cirka 500-1 000 P/E-cykler, medan SLC lätt kan överträffa 30 000 cykler även vid 19nm, så att använda SLC-cachen så mycket som möjligt är avgörande för uthållighet med TLC vid så små litografier.
Liksom den tidigare nCache 1.0, används 2.0-versionen också för att cachelagra NAND-mappningstabellen för att förhindra datakorruption och förlust. SanDisk använder inga skyddskretsar för strömförlust (dvs. kondensatorer) i klientenheter, utan istället används SLC-cachen för att spola mappningstabellen från DRAM oftare, vilket är möjligt på grund av den högre uthålligheten och lägre latensen hos SLC. Det ger uppenbarligen inte samma skyddsnivå som kondensatorer gör eftersom alla pågående skrivningar kommer att gå förlorade under ett strömavbrott, men det säkerställer att NAND-mappningstabellen inte blir korrupt och förvandlar enheten till en kloss. SanDisk har faktiskt en omfattande vitbok om skydd för strömavbrott och de tekniker som används, så de som är intresserade av ämnet bör tycka att det är bra att läsa.
Multi Page Recovery (MPR)
Att använda paritet som en form av felkorrigering har blivit mer och mer populärt i branschen på sistone. SandForce gjorde det första steget med RAISE för flera år sedan och nästan varje tillverkare har släppt sin egen implementering sedan dess. SanDisk har dock varit en av de få som inte har haft någon ordentlig paritetsbaserad felkorrigering i klient-SSD, men Ultra II ändrar på det.
SanDisks implementering kallas Multi Page Recovery och som namnet antyder ger den redundans på sidnivå. Tanken är exakt densamma som med SandForces RAISE, Microns RAIN och vilket annat RAID 5-liknande schema som helst: paritet skapas för data som kommer in, som sedan kan användas för att återställa data om ECC-motorn inte kan gör det.
Paritetsförhållandet i Ultra II är 5:1, vilket innebär att det finns en paritetssida för var femte sida med faktisk data. Men här är den knepiga delen: med 256GiB rå NAND och ett paritetsförhållande på 5:1 kan den användbara kapaciteten inte vara mer än 229GB eftersom en sjättedel av NAND är dedikerad för paritet.
Hemligheten är att NAND-matriserna egentligen inte är 128Gbit – de är faktiskt mycket större än så. SanDisk kunde inte ge oss den exakta storleken på grund av konkurrensskäl, men sa till oss att 128Gbit-numret borde behandlas som MLC för att det skulle vara vettigt. Eftersom TLC lagrar tre bitar per cell istället för två, kan den lagra 50 % mer data i samma område, så 128 Gbit MLC skulle bli 192 Gbit TLC. Det är i en perfekt värld där varje tärning är lika och det inte finns några dåliga block; i verkligheten ger TLC cirka 30-40 % densitetsökning jämfört med MLC eftersom TLC i sig har fler dåliga block (t.ex. strängare spänningskrav eftersom det finns mindre utrymme för fel på grund av snävare fördelning av spänningstillstånden).
I det här exemplet, låt oss anta att TLC ger en 35% ökning jämfört med TLC när de dåliga blocken tas bort. Det förvandlar vår 128Gbit MLC-matris till en 173Gbit TLC-matris. Nu, med nCache 2.0, har varje tärning ungefär 5 Gbit SLC, vilket äter bort ~15 Gbit TLC och vi slutar med en tärning som har 158 Gbit användbar kapacitet. Faktor i paritetsförhållandet 5:1 och slutanvändarkapaciteten är ~132Gbit per tärning. Sexton av dessa skulle vara lika med 264GiB rå NAND, vilket är ganska nära de 256GiB vi började med.
Observera att ovanstående bara är ett exempel för att hjälpa dig förstå hur 5:1 paritetsförhållande är möjligt. Som jag sa, SanDisk skulle inte avslöja de faktiska siffrorna och i den verkliga världen kan den råa NAND-kapaciteten variera lite eftersom antalet dåliga block kommer att variera från die till die. Det viktiga är dock att Ultra II har samma 12,7 % överprovisionering som Extreme Pro, och det är efter att nCache 2.0 och Multi Page Recovery har tagits med i beräkningen (dvs. 12,7 % är dedikerade till sophämtning, slitage- utjämning och de vanliga NAND-hanteringssystemen).
Dessutom har alla NAND-matriser vad som kallas reservbytes, som är ytterligare byte avsedda för ECC. Till exempel har Microns 20nm MLC NAND en faktisk sidstorlek på 17 600 byte (16 384 användarutrymme + 1 216 reservbyte), så i verkligheten är en 128Gbit-matris aldrig riktigt 128Gbit – det finns alltid lite mer för ECC och dålig blockhantering. Antalet reservbytes har vuxit i takt med att industrin har flyttat till mindre processnoder eftersom behovet av ECC har ökat och så även antalet dåliga block. TLC är bara en nivå sämre eftersom den är mindre tillförlitlig genom sin design, därför behövs fler reservbyte för att göra den användbar i SSD:er.
Testa uthållighet
SanDisk ger inte något specifikt uthållighetsbetyg för Ultra II, vilket liknar vad Samsung gör med SSD 840 EVO. Anledningen är att båda endast är validerade för klientanvändning, vilket innebär att om du skulle använda någon av dem i en företagsmiljö skulle garantin vara ogiltig ändå. Jag kan se resonemanget bakom att inte inkludera en strikt uthållighetsklassificering för en klientdrift på ingångsnivå eftersom konsumenterna inte är särskilt bra på att förstå sina uthållighetsbehov och att ha ett betyg (som uppenbarligen skulle vara lägre för en TLC-enhet) skulle bara leda till förvirring . Att SanDisk inte har satt något betyg betyder dock inte att jag inte ska testa uthållighet.
För att göra det vände jag mig till vår standardmetod för uthållighetstestning. I grund och botten skrev jag sekventiell 128KB data (QD1) till disken och övervakade SMART-värdena 230 och 241, dvs. Media Wear Out Indicator (MWI) och Total GB Written. I fallet med Ultra II fungerar MWI motsatt av vad vi är vana vid: den börjar från 0 % och ökar när frekvensomriktaren slits ut. När MWI når 100 % har enheten kommit till slutet av sin beräknade livslängd – den kommer sannolikt att fortsätta att fungera eftersom klientens SSD-uthållighetsklassificeringar är med ett års datalagring, men jag skulle inte rekommendera att använda den för kritiska data efter den punkten.
| SanDisk Ultra II uthållighetstest | |
| Ändring i mediasslitageindikator | 7,8 % |
| Ändring i Total GB Skrivet | 9 232 GiB |
| Observerad total uthållighet | 118 359 GiB |
| Observerade P/E-cykler | ~530 |
Tabellen ovan sammanfattar resultaten av mitt test. Testets längd var 12 timmar och jag tog några datapunkter under körningen för att säkerställa att resultaten är giltiga. Från data extrapolerade jag den totala uthålligheten och använde den som grund för att beräkna P/E-cyklerna med följande formel:
Jag gjorde antagandet att den kombinerade slitageutjämnings- och skrivförstärkningsfaktorn är 1x eftersom det är rimligt med rena sekventiella skrivningar och det gör beräkningen mycket enklare. För kapacitet använde jag användarkapaciteten (240GB dvs 223,5GiB), så de observerade P/E-cyklerna är helt enkelt total uthållighet dividerat med kapaciteten (båda i GiB).
Siffran jag kom fram till är 530 P/E-cykler. Det finns ett antal faktorer som gör det praktiskt taget omöjligt att räkna ut den exakta NAND-uthålligheten eftersom en del av NAND-enheten fungerar i SLC-läge med mycket större uthållighet och det finns en rejäl mängd reservbyte för paritet, men jag tror att det är säkert att säga att TLC NAND-delen är klassad till cirka 500 P/E-cykler.
| SanDisk Ultra II uppskattad uthållighet | ||||
| Kapacitet | 120 GB | 240 GB | 480 GB | 960 GB |
| Total uppskattad uthållighet | 54.6TiB | 109,1 TiB | 218.3TiB | 436,6 TiB |
| Skriver per dag | 20 GiB | |||
| Skriv förstärkning | 1,2x | |||
| Total beräknad livslängd | 6,4 år | 12,8 år | 25,5 år | 51,0 år |
Eftersom enbart P/E-cykelräkningen är lätt att missförstå, sätter jag in det i ett sammanhang som är lättare att förstå, dvs drivenhetens livslängd. Allt jag gjorde var att multiplicera användarkapaciteten med P/E-cykelräkningen för att få den totala uthålligheten, som jag sedan använde för att beräkna den uppskattade livslängden. Jag valde 20GiB skrivningar per dag för även om SanDisk inte gav ett uthållighetsbetyg för Ultra II, var deras interna designmål 20GiB per dag, vilket är en ganska vanlig standard för klientenheter. Jag ställer in skrivförstärkningen till 1,2x eftersom TLC-blocken skrivs sekventiellt tack vare nCache 2.0, och det borde resultera i skrivförstärkning som är mycket nära 1x.
500 P/E-cykler låter förvisso inte mycket, men när man sätter det i sitt sammanhang är det mer än tillräckligt. Med 20GiB om dagen kommer till och med 120GB Ultra II lätt att överleva resten av komponenterna. nCache 2.0 spelar en stor roll för att göra Ultra II så hållbar som den är eftersom den håller skrivförstärkningen nära den ideala 1x. Utan nCache 2.0 skulle 500 P/E-cykler vara ett stort problem, men som det ser ut ser jag inte att uthållighet är ett problem. Naturligtvis, om du skriver mer än 20GiB per dag och din arbetsbelastning är IO-intensiv i allmänhet, är det bättre att leta efter enheter som är avsedda för tyngre användning, t.ex. Extreme Pro och SSD 850 Pro.
En titt på SanDisks uppdaterade SSD Dashboard
Tillsammans med Ultra II kommer SanDisk med en uppdaterad version av sin SSD Dashboard, märkt som 1.1.1.
Startvyn har inte ändrats och ger samma översikt över drivningen som tidigare.
De viktigaste nya funktionerna finns under fliken “Verktyg” och tillhandahålls av tredje part. Tidigare har SanDisk inte erbjudit någon kloningsprogramvara med sina enheter, men den nya versionen ger möjligheten att använda Apricorns EZ GIG IV-programvara för att migrera från en gammal enhet. Genom att klicka på länken i Dashboard kommer du till Apricorns webbplats där användaren kan ladda ner programvaran. Observera att Dashboard innehåller en specialversion av EZ GIG IV som bara kan användas för att klona en enhet en gång.
Utöver EZ GIG IV lägger 1.1.1-versionen till Trend Micros mjukvara Titanium Antivirus+. Även om de flesta redan kör antivirusprogram av något slag, finns det (för) många människor som inte nödvändigtvis har ett uppdaterat antivirusprogram som har definitionerna för den senaste skadliga programvaran, så tanken bakom att inkludera antivirusprogramvaran är för att säkerställa att alla användare har en free och enkelt sätt att kontrollera deras system för skadlig programvara innan de migrerar till en ny enhet.
Den nya versionen lägger också till stöd för “sanitet”. Det är i grunden en förbättrad version av säker radering och fungerar på samma sätt som 0-fill radering gör: istället för att bara radera data, skriver sanitation nollor till alla LBA:er för att garantera att det absolut inte finns något sätt att återställa den gamla data. Crypto Erase är nu också en del av Dashboard, även om det för närvarande bara stöds av X300s eftersom det är den enda enheten med hårdvarukryptering.
Live-prestandaövervakning stöds också, men tyvärr finns det inget alternativ att köra ett riktmärke i programvaran (dvs den övervakar bara enheten liknande vad Windows Performance Monitor gör). För OS utan TRIM innehåller Dashboard en möjlighet att köra en schemalagd TRIM för att säkerställa maximal prestanda. Om TRIM stöds och är aktiverat (som i det här fallet sedan jag körde Windows 8.1), är TRIM-fliken nedtonad eftersom operativsystemet tar hand om att skicka TRIM-kommandona när det behövs.
Supporten har också förbättrats i den nya versionen eftersom alternativ för livechatt och e-postsupport har lagts till. Nya språk har också lagts till, och instrumentpanelen är nu tillgänglig på 17 olika språk. Under installationsprocessen kommer installationsprogrammet att fråga efter önskat språk, men det är också möjligt att ändra det i efterhand under fliken Inställningar.
Testa system
För AnandTech Storage Benches, prestandakonsistens, slumpmässig och sekventiell prestanda, prestanda kontra överföringsstorlek och belastningsströmförbrukning använder vi följande system:
| CPU | Intel Core i5-2500K körs på 3,3 GHz (Turbo & EIST aktiverat) |
| Moderkort | AsRock Z68 Pro3 |
| Chipset | Intel Z68 |
| Drivrutiner för chipset | Intel 9.1.1.1015 + Intel RST 10.2 |
| Minne | G.Skill RipjawsX DDR3-1600 4 x 8 GB (9-9-9-24) |
| Grafikkort | Palit GeForce GTX 770 JetStream 2GB GDDR5 (1150MHz kärnklocka; 3505MHz GDDR5 effektiv) |
| Video drivrutiner | NVIDIA GeForce 332.21 WHQL |
| Skrivbordsupplösning | 1920 x 1080 |
| OS | Windows 7 x64 |
Tack vare G.Skill för RipjawsX 32GB DDR3 DRAM-kit
För sömnkraftstestning använde vi ett annat system:
| CPU | Intel Core i7-4770K körs på 3,3 GHz (Turbo & EIST aktiverat, C-tillstånd inaktiverat) |
| Moderkort | ASUS Z87 Deluxe (BIOS 1707) |
| Chipset | Intel Z87 |
| Drivrutiner för chipset | Intel 9.4.0.1026 + Intel RST 12.9 |
| Minne | Corsair Vengeance DDR3-1866 2x8GB (9-10-9-27 2T) |
| Grafik | Intel HD Graphics 4600 |
| Drivrutiner för grafik | 15.33.8.64.3345 |
| Skrivbordsupplösning | 1920 x 1080 |
| OS | Windows 7 x64 |
