Intel lanserar Optane för konsumenter i form av M.2-baserad cachelagring

Permalänk
Medlem

Totalt misslyckat implementation av Intel! Tekniken och tanken verkar god men misslyckat till anledningen av att den just är en M.2 enhet.

Målgruppen som kan tänkas ha nytta av en "cache boost" enhet är den som har en befintlig äldre dator UTAN M.2 port och använder en mekanisk HDD till lagring, samt använder datorn som en vanlig PC.
[/quote]

Tror poängen är att de måste ha M.2 (eller U.2) för att kunna få NVMe och den låga accesstiden, annars kan du inte ens få de fördelarna, och då blir det som en totalt överprisad NAND SSD.

Skrivet av SolidReactor:

Bra att smidigt kunna skyffla in en enhet som boostar hela datorn, utan ominstallation av OS m.m. till gemene man.

Genom att ha M.2 anslutning vänder sig denna produkt till en målgrupp med nyare datorer, som då redan har en SSD till primär disk.

Är det något jag har missat eller missuppfattat?

Denna produkt borde ha kommit för ett antal år sedan när SSD var en "lyx" produkt p.g.a. priset och då i en SATA variant. Då hade den säkert kunna vara ett toppenalternativ till SSD om man inte har råd med en dyr SSD eller vill bara billigt kunna uppgradera sin befintliga investering till dator med innehållande gammal mekanisk disk.

Det du beskriver och "önskar ha" är just Intels Smart Reponse... dvs använda en liten SSD som boost för en HDD och har funnits sedan 2011, på en hel del moderkort, i Intels SATA styrkrets.

Mjukvaran finns att ladda ner gratis, du måste ha över datorn i RAID läge (går att ändra utan ominstall) och sen skapa den. Och det fungerar med alla SSDer och MBR diskar iaf (vad jag minns), så typ 2-3TB stora HDD. Cachen kan göras mellan 16-64GB stor, och du bör tänka på att lämna extra utrymme som jag beskrivit tidigare i tråden.

Håller dock fullständigt med att Intels implementation här är löjlig, men det var delvis SRT också, då de hade mest nytta på budget PC, och fanns bara i high-end moderkorten (typ Z*7/H*7 kort). Den var mycket populär i enklare laptops dock, där många tillverkare använde denna eller liknande teknik.

Permalänk
Skrivet av SolidReactor:

Totalt misslyckat implementation av Intel! Tekniken och tanken verkar god men misslyckat till anledningen av att den just är en M.2 enhet.

Målgruppen som kan tänkas ha nytta av en "cache boost" enhet är den som har en befintlig äldre dator UTAN M.2 port och använder en mekanisk HDD till lagring, samt använder datorn som en vanlig PC.
Bra att smidigt kunna skyffla in en enhet som boostar hela datorn, utan ominstallation av OS m.m. till gemene man.

Genom att ha M.2 anslutning vänder sig denna produkt till en målgrupp med nyare datorer, som då redan har en SSD till primär disk.

Är det något jag har missat eller missuppfattat?
Denna produkt borde ha kommit för ett antal år sedan när SSD var en "lyx" produkt p.g.a. priset och då i en SATA variant. Då hade den säkert kunna vara ett toppenalternativ till SSD om man inte har råd med en dyr SSD eller vill bara billigt kunna uppgradera sin befintliga investering till dator med innehållande gammal mekanisk disk.

Det enda du missar är att M.2-portens sällsynthet inte spelar nån roll på äldre datorer eftersom det redan är nolll äldre datorer med Kaby Lake. :/

Visa signatur
Permalänk
Medlem

Kan nog bli prisvärt inom något år. Kör själv en OS-SSD på 180gb + 2tb lagring för alla mindre frekvent använda spel i steam-biblioteket. Om det skulle vara möjligt att cacha ~100gb av de viktigaste spelfilerna så kunde man kanske slippa flytta runt spelen alls.

Visa signatur

Om du vill att jag ska se ditt svar så tryck på Citera.

Permalänk
Medlem
Skrivet av Paddanx:

Det du beskriver och "önskar ha" är just Intels Smart Reponse... dvs använda en liten SSD som boost för en HDD och har funnits sedan 2011, på en hel del moderkort, i Intels SATA styrkrets.

Mjukvaran finns att ladda ner gratis, du måste ha över datorn i RAID läge (går att ändra utan ominstall) och sen skapa den. Och det fungerar med alla SSDer och MBR diskar iaf (vad jag minns), så typ 2-3TB stora HDD. Cachen kan göras mellan 16-64GB stor, och du bör tänka på att lämna extra utrymme som jag beskrivit tidigare i tråden.

Håller dock fullständigt med att Intels implementation här är löjlig, men det var delvis SRT också, då de hade mest nytta på budget PC, och fanns bara i high-end moderkorten (typ Z*7/H*7 kort). Den var mycket populär i enklare laptops dock, där många tillverkare använde denna eller liknande teknik.

Som "cache disk" att köra med M.2 NVME är att konkurrera mot SSD.
Att köra "cache disk" med SATA är att kunna konkurrera mot HDD över SATA.

Verkar vara som du säger att Intel ville ha en så bra produkt som möjligt men då hamnat i en mindre målgrupp. Jag tycker att det låter dumt, låter som prestige tog över förnuft.
Antar att Intel hoppats på att Optane varumärket ska vara bra reklam på den fina teknik som komma skall, men jag ser bara patetisk försök att skohorn:a in en produkt i fel ställe.

Nyfiken på hur det internt låter hos Intels RnD, vad teknikerna/forskarna säger och vad marknadsföringen & chefen säger.

Permalänk
Datavetare
Skrivet av Paddanx:

Totalt misslyckat implementation av Intel! Tekniken och tanken verkar god men misslyckat till anledningen av att den just är en M.2 enhet.

Målgruppen som kan tänkas ha nytta av en "cache boost" enhet är den som har en befintlig äldre dator UTAN M.2 port och använder en mekanisk HDD till lagring, samt använder datorn som en vanlig PC.
[/quote]

Tror poängen är att de måste ha M.2 (eller U.2) för att kunna få NVMe och den låga accesstiden, annars kan du inte ens få de fördelarna, och då blir det som en totalt överprisad NAND SSD.

Det du beskriver och "önskar ha" är just Intels Smart Reponse... dvs använda en liten SSD som boost för en HDD och har funnits sedan 2011, på en hel del moderkort, i Intels SATA styrkrets.

Mjukvaran finns att ladda ner gratis, du måste ha över datorn i RAID läge (går att ändra utan ominstall) och sen skapa den. Och det fungerar med alla SSDer och MBR diskar iaf (vad jag minns), så typ 2-3TB stora HDD. Cachen kan göras mellan 16-64GB stor, och du bör tänka på att lämna extra utrymme som jag beskrivit tidigare i tråden.

Håller dock fullständigt med att Intels implementation här är löjlig, men det var delvis SRT också, då de hade mest nytta på budget PC, och fanns bara i high-end moderkorten (typ Z*7/H*7 kort). Den var mycket populär i enklare laptops dock, där många tillverkare använde denna eller liknande teknik.

Grejen med 3D-Xpoint är att utan NVMe är man totalt utan fördelar. Det finns fyra egenskaper som ger 3D-Xpoint ett existensberättigande jämfört med NAND.

  • accesslatensen är ~100 gånger lägre

  • det går att skriva många fler gånger innan minnet slits ut

  • det går att packa väsentligt mer bitar på i ett visst utrymme jämfört med DRAM (ungefär samma densitet som NAND)

  • går effektivt att adressera ner på enskilda bytes, NAND består av relativt stora block

Är de två första punkterna man försöker spela på nu i NVMe-baserade enheter. Problemet är att även fast NVMe har låg latens jämfört med tidigare gränssnitt är det fortfarande så att latens som kommer från NVMe-kontrollen är den dominerande faktorn för 3D-Xpoint. I praktiken är latensen bara 5-10 gånger lägre än de snabbast NAND-baserade enheterna, för att nå 100x måste man få in denna teknik direkt i RAM-moduler (och först då de två sista punkterna överhuvudtaget blir relevanta).

Folk verkar stirra på max IOPS för Samsungs top-of-the-line och sedan avfärda Optane för det är ungefär samma maximala IOPS. Den man totalt då missar är att NAND-baserade diskar når överhuvudtaget inte över 100k IOPS innan ködjupet av samtidiga transaktioner klart passerat 10, maximal IOPS når man inte innan ködjupet är en bit över 50.

Vid ködjup <=2, vilket är vad en typisk desktopdator kommer spendera väldigt nära 100 % tiden med, så ligger NAND-baserade diskar på 10k-20k IOPS. Det ser man också i resultatet som postades tidigare i tråden, 4k random read QD=1 -> 55,17 MB/s (motsvarar 13,8k IOPS).

Optane diskarna når 5-10 gånger högre IOPS vid låga ködjup, så 4k random read Q=1 kommer i stället ligga runt 250-400 MB/s. Beroende på arbetslast kan detta vara värt något, men det är bara inom relativt smala nischer där 3D-Xpoint sittandes på NVMe har en poäng. Sätter man det t.ex. på SATA är det ju helt värdelöst för då ryker den enda relevanta fördelen som finns innan man får in detta direkt som RAM, SATA har ju så pass hög latens att det blir en flaskhals även för NAND.

Ser därför inte riktigt fördelen av detta på desktop. Eller ser absolut fördel med SRT men ser inte att Optane skulle ge någon relevant vinst över SRT med en NAND-disk sittandes på SATA eller NVMe.

Förstår inte heller din aviga inställning till SRT. SSHD diskarna hade potential, men den potentialen utnyttjandes aldrig då man nästan uteslutande använde en allt för liten NAND-cache (typiskt 8 GB). Kör själv SRT på min speldator, har en 60 GB SSD-cache (en SSD jag hittade i en låda) mot en 1 TB 2,5" laptop-disk (har en mini-ITX låda + tycker 3,5" diskar låter för mycket).

Prestandamässigt är 1 TB 2,5" horribel, men i praktiken blir det väldigt nära prestanda motsvarande 60 GB SSD. Då använder jag denna disk som lagring av mitt Steam-bibliotek medan OS och övriga program ligger på en 256 GB 850 EVO disk. D.v.s. tanken med SSHD var inte fel, men det är kritiskt att cachen är stor nog att kunna hålla all data som man regelmässigt använder.

16 GB lär vara för lite idag, 32 GB kanske fungerar men är inte helt säker (beror på vad man gör så klart) så skeptiskt till Optane diskarna i denna artikel. 60 GB är fortfarande tillräckligt stort för att hålla ett par moderna spel, inget spel använder ju all data som installeras hela tiden.

Det man vinner med SSD/Optane cache för en mekanisk disk är främst brutal ökad IOPS-kapacitet vid låga ködjup. Även en rätt medioker SSD har >100x högre IOPS jämfört med en mekanisk disk vid 4k random read QD=1. Ser dock inte riktigt att fördelen med Optane blir relevant över en SSD ens sittande på SATA utanför nischfall.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av SolidReactor:

Som "cache disk" att köra med M.2 NVME är att konkurrera mot SSD.
Att köra "cache disk" med SATA är att kunna konkurrera mot HDD över SATA.

Verkar vara som du säger att Intel ville ha en så bra produkt som möjligt men då hamnat i en mindre målgrupp. Jag tycker att det låter dumt, låter som prestige tog över förnuft.
Antar att Intel hoppats på att Optane varumärket ska vara bra reklam på den fina teknik som komma skall, men jag ser bara patetisk försök att skohorn:a in en produkt i fel ställe.

Nyfiken på hur det internt låter hos Intels RnD, vad teknikerna/forskarna säger och vad marknadsföringen & chefen säger.

Håller med.

Speciellt när teknikerna kommer till chefen och PR gänget och säger:
"Ermm.. de 1000x snabbare målen vi sa tidigare... vi kommer missa dem med typ 100x faktor."
Hakan måste ha slagit i bordet... och panik utbrutit

De verkar nästan ha hype:at sig själva så mycket att de glömt bort att titta på vad som hänt med SSDer runt om sig. Eller vad produkten faktiskt kan göra i praktiken.

Mest ironiska är ju att den SSDn jag vet idag som verkligen skulle behöva en Optane Cache, är deras egen 600p, som faller pladask med 20MB/s när den lilla SSD cachen är slut, samt har rätt dålig låg kö-djup IOPs.

Så kanske ingen på Intel har tittat på konkurrenterna? Skulle ju inte vara så svårt att tro med tanke på att de jämför Optane med S3700, och inte 750, som är snabbare. Eller så är det att man inser hur dåligt det egentligen är, men försöker ändå sälja möget.

Permalänk
Medlem
Skrivet av Yoshman:

Grejen med 3D-Xpoint är att utan NVMe är man totalt utan fördelar. Det finns fyra egenskaper som ger 3D-Xpoint ett existensberättigande jämfört med NAND.

  • accesslatensen är ~100 gånger lägre

  • det går att skriva många fler gånger innan minnet slits ut

  • det går att packa väsentligt mer bitar på i ett visst utrymme jämfört med DRAM (ungefär samma densitet som NAND)

  • går effektivt att adressera ner på enskilda bytes, NAND består av relativt stora block

Är de två första punkterna man försöker spela på nu i NVMe-baserade enheter. Problemet är att även fast NVMe har låg latens jämfört med tidigare gränssnitt är det fortfarande så att latens som kommer från NVMe-kontrollen är den dominerande faktorn för 3D-Xpoint. I praktiken är latensen bara 5-10 gånger lägre än de snabbast NAND-baserade enheterna, för att nå 100x måste man få in denna teknik direkt i RAM-moduler (och först då de två sista punkterna överhuvudtaget blir relevanta).

Som sagt, i en servermiljö kan utan tvekan Optane bli mer användbar. Men jag har två kritiska tvivel som måste tas i aspekt, som du kanske har svar på?

Ena är... prestandan. det är helt klart ett "stort-långsamt-ramminne", men även om du kan adressera på en byte nivå, så kommer ju all access ändå att bli med lägre bandbredd och lägre prestanda än riktigt RAM. Du får dock en "fördel/nackdel" att du måste kunna hantera fel via ECC, samt fel vid "omstart". Ska du blanka minnet helt då eller, eftersom det inte tappar data vid strömförlust.

Tömmer du det så sliter du ju på det, och tömmer du inte det så måste ju all kod skivas om så den kan hantera en "uppstart" utan en... "normal uppstart".

Andra är... slitage. Din punkt 2 ovan är rätt fel tänkt, och låt mig förklara varför jag tror det. De säger "30 Drive Wites Per Day" på (nu 3), senare 5 år är nivån. Så 5år*365*30DWPD*375GB = ca 20k TBW, eller 20PB, vilket är mycket mer än NAND, okej, så långt allt bra.

Sen skapar vi en 30GB stor databas i denna.. och du skriver till denna med låt oss säga de 250MB/s du nämner nedan... Om vi antar att du skriver exakt lika mycket till varje del (vilket ju är perfekt miljö, men inte realistisk) så kommer du ändå bara använda 30GB av detta större Optane pga du "modifierar på byte nivå". Så du skriver ca 250MB/s i QD1, till effektivt en 30GB "disk".

250MB/s*3600*24, dvs hela 21,6TB per dag... Men du skriver inte det till 375GB disk, utan till 30GB, då Optane adresseras och hanteras sektor för sektor, vilket är varför prestandan är så låg, dvs.. ingen Wear-algoritm.

Så tar vi formeln ovan och ersätter 375GB med 30GB, får vi plötsligt bara 1,64PB... och om vi nu använder lägsta QD1 så tittar vi på 1640TB / 21.6TB per dag = 75 dagar... Så din dvindyra Optane disk har 30GB skadade utslitna sektorer och "felmeddelande" efter 2,5 månad. Inte direkt lovande för RAM huh?

Så alla fördelar med att kunna adressera på bit nivå, allt prat om RAM och hur Optane är så mycket snabbare... du kan ju ffs inte använda prestandan?!!? Att du just kan modifiera samma bit om och om igen gör att man tom på dagar eller tom timmar kan slita ut enstaka "byte" celler på detta, när resten av disken är oanvänd.

Även om vi tittar på säg hela disken @ 250MB/s, så blir det ändå 20000TBW/21.6 per dag = 925 dagar. Så även om du på något magiskt sätt använder allt "perfekt jämt", så är den i lägsta kö-djup, redan död inom 2,5år.

Så... vad Intel säger är: Här har du en disk som "klarar konstant" 500k IOPS, men du kan max skriva 125MB/s (31k IOPS) i snitt, för att hålla 5 års garantinivån, annars sliter du ut den för snabbt, tom räknat med en wear-leveling teknik du inte ens har som RAM. Wtf...

Finns inte en chans att detta kan användas som RAM... skojar du? Inte i nuvarande skick iaf.
Hur i hela friden ska du effektivt kunna använda detta när du i RAM inte styr verken slitage nivå eller var du skriver data och pga skrivtoleansen knappt ens kan matcha en HDD i snitt vs RAM som har typ 20GB/s+.

Med det sagt... du kan säkert hitta ett specifikt skriver fall där det hjälper, men det är lite som att säga att för det speciella fallet av USA kärnvapen fortfarande styrs av 8" floppy disketter. Man kan alltid hitta knäppa miljöer, men det betyder inte att en produkt är bra.

Optane är en flopp som initial produkt. Som teknik och möjlighet, hoppas jag den kan gå bättre än många andra av Intels tekniker. Men vi kan ta Intels RDRAM (Rambus) eller IA64, som ex på hur Intels "bättre" teknik ändå dör, då den inte fungerar så kostnadseffektivt i praktiken som man trodde. Thunderbolt höll ju på att dö den med, men verkar nu med sin mer öppna approach kunna överleva.

Skrivet av Yoshman:

Folk verkar stirra på max IOPS för Samsungs top-of-the-line och sedan avfärda Optane för det är ungefär samma maximala IOPS. Den man totalt då missar är att NAND-baserade diskar når överhuvudtaget inte över 100k IOPS innan ködjupet av samtidiga transaktioner klart passerat 10, maximal IOPS når man inte innan ködjupet är en bit över 50.

Vid ködjup <=2, vilket är vad en typisk desktopdator kommer spendera väldigt nära 100 % tiden med, så ligger NAND-baserade diskar på 10k-20k IOPS. Det ser man också i resultatet som postades tidigare i tråden, 4k random read QD=1 -> 55,17 MB/s (motsvarar 13,8k IOPS).

Optane diskarna når 5-10 gånger högre IOPS vid låga ködjup, så 4k random read Q=1 kommer i stället ligga runt 250-400 MB/s. Beroende på arbetslast kan detta vara värt något, men det är bara inom relativt smala nischer där 3D-Xpoint sittandes på NVMe har en poäng. Sätter man det t.ex. på SATA är det ju helt värdelöst för då ryker den enda relevanta fördelen som finns innan man får in detta direkt som RAM, SATA har ju så pass hög latens att det blir en flaskhals även för NAND.

Så då går vi tillbaka till läsning. För att läsa är ju som sagt inga problem, det kan både NAND och Optane göra i typ evigheter... om inte cellurladdning eller liknande påverkar så klart.

Men personer som gillar Optane (som du ovan) verkar stirra sig blind på att man ska just läsa på kö-djup 1-2, på servernivå, vilket inte riktigt är något jag förstår. Viktigaste måste väl vara att du har en låg och konstant latency, vilket dock är Optanes enda fördel... och ja.. enda. I skrivning så blir detta ju ett problem med infon ovan...

Men hur mycket kodning måste du inte göra om du nu plötslig måste gå från RAM access till ROM access? Det kan omöjligt bli effektivt nog att ersätta det... iaf med dagens mjukvara/teknik. Det kan ersätta en SSD i prestanda, men inte i storlek/pris på långa vägar... så det hamnar i en konstig mellanväg där det är för dyrt för att användas, men inte snabbt nog för att vara värt att använda.

SSDerna kan ju skriva sin last mer än nog bra idag, och en Optane SSD är mer eller mindre lika användbart som en S3700 är som klient-disk med sett till sitt eMLC och förbättrade skrivtolerans. Man använder den inte... men med optane är ju hela poängen att man ska använda det, men inte kan. För även om NAND helt klart har sämre skrivtolerans än Optane (och sämre IOPS), så kan en SSD iaf använda mer av det.

Wear-algoritm ser till att disken lastas relativt jämnt, så även om Windows läser samma filer om och om igen, och du fortsätter att lägga in nya spel, nya filmer, nya bilder, så kommer de statiska filerna roteras och allt NAND slitas relativt jämt. Detta kan du inte på RAM... eller på Optane, utan att förstöra hela latensen och fördelarna du själv nämner ovan.

Skrivet av Yoshman:

Ser därför inte riktigt fördelen av detta på desktop. Eller ser absolut fördel med SRT men ser inte att Optane skulle ge någon relevant vinst över SRT med en NAND-disk sittandes på SATA eller NVMe.

Förstår inte heller din aviga inställning till SRT. SSHD diskarna hade potential, men den potentialen utnyttjandes aldrig då man nästan uteslutande använde en allt för liten NAND-cache (typiskt 8 GB). Kör själv SRT på min speldator, har en 60 GB SSD-cache (en SSD jag hittade i en låda) mot en 1 TB 2,5" laptop-disk (har en mini-ITX låda + tycker 3,5" diskar låter för mycket).

Prestandamässigt är 1 TB 2,5" horribel, men i praktiken blir det väldigt nära prestanda motsvarande 60 GB SSD. Då använder jag denna disk som lagring av mitt Steam-bibliotek medan OS och övriga program ligger på en 256 GB 850 EVO disk. D.v.s. tanken med SSHD var inte fel, men det är kritiskt att cachen är stor nog att kunna hålla all data som man regelmässigt använder.

Tror du har missuppfattat mig. Cache lösning likt SRT har jag själv använt förr, och till bekanta, och den är helt klart användbar och bra. Det jag har emot det är att använda en överprisat pytteliten Optane för det, när det inte ger mycket fördel för en klient med HDD + det. Det är helt klart en bra budget teknik så man slipper köpa stora SSDer, utan kan köra på mindre SSD + det.

Ev kan jag se nyttan med en Optane som sitter med större "långsam" SATA SSD som systemdisk och vill ha lite lägre latens, men jag tror ändå inte på konceptet att offra sin enda M.2 plats för det, vs att bara köpa till en system M.2 SSD av lämplig storlek och använda SATA SSDn som speldisk tex. Det gör liksom mer nytta i praktiken, och kräver inte just 200-seriens kort och CPU + Win 10 och att vara systemdisk.

Men när kraven är så höga, känns det lite meningslöst.

Skrivet av Yoshman:

16 GB lär vara för lite idag, 32 GB kanske fungerar men är inte helt säker (beror på vad man gör så klart) så skeptiskt till Optane diskarna i denna artikel. 60 GB är fortfarande tillräckligt stort för att hålla ett par moderna spel, inget spel använder ju all data som installeras hela tiden.

Det man vinner med SSD/Optane cache för en mekanisk disk är främst brutal ökad IOPS-kapacitet vid låga ködjup. Även en rätt medioker SSD har >100x högre IOPS jämfört med en mekanisk disk vid 4k random read QD=1. Ser dock inte riktigt att fördelen med Optane blir relevant över en SSD ens sittande på SATA utanför nischfall.

Håller med dig ang storleken också, 16GB känns... värdelöst för priset. 32GB är även det rätt lite, men på blocknivå klarar det iaf en enkel dator relativt bra, tills tyngre spel kommer in i bilden.

Du vinner även fördelen att små skrivningar av OSet inte stör en större läsning (om du har aktiverat prestanda skrivningen i SRT). Det hjälper en hel del vid tex Windows update, då den konstant ska skriva till små loggfiler, som annars kan sega ner en HDD rätt bra. Och en gammal Vertex 60GB fungerar bra för tex en 1TB 7200 RPM speldisk...

Men Optane i dess nuvarande form... är verkligen totalt värdelös. Den är som en mellanpunkt som inte riktigt är användbar någonstans.

Nu med mitt 5775c spelmaskin bygge så valde jag dock att gå helt på SSD, så jag lyckats skaffa det som behövdes. Så jag har 1TB System och lagring (850 Pro), 2TB spel... (850 Pro) :p, 1TB arbetsdisk (840 EVO) och 400GB inspelning av spelsessioner (S3700).

Även om jag hade kunnat sätta Optane i denna, ser jag liksom inte poängen, då det enda som skulle boostas är just systemdisken (pga dens begränsning), och om Windows disken har lite lägre latency än en 850 PRO tror jag är rätt meningslöst. Och som RAM.... hell no.

PS. Ledsen till alla för WoT... Är något som brukar ske med poster med @Yoshman

Typo...
Permalänk
Datavetare
Skrivet av Paddanx:

Som sagt, i en servermiljö kan utan tvekan Optane bli mer användbar. Men jag har två kritiska tvivel som måste tas i aspekt, som du kanske har svar på?

Ena är... prestandan. det är helt klart ett "stort-långsamt-ramminne", men även om du kan adressera på en byte nivå, så kommer ju all access ändå att bli med lägre bandbredd och lägre prestanda än riktigt RAM. Du får dock en "fördel/nackdel" att du måste kunna hantera fel via ECC, samt fel vid "omstart". Ska du blanka minnet helt då eller, eftersom det inte tappar data vid strömförlust.

Tömmer du det så sliter du ju på det, och tömmer du inte det så måste ju all kod skivas om så den kan hantera en "uppstart" utan en... "normal uppstart".

Andra är... slitage. Din punkt 2 ovan är rätt fel tänkt, och låt mig förklara varför jag tror det. De säger "30 Drive Wites Per Day" på (nu 3), senare 5 år är nivån. Så 5år*365*30DWPD*375GB = ca 20k TBW, eller 20PB, vilket är mycket mer än NAND, okej, så långt allt bra.

Sen skapar vi en 30GB stor databas i denna.. och du skriver till denna med låt oss säga de 250MB/s du nämner nedan... Om vi antar att du skriver exakt lika mycket till varje del (vilket ju är perfekt miljö, men inte realistisk) så kommer du ändå bara använda 30GB av detta större Optane pga du "modifierar på byte nivå". Så du skriver ca 250MB/s i QD1, till effektivt en 30GB "disk".

250MB/s*3600*24, dvs hela 21,6TB per dag... Men du skriver inte det till 375GB disk, utan till 30GB, då Optane adresseras och hanteras sektor för sektor, vilket är varför prestandan är så låg, dvs.. ingen Wear-algoritm.

Så tar vi formeln ovan och ersätter 375GB med 30GB, får vi plötsligt bara 1,64PB... och om vi nu använder lägsta QD1 så tittar vi på 1640TB / 21.6TB per dag = 75 dagar... Så din dvindyra Optane disk har 30GB skadade utslitna sektorer och "felmeddelande" efter 2,5 månad. Inte direkt lovande för RAM huh?

Så alla fördelar med att kunna adressera på bit nivå, allt prat om RAM och hur Optane är så mycket snabbare... du kan ju ffs inte använda prestandan?!!? Att du just kan modifiera samma bit om och om igen gör att man tom på dagar eller tom timmar kan slita ut enstaka "byte" celler på detta, när resten av disken är oanvänd.

Även om vi tittar på säg hela disken @ 250MB/s, så blir det ändå 20000TBW/21.6 per dag = 925 dagar. Så även om du på något magiskt sätt använder allt "perfekt jämt", så är den i lägsta kö-djup, redan död inom 2,5år.

Så... vad Intel säger är: Här har du en disk som "klarar konstant" 500k IOPS, men du kan max skriva 125MB/s (31k IOPS) i snitt, för att hålla 5 års garantinivån, annars sliter du ut den för snabbt, tom räknat med en wear-leveling teknik du inte ens har som RAM. Wtf...

Finns inte en chans att detta kan användas som RAM... skojar du? Inte i nuvarande skick iaf.
Hur i hela friden ska du effektivt kunna använda detta när du i RAM inte styr verken slitage nivå eller var du skriver data och pga skrivtoleansen knappt ens kan matcha en HDD i snitt vs RAM som har typ 20GB/s+.

Med det sagt... du kan säkert hitta ett specifikt skriver fall där det hjälper, men det är lite som att säga att för det speciella fallet av USA kärnvapen fortfarande styrs av 8" floppy disketter. Man kan alltid hitta knäppa miljöer, men det betyder inte att en produkt är bra.

Optane är en flopp som initial produkt. Som teknik och möjlighet, hoppas jag den kan gå bättre än många andra av Intels tekniker. Men vi kan ta Intels RDRAM (Rambus) eller IA64, som ex på hur Intels "bättre" teknik ändå dör, då den inte fungerar så kostnadseffektivt i praktiken som man trodde. Thunderbolt höll ju på att dö den med, men verkar nu med sin mer öppna approach kunna överleva.

Så då går vi tillbaka till läsning. För att läsa är ju som sagt inga problem, det kan både NAND och Optane göra i typ evigheter... om inte cellurladdning eller liknande påverkar så klart.

Men personer som gillar Optane (som du ovan) verkar stirra sig blind på att man ska just läsa på kö-djup 1-2, på servernivå, vilket inte riktigt är något jag förstår. Viktigaste måste väl vara att du har en låg och konstant latency, vilket dock är Optanes enda fördel... och ja.. enda. I skrivning så blir detta ju ett problem med infon ovan...

Men hur mycket kodning måste du inte göra om du nu plötslig måste gå från RAM access till ROM access? Det kan omöjligt bli effektivt nog att ersätta det... iaf med dagens mjukvara/teknik. Det kan ersätta en SSD i prestanda, men inte i storlek/pris på långa vägar... så det hamnar i en konstig mellanväg där det är för dyrt för att användas, men inte snabbt nog för att vara värt att använda.

SSDerna kan ju skriva sin last mer än nog bra idag, och en Optane SSD är mer eller mindre lika användbart som en S3700 är som klient-disk med sett till sitt eMLC och förbättrade skrivtolerans. Man använder den inte... men med optane är ju hela poängen att man ska använda det, men inte kan. För även om NAND helt klart har sämre skrivtolerans än Optane (och sämre IOPS), så kan en SSD iaf använda mer av det.

Wear-algoritm ser till att disken lastas relativt jämnt, så även om Windows läser samma filer om och om igen, och du fortsätter att lägga in nya spel, nya filmer, nya bilder, så kommer de statiska filerna roteras och allt NAND slitas relativt jämt. Detta kan du inte på RAM... eller på Optane, utan att förstöra hela latensen och fördelarna du själv nämner ovan.

Tror du har missuppfattat mig. Cache lösning likt SRT har jag själv använt förr, och till bekanta, och den är helt klart användbar och bra. Det jag har emot det är att använda en överprisat pytteliten Optane för det, när det inte ger mycket fördel för en klient med HDD + det. Det är helt klart en bra budget teknik så man slipper köpa stora SSDer, utan kan köra på mindre SSD + det.

Ev kan jag se nyttan med en Optane som sitter med större "långsam" SATA SSD som systemdisk och vill ha lite lägre latens, men jag tror ändå inte på konceptet att offra sin enda M.2 plats för det, vs att bara köpa till en system M.2 SSD av lämplig storlek och använda SATA SSDn som speldisk tex. Det gör liksom mer nytta i praktiken, och kräver inte just 200-seriens kort och CPU + Win 10 och att vara systemdisk.

Men när kraven är så höga, känns det lite meningslöst.

Håller med dig ang storleken också, 16GB känns... värdelöst för priset. 32GB är även det rätt lite, men på blocknivå klarar det iaf en enkel dator relativt bra, tills tyngre spel kommer in i bilden.

Du vinner även fördelen att små skrivningar av OSet inte stör en större läsning (om du har aktiverat prestanda skrivningen i SRT). Det hjälper en hel del vid tex Windows update, då den konstant ska skriva till små loggfiler, som annars kan sega ner en HDD rätt bra. Och en gammal Vertex 60GB fungerar bra för tex en 1TB 7200 RPM speldisk...

Men Optane i dess nuvarande form... är verkligen totalt värdelös. Den är som en mellanpunkt som inte riktigt är användbar någonstans.

Nu med mitt 5775c spelmaskin bygge så valde jag dock att gå helt på SSD, så jag lyckats skaffa det som behövdes. Så jag har 1TB System och lagring (850 Pro), 2TB spel... (850 Pro) :p, 1TB arbetsdisk (840 EVO) och 400GB inspelning av spelsessioner (S3700).

Även om jag hade kunnat sätta Optane i denna, ser jag liksom inte poängen, då det enda som skulle boostas är just systemdisken (pga dens begränsning), och om Windows disken har lite lägre latency än en 850 PRO tror jag är rätt meningslöst. Och som RAM.... hell no.

PS. Ledsen till alla för WoT... Är något som brukar ske med poster med @Yoshman

Du får rätta mig om jag har fel här, men är väl ändå så att 3D-Xpoint tål fler skrivningar än NAND? Och de bästa NAND-diskarna har samma peak IOPS som Optane. Är då även NAND-diskarna värdelösa enligt dig för de kommer ju dö ännu snabbare?

Eller realistiskt, varför skulle man 24/7 ha max IOPS och detta helt dedicerat mot skrivning? Finns det någon realistisk verklig arbetslast som ens är i närheten av något sådant?

Som jag förstår det är överhuvudtaget skrivkapaciteten och även latensen för skrivningar inte lika fördelaktiga för 3D-Xpoint som läsning när man jämför med NAND. Det use-case jag helt tänker mig är read-mostly databaser, kör man då 3D-Xpoint direkt på RAM-bussen har man ju access till hela sin databas direkt i programmet utan att gå via långsamma och CPU-krävande (i dessa hastigheter blir det CPU-krävande) I/O-operationer.

Att idag utrusta sin server med 1 TB RAM eller mer gör RAM till den överlägset dyraste komponenten. Så även om 3D-Xpoint är "dyrt" är det en piss i Mississippi jämfört med DRAM i motsvarande storlek.

Nu är det möjligt att minnesmappa en disk, men under huven måste ändå OS-kärnan översätta det till I/O-operationer så är ändå inte i närheten lika snabbt som om minnet sitter direkt som RAM. OSet kommer självklart förstå att vissa fysiska minnesadresser är 3D-Xpoint, så ur den aspekten är det inga problem att hålla isär DRAM och 3D-Xpoint.

Ser inte heller varför det skulle vara ett problem att se till att varje cell skrivs jämnt, det vare sig om man kör den som disk (finns en mappning i kontroller mellan logisk och fysisk minnesadress) och RAM (CPUn jobbar med virtuella adresser som via en MMU mappas till fysiska adresser). Är tvärt om rätt enkelt att få perfekt spridning av skrivningar över celler, denna spridning gör man av praktiska skäl på en större nivå än bytes (som RAM blir ju det naturligt gränsen samma som en "page", d.v.s. 4 kB, 2 MB eller 1 GB).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

@Yoshman:
@Paddanx:

Min förståelse är att denna produkt är enbart för PC och hemanvändare, ej för server(?)

Anledningar:

  • Om en "boost" önskas till en server så bör man "bara" köpa till 16GB eller 32GB RAM istället. (eller vilken mängd som behövs)
    Visst sparar inte RAM data efter omstart MEN då en server är oftast tänkt att vara på 24/7 så har en server ingen större nytta av just "Boot-boost" funktionen/prestandan. Då innebär det att all data enbart behöves läses in 1 gång efter boot och sedan har man boosten till sina applikationer.

  • RAM har klart bättre prestanda och slits inte som NAND minnen kan göra.

  • RAM kostar mer än SSD/NAND vid inköp, men troligtvis inte mer om man räknar TCO (totala kostnaden) för server (antar jag i vanliga fall)

slitage tänket bör beräknas och utgå ifrån en hemma PC användare då?
I.s.f. tänker jag att i första hand så cache:as allt i RAM (när data lämnar CPU), därefter vid cachemiss så sker ett anrop till disk och då agerar denna Intel cache-disk som "lagringsbar-RAM" mellan RAM och lagrings-Disk.
Om jag har topologin någorlunda korrekt beskrivet så är det inte så himla mycket som skrivs till Optane cache-disken så att slitage blir ett större problem? (Igen, för hemmaanvändare och PC)
Jag antar att Intels cache-disk INTE lagrar all ny data som CPU:n anropar som också saknas i RAM, att den enbart lagrar data som den märker att användare anropar tillräckligt ofta och inte finns i RAM för att det ska vara intressant att behålla. Anropas det oftare så skyfflas denna data (antagligen) till RAM istället och då slits det ännu mindre på Optane disken.

Utöver dessa antaganden så antar jag också att Intel använder sin kunskap och teknik gällande "cache predictions" från CPU cache design fast troligtvis något mer anpassat för Optane, för att vara effektiv och då slita mindre på Optane disken.

Så med alla mina antagen så är slitage inget problem för Optane vid hemma-PC användandet såvida användare inte har 1GB RAM och inte swap:ar ihjäl systemet

Permalänk
Medlem

Som produkten är idag så liknar jag den med ReadyBoost som lanserades med Windows Vista. Ett USBminne för att snabba upp datorn istället för att köpa mer RAM (som då var relativt dyrt). Samma här, istället för att köpa dyrare SSD så köper man en enhet som cachear mellan cpu/minne och disk. ReadyBoost floppade ganska hårt då priserna på RAM gick ner och kommer Optane fortsätta att vara en cache-funktion till mekaniska diskar så tror jag inte det kommer vara någon ljus framtid.

Visa signatur

.: Learn the system, Play the system, Break the system :.

Permalänk
Medlem

@Stealthbomb: Är Intel seriösa med det? Men det står ju högst upp i samma bild att det fungerar med "dual-drive configuration" med SSD+HDD? Är den andra disken värdelös då?

Permalänk
Skrivet av ggalaxyy:

Enheten är ju till för servrar.

Nej, det finns ju serverkort, det här är ju M.2 versionen som är gjord just för massmarknaden, exakt därför de visar den här typen av prestanda i marknadsföringen, servrar skulle hellre använda PCIe slot eller något annat interface än M.2

Visa signatur

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X

Permalänk
Skrivet av ggalaxyy:

Ja det är väl där dom är tänka att sitta också..? Hemma NASar och servrar.

Skrivet av ggalaxyy:

Enheten är ju till för servrar.

Och det är knappast så att NASar ens stödjer Optane. De måste ju faktiskt ha:
1. en M.2 plats
2. Kaby Lake CPU

Så nej, den här är helt klart inte gjord för hemma NAS:ar en NAS är knappast något man ser till att hålla uppdaterad med jämna mellanrum för att ha senaste teknologin, och vad fan spelar boot time för roll egentligen när en NAS bara är till för lagring? Nej det här verkar vara ett alternativ till en OS SSD.

Visa signatur

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X

Permalänk
Skrivet av Paddanx:

@kelthar Notera att den sidan, dessa 1000x osv... var allt hype. Hype som inte kunde hållas utan de har idag extremt meningslös prestandaskillnad för konsumenter.

Det finns specifika serverändamål som de kan bli användbara i dock, men det är specifika krav man ställer då.

För 500kr/800kr får du ju en 120/250GB SSD idag, och de gör otroligt mycket mer nytta pga upp till 8x större storlek. Du kan tom ta din 250GB SSD, använda Intels Smart Response och göra en 16-64GB cache på denna SSD för en mekanisk disk, och sen göra en ca 110-210GB* SSD för systemet av en 250GB SSD, och få båda fördelarna för priset av en 32GB Optane.

Och visst, Optane kommer helt klart ha bättre accesstid, men ärligt... att ha hela systemet på en SSD + en cache för din HDD för samma pris som ändå är snabbt, är det inte mer vettigt? De 32GB kommer ju vara extremt begränsade och bara hjälpa vissa delar, medan SSDn kan boosta hela Windows, och cachen ändå hjälpa spelen.

Jag satte ihop en 1TB HDD + en gammal Vertex 3 60GB SSD för en vän med Intel Smart Response för ett tag sedan. Prestandan var faktiskt helt okej, och definitivt snabbare än ren HDD, med snabb Windows boot och allt kändes rappt. Efter 1,5 år dog HDDn... SSDn lever än dock.

*Du kan göra större, men du bör lämna utrymme för dens cache att jobba effektivt, så räkna ca 2x cachens utrymme, med lika mycket tomt opartitionerat utrymme som cache storleken, för optimal nivå. Så en 32GB Cache behöver ytterligare 32GB opartitionerat utrymme.

Du måste ju ändå punga ut 500kr+ för optane enheten... och du kan göra exakt samma teknik med en billigare 120GB SSD (eller mindre) för lägre kostnad och all mjukvara finns redan i Intels moderkort och är beprövad i antal år.

Du behöver inte ens ett 200-series moderkort, utan kan göra det i Z170/H170, Z97/H97, Z87/H87, Z77/H77 och Z68 (ev fler), så inga pengar behövs heller läggas på nytt system om du har någon av dessa.

@Bloodstainer De gör detta eftersom Optane har "floppat". De har inte kunnat leverera vad de ursprungligen tänkte, eller prestandan/fördelarna de hoppats. Vanligt NAND har helt enkelt utvecklats till att bli snabbt och prisvärt nog för att konkurrera på annat sätt än man trodde.

Iden med Optane var inte dum, och den kommer säkert hitta sin nytta, men om det tar 10ns eller 0,1ms (100ns) för en sektor att bli läst i Windows för en hemanvändare märks inte. Redan en usel SSD på 0,5ms är mer än snabb nog för att "lyfta ett system" över en HDD. Och för 16/32GB vs 120/250/500GB+ är det ju helt NAND SSDs fördel.

Även om jag håller med dig om dina punkter, så skulle jag vilja säga att jag tror att Optane har en marknad, och det är billiga, nybyggen. För till exempel en butiksdator eller kontorsdatorer där man inte vill betala för höga priser på SSDer. Och i laptops där SSD lagring oftast är för liten i de nedre segmentet, och jag skulle gärna vilja ha en 16gb eller 32gb optane disk och en 1-2TB HDD i en laptop. Många budget laptops idag upp till 7000kr prislappen kommer ju tyvärr bara med 128gb SSD lagring. Vilket känns lite "meh"

Men ja, jag håller med, detta känns som ett försök att revolutionera SSD disken igen, och jag tror bara att detta var ett försök att visa "Caching är sjukt viktigt för servrar" medans man glömmer bort hur mycket DRAM och SSD caching redan gör. och tyvärr är ju Optane långsammare än DRAM så jag känner inte att de är icke-volatilt är en tillräckligt stor selling point.

Dock så kommer jag bygga en dator för en butik snart, och där kan jag hitta en eventuell användarområde för just Optane diskar, men hamnar inte priser under 650kr så kommer jag nog bara välja en M.2 SSD istället.

Visa signatur

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X

Permalänk
Datavetare
Skrivet av SolidReactor:

@Yoshman:
@Paddanx:

Min förståelse är att denna produkt är enbart för PC och hemanvändare, ej för server(?)

Anledningar:

  • Om en "boost" önskas till en server så bör man "bara" köpa till 16GB eller 32GB RAM istället. (eller vilken mängd som behövs)
    Visst sparar inte RAM data efter omstart MEN då en server är oftast tänkt att vara på 24/7 så har en server ingen större nytta av just "Boot-boost" funktionen/prestandan. Då innebär det att all data enbart behöves läses in 1 gång efter boot och sedan har man boosten till sina applikationer.

  • RAM har klart bättre prestanda och slits inte som NAND minnen kan göra.

  • RAM kostar mer än SSD/NAND vid inköp, men troligtvis inte mer om man räknar TCO (totala kostnaden) för server (antar jag i vanliga fall)

slitage tänket bör beräknas och utgå ifrån en hemma PC användare då?
I.s.f. tänker jag att i första hand så cache:as allt i RAM (när data lämnar CPU), därefter vid cachemiss så sker ett anrop till disk och då agerar denna Intel cache-disk som "lagringsbar-RAM" mellan RAM och lagrings-Disk.
Om jag har topologin någorlunda korrekt beskrivet så är det inte så himla mycket som skrivs till Optane cache-disken så att slitage blir ett större problem? (Igen, för hemmaanvändare och PC)
Jag antar att Intels cache-disk INTE lagrar all ny data som CPU:n anropar som också saknas i RAM, att den enbart lagrar data som den märker att användare anropar tillräckligt ofta och inte finns i RAM för att det ska vara intressant att behålla. Anropas det oftare så skyfflas denna data (antagligen) till RAM istället och då slits det ännu mindre på Optane disken.

Utöver dessa antaganden så antar jag också att Intel använder sin kunskap och teknik gällande "cache predictions" från CPU cache design fast troligtvis något mer anpassat för Optane, för att vara effektiv och då slita mindre på Optane disken.

Så med alla mina antagen så är slitage inget problem för Optane vid hemma-PC användandet såvida användare inte har 1GB RAM och inte swap:ar ihjäl systemet

Tror det mest är så att jag och @Paddanx är överens med flera andra i denna tråd: vår syn är att produkterna i denna artikel har väldigt tvivelaktigt värde (NAND över SATA fungera i praktiken i princip lika bra som cache för en mekanisk HD och det kan användas på alla plattformar, inte bara Z270). Så vi övergick till att diskutera 3D-Xpoint tekniken i ett bredare perspektiv.

Har överhuvudtaget svårt att riktigt se en "killer-app" för 3D-Xpoint för konsumenter. På servers finns det flera "killer-apps" för tekniken, den som ligger närmast är att använda Optane-diskar (som måste ha terrabyte storlek) som databaslagring av data som man ofta läser, där mängden data kanske inte är gigantiskt med antalet poster man behöver är enormt. Inte alls ett ovanligt fall och i det läget blir man helt bunden av accesslatens.

Men den riktiga "killer-appen" är att använda 3D-Xpoint som RAM. I det läget slipper man översätta data från en format lämpligt för disklagring till ett format lämpligt för CPU. Man lagrar helt enkelt sina datastrukturer i RAM som backas av 3D-Xpoint, det är ju persistent så är ju redan lagrat "på disk". I detta läge får man även full utväxling på den faktor 100 3D-Xpoint har i lägre latens, så länge man kör över NVMe blir ju NVMe-gränssnittet den dominerade faktor för latens med 3D-Xpoint.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Quizmästare Gävle 2022

Någon som minns "Robson"?
Gick ju sådär med det också..

Visa signatur
Permalänk
Medlem
Skrivet av Yoshman:

Du får rätta mig om jag har fel här, men är väl ändå så att 3D-Xpoint tål fler skrivningar än NAND? Och de bästa NAND-diskarna har samma peak IOPS som Optane. Är då även NAND-diskarna värdelösa enligt dig för de kommer ju dö ännu snabbare?

Som du borde ha kunnat läsa i den posten du citerar:
"SSDerna kan ju skriva sin last mer än nog bra idag, och en Optane SSD är mer eller mindre lika användbart som en S3700 är som klient-disk med sett till sitt eMLC och förbättrade skrivtolerans."

Så jag säger inte att en SSD baserad på Optane är sämre, tvärt om. Men det är inget man som klient användare använder. Som server SSD är det dock en bra lösning, men du får då nackdelarna som du själv tar upp:

"Problemet är att även fast NVMe har låg latens jämfört med tidigare gränssnitt är det fortfarande så att latens som kommer från NVMe-kontrollen är den dominerande faktorn för 3D-Xpoint."

Så... hela argumentet där, handlar om RAM, inte SSD:
"I praktiken är latensen bara 5-10 gånger lägre än de snabbast NAND-baserade enheterna, för att nå 100x måste man få in denna teknik direkt i RAM-moduler (och först då de två sista punkterna överhuvudtaget blir relevanta)."

Jag tog dock de enda skrivtålighets värdena vi officiellt har på en Optane enhet som bas för beräkningen, då det är de enda riktiga siffrorna som finns som inte är hypade från Intel. Skillnaden mellan den 375GB disken och 1TB RAM, är... ca 3x storleken. Det är dock samma "chip" av Optane under huven, och samma begränsningar i skrivtålighet.

Skrivet av Yoshman:

Eller realistiskt, varför skulle man 24/7 ha max IOPS och detta helt dedicerat mot skrivning? Finns det någon realistisk verklig arbetslast som ens är i närheten av något sådant?

Vem har påstått något med max IOPs?
Jag tog det lägsta QD1 värdet du angav som data, 250MB/s, som är 62,5k IOPs, vilket bara på denna SSD är 12,5% av dens kapacitet, som den ska (enligt uppgifter) kunna hålla konstant (som alla tycker är så fantastiskt). Detta är något tom en SATA SSD kan leverera, dock i högre kö-djup. Och när vi ser det som RAM är ju 62,5k IOPs "en piss i Mississippi" som du så bra säger det nedan, då du just också ska få lägre latencyn som var anledningen ovan.

Så matten ovan som visar "att den omöjligt kan hantera ett RAMs användning på 2,5år", är baserat på just detta... Så ska du få samma livslängd på ditt nya RAM, som en enterprise klassad HDD/SSD på 5 år, får du max använda ca 30k IOPs på ditt nya "375GB RAM" i skrivning, vilket verkligen är löjligt lite och fullständigt oanvändbart.

Tar du "värsta fall" (som du trodde detta var), dvs 24/7 max IOPS på ca 500k IOPS och på 1TB RAM: 500 000*4kB*3600*24 = ca 172TB/dag (dvs något högre än de 30 de anger som "normalt" inom garantin). Med 1TB RAM och 30DWPD: 30*365*5år = ca 55PB. 55PB/0.172 per dag = ca 320 dagar, och detta räknat med en perfekt slitage-algoritm på hela disken, något som är bättre än realistiskt eller verkligt.

Om vi istället tar dess 30DWPD, som är garantin-nivån för 5år på ditt 1TB RAM så kan du använda: 30TB / 24 / 3600 = ca 350MB/s, eller 87 500 - 4k IOPS per dag i snitt. Det är mao som att använda en 850 PRO... till ca 100% i prestanda... som RAM skrivprestanda. RAM ligger normalt på vad, 20GB/s skrivning... vs 350MB/s?

Lägg till att när du som RAM kör, kommer direkta bit-adresseringen som du själv säger: "går effektivt att adressera ner på enskilda bytes, NAND består av relativt stora block", så kan du omöjligt göra en bra slitage-reglering utan andra nackdelar, om data skrivs på det sättet, vilket det gör i just RAM. Så de 350MB/s-87,5k IOPs ovan är mao... bästa fall scenario för att hålla garantinivån Intel har nu iaf.. Så vem pratar om realistiskt här? Det är ju bara QD1 på optane SSD disken...

Skrivet av Yoshman:

Som jag förstår det är överhuvudtaget skrivkapaciteten och även latensen för skrivningar inte lika fördelaktiga för 3D-Xpoint som läsning när man jämför med NAND. Det use-case jag helt tänker mig är read-mostly databaser, kör man då 3D-Xpoint direkt på RAM-bussen har man ju access till hela sin databas direkt i programmet utan att gå via långsamma och CPU-krävande (i dessa hastigheter blir det CPU-krävande) I/O-operationer.

Att idag utrusta sin server med 1 TB RAM eller mer gör RAM till den överlägset dyraste komponenten. Så även om 3D-Xpoint är "dyrt" är det en piss i Mississippi jämfört med DRAM i motsvarande storlek.

Och då är vi i dessa 8" floppy-disk miljöerna jag pratade om ovan. Du kan mao hitta udda miljöer där just Optane fungerar, det tvivlar jag inte alls på, men det gör dock inte produkten till något "användbart för alla servrar", utan bara för special fall.

Det gör bara specialfallets lösning till något man kan lappa ihop billigare med detta, där du dock måste vara försiktig som tusan med mängden skrivoperationer till denna databas, tex, men kan ha fördelar med just låg och jämn latens på läs-operationer. Du måste mao välja specifika lösningar för specifika databaser, och du måste som programmerare nu plötsligt tänka på att skriva det på annat ställe (tex riktigt RAM).

Den mest ideala lösningen är ju en RAM-ersättare som kan användas som just RAM, utan andra begränsningar, men det påstår jag, med bla beräkningarna gjorda, att Optane är totalt flopp på. Lyckas de förbättra eller fixa det i framtida versioner? Ingen aning. Men även 100k P/E är inget för vad RAM gör tom i en klientmaskin, så vi måste upp i flera miljoner P/E.

Skrivet av Yoshman:

Nu är det möjligt att minnesmappa en disk, men under huven måste ändå OS-kärnan översätta det till I/O-operationer så är ändå inte i närheten lika snabbt som om minnet sitter direkt som RAM. OSet kommer självklart förstå att vissa fysiska minnesadresser är 3D-Xpoint, så ur den aspekten är det inga problem att hålla isär DRAM och 3D-Xpoint.

Detta är lite vad jag syftar på här, för du säger det som att det bara är att "plugga in"... klart, vilket är en löjlig underskattning. Du måste både programmera denna hantering av adresserna, och hela den hanteringen lägger en latens lager på din database som helhel, inkl RAM access. Att det kommer gå att skilja på har jag inga tvivel på, men hur du gör det effektivt, utan att behöva skriva om hela hanteringen av ditt RAM är var jag tappar bort dig...

Skrivet av Yoshman:

Ser inte heller varför det skulle vara ett problem att se till att varje cell skrivs jämnt, det vare sig om man kör den som disk (finns en mappning i kontroller mellan logisk och fysisk minnesadress) och RAM (CPUn jobbar med virtuella adresser som via en MMU mappas till fysiska adresser). Är tvärt om rätt enkelt att få perfekt spridning av skrivningar över celler, denna spridning gör man av praktiska skäl på en större nivå än bytes (som RAM blir ju det naturligt gränsen samma som en "page", d.v.s. 4 kB, 2 MB eller 1 GB).

Åter igen... du antar detta, utan att tänka på konsekvenserna i praktiken.
Om du kan adressera och ändra på byte nivå, och du ska göra wear-algoritmer, så behöver du ju hålla reda på antal skrivningar på byte nivå, så kommer du att behöva enorma mängder utrymme för att lagra och hålla reda på hur mycket varje del av varje cell är sliten.

Så du behöver hålla reda på slitaget för 1TB "celler"... med vad? 1TB till? Tänk på att bara för de stora blocken som en SSD har idag, så har de ändå typ 1GB/TB RAM för just denna "adressering" och Metadata. Ska du göra blocken så små som du vill ha i RAM, så blir det stort problem och enorma mängder data och extremt ineffektivt.

Och ska du göra det till en "page" så kommer vi tillbaka till att du kanske skriver om samma "page" om och om och om igen, och då sliter ut just den biten fortare än grannens "page". Här kan du dock göra en algoritm, men då kommer nästa problem.

- Om gör du det med CPUn så kommer du behöva offra CPU resurser för att gör slitage-algoritm... inte direkt optimalt för att ha låg latens eller effektiva serverar. Och var ska du lagra denna info som kommer öka mängden skrivningar?

- Om du gör det via en kontroller, som SSD tex, så får du ju samma problem som just med Optane som SSD, dvs ett lager mellan som kostar dig 10x eller högre latenser. Något du själv sa är varför man gör det som RAM.

Så problemet här att du verkligen försöker äta kakan och ha den kvar samtidigt.

Optane har helt klart fördelar som inte NAND eller RAM har, men samtidigt får det stora nackdelar om den används som RAM/SSD, som gör den en halvdålig ersättare till båda. Som SSD tappar du låga latensen, och du får en svindyr NAND SSD, utan egentligen mycket andra fördelar. Som RAM kommer du nästan behöva använda det som special ROM del för att inte slita ut det, eller i extremt specialskrivna programmiljöer.

Håller med dig fullständigt i #16750063 dock

Permalänk
Medlem
Skrivet av Bloodstainer:

Även om jag håller med dig om dina punkter, så skulle jag vilja säga att jag tror att Optane har en marknad, och det är billiga, nybyggen. För till exempel en butiksdator eller kontorsdatorer där man inte vill betala för höga priser på SSDer. Och i laptops där SSD lagring oftast är för liten i de nedre segmentet, och jag skulle gärna vilja ha en 16gb eller 32gb optane disk och en 1-2TB HDD i en laptop. Många budget laptops idag upp till 7000kr prislappen kommer ju tyvärr bara med 128gb SSD lagring. Vilket känns lite "meh"

Delvis håller jag med dig, men som sagt, det du beskriver är inget nytt. Det har använts i laptops sedan 2011... Fanns massor med maskiner som körde just 20-32GB SSD + 500-1000GB HDD, och dessa använder en cache som typ Smart Response. En snabb titt på Ebay visar också dessa olika SSD lösningar.

Att idag göra liknande skedde fortfarande typ 2015-2016, men då lödde man fast NANDet på moderkortet istället. Och med tanke på att du kan få kapslar med hela 512GB SSD i ett chip, med kontroller och allt inbyggt, så kan du väldigt billigt få en liten SSD som cache till en HDD.

Problemet är att en HDD + bärbart media är döende tänk. HDDn tål inte rörelser och den är för tjock. Den kostar också i mindre storlekar som en billig OEM SSD, vilket gör att 250GB SSD har idag börjat ta över detta helt.

På en stationär/laptop, som har 2 SATA platser iaf, och ett av de SRT kompatibla chippen, så kan du redan idag själv slänga in en 500GB-3TB HDD och en valfri SSD och köra som jag har beskrivit ovan, oavsett Windows/Linux, då det sker på blocknivå.

Så att betala extra pengar för 32GB optane vs en SSD ger så lite vinst, att det är bortkastade pengar, både för OEM som kör budget och för dig som vill bygga billig lagring. Du kan dessutom använda det på en icke systemdisk, något Optane tydligen inte kan.

Skrivet av Bloodstainer:

Men ja, jag håller med, detta känns som ett försök att revolutionera SSD disken igen, och jag tror bara att detta var ett försök att visa "Caching är sjukt viktigt för servrar" medans man glömmer bort hur mycket DRAM och SSD caching redan gör. och tyvärr är ju Optane långsammare än DRAM så jag känner inte att de är icke-volatilt är en tillräckligt stor selling point.

Dock så kommer jag bygga en dator för en butik snart, och där kan jag hitta en eventuell användarområde för just Optane diskar, men hamnar inte priser under 650kr så kommer jag nog bara välja en M.2 SSD istället.

Enda jag såg skulle kunna hamna under 650kr är ju 16GB... och då är inte ens HDDn inräknad. Räknar du med HDD + Optane så är du redan uppe och börjar sniffa på 250-500GB SSD i pris. För en dator som "bara ska gå" behövs inte direkt en M.2 SSD heller, utan en enkel SATA räcker och blir över många gånger om om du inte behöver mer prestanda.

Och behöver du den prestandan från början, så förstår jag inte varför ens en HDD är med i bilden, eller tänkte du boosta en SSD?

Permalänk
Datavetare
Skrivet av Paddanx:

Som du borde ha kunnat läsa i den posten du citerar:
"SSDerna kan ju skriva sin last mer än nog bra idag, och en Optane SSD är mer eller mindre lika användbart som en S3700 är som klient-disk med sett till sitt eMLC och förbättrade skrivtolerans."

Så jag säger inte att en SSD baserad på Optane är sämre, tvärt om. Men det är inget man som klient användare använder. Som server SSD är det dock en bra lösning, men du får då nackdelarna som du själv tar upp:

"Problemet är att även fast NVMe har låg latens jämfört med tidigare gränssnitt är det fortfarande så att latens som kommer från NVMe-kontrollen är den dominerande faktorn för 3D-Xpoint."

Så... hela argumentet där, handlar om RAM, inte SSD:
"I praktiken är latensen bara 5-10 gånger lägre än de snabbast NAND-baserade enheterna, för att nå 100x måste man få in denna teknik direkt i RAM-moduler (och först då de två sista punkterna överhuvudtaget blir relevanta)."

Jag tog dock de enda skrivtålighets värdena vi officiellt har på en Optane enhet som bas för beräkningen, då det är de enda riktiga siffrorna som finns som inte är hypade från Intel. Skillnaden mellan den 375GB disken och 1TB RAM, är... ca 3x storleken. Det är dock samma "chip" av Optane under huven, och samma begränsningar i skrivtålighet.

Vem har påstått något med max IOPs?
Jag tog det lägsta QD1 värdet du angav som data, 250MB/s, som är 62,5k IOPs, vilket bara på denna SSD är 12,5% av dens kapacitet, som den ska (enligt uppgifter) kunna hålla konstant (som alla tycker är så fantastiskt). Detta är något tom en SATA SSD kan leverera, dock i högre kö-djup. Och när vi ser det som RAM är ju 62,5k IOPs "en piss i Mississippi" som du så bra säger det nedan, då du just också ska få lägre latencyn som var anledningen ovan.

Så matten ovan som visar "att den omöjligt kan hantera ett RAMs användning på 2,5år", är baserat på just detta... Så ska du få samma livslängd på ditt nya RAM, som en enterprise klassad HDD/SSD på 5 år, får du max använda ca 30k IOPs på ditt nya "375GB RAM" i skrivning, vilket verkligen är löjligt lite och fullständigt oanvändbart.

Tar du "värsta fall" (som du trodde detta var), dvs 24/7 max IOPS på ca 500k IOPS och på 1TB RAM: 500 000*4kB*3600*24 = ca 172TB/dag (dvs något högre än de 30 de anger som "normalt" inom garantin). Med 1TB RAM och 30DWPD: 30*365*5år = ca 55PB. 55PB/0.172 per dag = ca 320 dagar, och detta räknat med en perfekt slitage-algoritm på hela disken, något som är bättre än realistiskt eller verkligt.

Om vi istället tar dess 30DWPD, som är garantin-nivån för 5år på ditt 1TB RAM så kan du använda: 30TB / 24 / 3600 = ca 350MB/s, eller 87 500 - 4k IOPS per dag i snitt. Det är mao som att använda en 850 PRO... till ca 100% i prestanda... som RAM skrivprestanda. RAM ligger normalt på vad, 20GB/s skrivning... vs 350MB/s?

Lägg till att när du som RAM kör, kommer direkta bit-adresseringen som du själv säger: "går effektivt att adressera ner på enskilda bytes, NAND består av relativt stora block", så kan du omöjligt göra en bra slitage-reglering utan andra nackdelar, om data skrivs på det sättet, vilket det gör i just RAM. Så de 350MB/s-87,5k IOPs ovan är mao... bästa fall scenario för att hålla garantinivån Intel har nu iaf.. Så vem pratar om realistiskt här? Det är ju bara QD1 på optane SSD disken...

Och då är vi i dessa 8" floppy-disk miljöerna jag pratade om ovan. Du kan mao hitta udda miljöer där just Optane fungerar, det tvivlar jag inte alls på, men det gör dock inte produkten till något "användbart för alla servrar", utan bara för special fall.

Det gör bara specialfallets lösning till något man kan lappa ihop billigare med detta, där du dock måste vara försiktig som tusan med mängden skrivoperationer till denna databas, tex, men kan ha fördelar med just låg och jämn latens på läs-operationer. Du måste mao välja specifika lösningar för specifika databaser, och du måste som programmerare nu plötsligt tänka på att skriva det på annat ställe (tex riktigt RAM).

Den mest ideala lösningen är ju en RAM-ersättare som kan användas som just RAM, utan andra begränsningar, men det påstår jag, med bla beräkningarna gjorda, att Optane är totalt flopp på. Lyckas de förbättra eller fixa det i framtida versioner? Ingen aning. Men även 100k P/E är inget för vad RAM gör tom i en klientmaskin, så vi måste upp i flera miljoner P/E.

Detta är lite vad jag syftar på här, för du säger det som att det bara är att "plugga in"... klart, vilket är en löjlig underskattning. Du måste både programmera denna hantering av adresserna, och hela den hanteringen lägger en latens lager på din database som helhel, inkl RAM access. Att det kommer gå att skilja på har jag inga tvivel på, men hur du gör det effektivt, utan att behöva skriva om hela hanteringen av ditt RAM är var jag tappar bort dig...

Åter igen... du antar detta, utan att tänka på konsekvenserna i praktiken.
Om du kan adressera och ändra på byte nivå, och du ska göra wear-algoritmer, så behöver du ju hålla reda på antal skrivningar på byte nivå, så kommer du att behöva enorma mängder utrymme för att lagra och hålla reda på hur mycket varje del av varje cell är sliten.

Så du behöver hålla reda på slitaget för 1TB "celler"... med vad? 1TB till? Tänk på att bara för de stora blocken som en SSD har idag, så har de ändå typ 1GB/TB RAM för just denna "adressering" och Metadata. Ska du göra blocken så små som du vill ha i RAM, så blir det stort problem och enorma mängder data och extremt ineffektivt.

Och ska du göra det till en "page" så kommer vi tillbaka till att du kanske skriver om samma "page" om och om och om igen, och då sliter ut just den biten fortare än grannens "page". Här kan du dock göra en algoritm, men då kommer nästa problem.

- Om gör du det med CPUn så kommer du behöva offra CPU resurser för att gör slitage-algoritm... inte direkt optimalt för att ha låg latens eller effektiva serverar. Och var ska du lagra denna info som kommer öka mängden skrivningar?

- Om du gör det via en kontroller, som SSD tex, så får du ju samma problem som just med Optane som SSD, dvs ett lager mellan som kostar dig 10x eller högre latenser. Något du själv sa är varför man gör det som RAM.

Så problemet här att du verkligen försöker äta kakan och ha den kvar samtidigt.

Optane har helt klart fördelar som inte NAND eller RAM har, men samtidigt får det stora nackdelar om den används som RAM/SSD, som gör den en halvdålig ersättare till båda. Som SSD tappar du låga latensen, och du får en svindyr NAND SSD, utan egentligen mycket andra fördelar. Som RAM kommer du nästan behöva använda det som special ROM del för att inte slita ut det, eller i extremt specialskrivna programmiljöer.

Håller med dig fullständigt i #16750063 dock

DRAM kan adresseras på bytenivå, ändå hanterar OS endast RAM på page-nivå när det kommer till virtuell till fysisk översättning. Så här är manegen redan krattad för 3D-Xpoint.

Och redan idag betyder vissa fysiska minnesadresser något helt annat än läsa/skriva till DRAM, grafikkort, nätverkskort, ljudkort etc är alla mappade på fysiska minnesadresser. Så som OS-utvecklare ser jag inte det minsta problem att vissa fysiska adresser motsvarar DRAM och vissa 3D-Xpoint, det är ett problem som OS-utvecklare löste på 70-talet.

Pratar man i stället diskar har ju alla NAND och rimligtvis även Optane-diskarna en kontrollkrets som översätter mellan logiska adresser och fysiska adresser. Så även här är ju problemet med att sprida ut skrivningarna jämnt redan ett löst problem. I disk-fallet finns ingen fördel för 3D-Xpoint att kunna adresseras på bytenivå, OS klassar diskar som "block-devices" så OSet kommer alltid läsa/skriva data som block för hela disk-I/O-systemet är designat kring den abstraktionen. Det är ännu en orsak till varför 3D-Xpoint aldrig kan nå sin fulla potential när det används som disk.

Sedan blir ditt "worst-case" totalt orealistiskt, vad är poängen med 100 % skrivningar? Om man aldrig läser informationen som skrivs är det ju rätt meningslöst. Redan 2:1 läsning:skrivning anses vara VÄLDIG hög andel skrivningar, om 2 utav 3 IOPS är läsning blir det enligt din worst-case uträkning 7,5 år som disken lever vilket få anses helt inom rimlighetens gräns.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

DRAM kan adresseras på bytenivå, ändå hanterar OS endast RAM på page-nivå när det kommer till virtuell till fysisk översättning. Så här är manegen redan krattad för 3D-Xpoint.

Och redan idag betyder vissa fysiska minnesadresser något helt annat än läsa/skriva till DRAM, grafikkort, nätverkskort, ljudkort etc är alla mappade på fysiska minnesadresser. Så som OS-utvecklare ser jag inte det minsta problem att vissa fysiska adresser motsvarar DRAM och vissa 3D-Xpoint, det är ett problem som OS-utvecklare löste på 70-talet.

Dock är samtliga av dessa RAM utan begränsning. Dvs du sliter inte ut grafikkortes minne genom att adressera och använda den. Men okej, du anser det inte som RAM som i Systemets primär RAM, utan som någon form av sekundär RAM som normalt bara används av specifika tjänster/mjukvara, då är jag med.

Men du inser väl ändå att du nu i den specialmjukvaran måste bygga ett form av mjukvarulager som håller koll på slitaget? Eller hur tänkte du göra wear-leveling i adressform? Inget av detta behövs, eller finns för verken DRAM, grafikkort, Nätverkskort, Ljudkort osv... Alla antas kunna läsa/skriva obegränsade antal gånger.

Skrivet av Yoshman:

Pratar man i stället diskar har ju alla NAND och rimligtvis även Optane-diskarna en kontrollkrets som översätter mellan logiska adresser och fysiska adresser. Så även här är ju problemet med att sprida ut skrivningarna jämnt redan ett löst problem. I disk-fallet finns ingen fördel för 3D-Xpoint att kunna adresseras på bytenivå, OS klassar diskar som "block-devices" så OSet kommer alltid läsa/skriva data som block för hela disk-I/O-systemet är designat kring den abstraktionen. Det är ännu en orsak till varför 3D-Xpoint aldrig kan nå sin fulla potential när det används som disk.

Och detta har jag som sagt inte argumenterat emot, utan vi är överens när det gäller SSD delen.

Skrivet av Yoshman:

Sedan blir ditt "worst-case" totalt orealistiskt, vad är poängen med 100 % skrivningar? Om man aldrig läser informationen som skrivs är det ju rätt meningslöst. Redan 2:1 läsning:skrivning anses vara VÄLDIG hög andel skrivningar, om 2 utav 3 IOPS är läsning blir det enligt din worst-case uträkning 7,5 år som disken lever vilket få anses helt inom rimlighetens gräns.

7,5år skulle jag gärna vilja se matten på...
Garantin på 5 år tillåter 87 500 - 4k IOPS per dag i snitt i skrivning, betyder det att du räknar med ca 180k IOPS läsning.. på RAM? Låter rätt lågt räknat med tanke på att du nyligen stod o sa att latencyn i dessa uppgifter blir största flaskhalsen och att den då kan nå ner till 1/100 av NAND, vilket ju också gör IOPs i runda slängar 100x högre v

Men okej, vi kör ditt tankesätt, så 1TB RAM Optane, 30DWPD (troliga TWB nivån), och 1:5 (20/80 skriv/läs), en rätt normal sits för serverlast.

Så du kommer då läsa i runda slänga av 437k IOPs, eller 1,75GB/s, vilket den klarar utan problem. Tom så pass att den lär klara mer än det, eller hur? Tom SSDn P4800X kan ge 550k IOPs/s... Som RAM med 10x lägre latency lär vi prata 2,5-5M IOPs i teorin (fortfarande läsning).

Men om vi då kör 1:5 kommer vi överstiga de värdena rejält ovan. Så vi pratar inte 2:3, 1:5, utan vi pratar 87,5k vs dens IOPs i RAM. Och ska man tro Intel och dig så pratar vi lätt 1M IOPs, kanske mer. Så vi pratar minst 1:10... kanske tom 1:20. Mer än det så passerar vi garantinivån för 5 år.

Så du sitter här och säger att du tycker och tror att du kommer köra en mjukvara som till 95% läser, och 5% skriver till en databas och då inte ens räknat med någon overhead alls. Vilken databas skriver så lite på 5 år? Är ju nästan ROM baserat. Eller är det vad du räknat med?

Permalänk
Datavetare
Skrivet av Paddanx:

Dock är samtliga av dessa RAM utan begränsning. Dvs du sliter inte ut grafikkortes minne genom att adressera och använda den. Men okej, du anser det inte som RAM som i Systemets primär RAM, utan som någon form av sekundär RAM som normalt bara används av specifika tjänster/mjukvara, då är jag med.

Men du inser väl ändå att du nu i den specialmjukvaran måste bygga ett form av mjukvarulager som håller koll på slitaget? Eller hur tänkte du göra wear-leveling i adressform? Inget av detta behövs, eller finns för verken DRAM, grafikkort, Nätverkskort, Ljudkort osv... Alla antas kunna läsa/skriva obegränsade antal gånger.

Och detta har jag som sagt inte argumenterat emot, utan vi är överens när det gäller SSD delen.

7,5år skulle jag gärna vilja se matten på...
Garantin på 5 år tillåter 87 500 - 4k IOPS per dag i snitt i skrivning, betyder det att du räknar med ca 180k IOPS läsning.. på RAM? Låter rätt lågt räknat med tanke på att du nyligen stod o sa att latencyn i dessa uppgifter blir största flaskhalsen och att den då kan nå ner till 1/100 av NAND, vilket ju också gör IOPs i runda slängar 100x högre v

Men okej, vi kör ditt tankesätt, så 1TB RAM Optane, 30DWPD (troliga TWB nivån), och 1:5 (20/80 skriv/läs), en rätt normal sits för serverlast.

Så du kommer då läsa i runda slänga av 437k IOPs, eller 1,75GB/s, vilket den klarar utan problem. Tom så pass att den lär klara mer än det, eller hur? Tom SSDn P4800X kan ge 550k IOPs/s... Som RAM med 10x lägre latency lär vi prata 2,5-5M IOPs i teorin (fortfarande läsning).

Men om vi då kör 1:5 kommer vi överstiga de värdena rejält ovan. Så vi pratar inte 2:3, 1:5, utan vi pratar 87,5k vs dens IOPs i RAM. Och ska man tro Intel och dig så pratar vi lätt 1M IOPs, kanske mer. Så vi pratar minst 1:10... kanske tom 1:20. Mer än det så passerar vi garantinivån för 5 år.

Så du sitter här och säger att du tycker och tror att du kommer köra en mjukvara som till 95% läser, och 5% skriver till en databas och då inte ens räknat med någon overhead alls. Vilken databas skriver så lite på 5 år? Är ju nästan ROM baserat. Eller är det vad du räknat med?

Jag gjorde ingen matematik alls, utgick från att din uträckning var korrekt och som jag förstod den skulle man då skriva sönder disken på 2,5 år om man skrev konstant i peak IOPS. Om två utan av tre IOPS i stället är läsning så blir det 7,5 år med samma antal IOPS.

Fallet "read-mostly" data är ju i praktiken extremt vanligt. Största vinsten 3D-Xpoint ger som RAM i detta fall är ju att man kan ha långt mer fysiskt RAM vid en viss budget då 3D-Point är långt billigare än DRAM per byte. Idag är ju alternativet endera att lägga en massiv summa på RAM (>1 TB RAM gör priset på övriga komponenter till ett rätt litet problem) eller så får man minnesmappa disken vilket inte är i närheten lika snabbt som 3D-Xpoint sittandes på RAM-bussen (i praktiken kopierar OSet in data page-för-page i DRAM för den del man jobbar med för tillfället, är allt för segt att direkt jobba mot disk, så här är ännu en fördel med 3D-Xpoint i form av att data direkt hamnar i non-volatil RAM alt. så har man DRAM-cache även här för bättre prestanda och färre skrivningar mot NVRAM).

Hanteringen rent logiskt är ju trivial, i normalfallet är allt minne program ser DRAM. Sedan måste det finnas ett separat anrop som mappar upp fysiskt 3D-Xpoint RAM i processens virtuella minnesrymd. Faktum är att man rent teoretiskt dynamiskt skulle kunna skifta denna minnesarea mellan att vara DRAM-backat och 3D-Xpoint-backat, applikationen skulle inte se någon skillnad alls bortsett från prestanda.

Allt stöd för detta finns redan i dagens OS. Skriver man högpresterande nätverksapplikationer är det i bl.a. Linux möjligt att mappa in minnet som nätverkskortet använder som sänd/mottagarbuffertar. För applikationen hanteras den minnesarean precis som vilket minne som helst, är ju MMUn som sköter allt och OSet som bestämt hur MMUn är konfigurerad. Så biten att DRAM och 3D-Xpoint finns i samma system är ett totalt icke-problem.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Jag gjorde ingen matematik alls, utgick från att din uträckning var korrekt och som jag förstod den skulle man då skriva sönder disken på 2,5 år om man skrev konstant i peak IOPS. Om två utan av tre IOPS i stället är läsning så blir det 7,5 år med samma antal IOPS.

"Även om vi tittar på säg hela disken @ 250MB/s, så blir det ändå 20000TBW/21.6 per dag = 925 dagar. Så även om du på något magiskt sätt använder allt "perfekt jämt", så är den i lägsta kö-djup, redan död inom 2,5år."

Du missade nog en del... 250MB/s, så 62.5k IOPS i QD1. Är det max den klarar nu? Så du påstår att din Optane "RAM-disk" har sämre skriv-IOPs prestanda än min 850 SATA SSD? Detta är nyhet för mig...

Det enda jag inte gjort är räkna med läsning. Varför?, pga hur påverkar den? Du kan läsa oändligt antal gånger, och du kan läsa 8 gånger snabbare än denna nivån tom på deras SSD, så det spelar ingen roll om du kör 100% skrivning eller 12,5% skrivning i det fallet... Min poäng att du på den "då" 375GB Optane SSDn, endast kan skriva i SATA SSD nivå ändå, innan det slits ut, typ som SLC NAND.

Skrivet av Yoshman:

Fallet "read-mostly" data är ju i praktiken extremt vanligt. Största vinsten 3D-Xpoint ger som RAM i detta fall är ju att man kan ha långt mer fysiskt RAM vid en viss budget då 3D-Point är långt billigare än DRAM per byte. Idag är ju alternativet endera att lägga en massiv summa på RAM (>1 TB RAM gör priset på övriga komponenter till ett rätt litet problem) eller så får man minnesmappa disken vilket inte är i närheten lika snabbt som 3D-Xpoint sittandes på RAM-bussen (i praktiken kopierar OSet in data page-för-page i DRAM för den del man jobbar med för tillfället, är allt för segt att direkt jobba mot disk, så här är ännu en fördel med 3D-Xpoint i form av att data direkt hamnar i non-volatil RAM alt. så har man DRAM-cache även här för bättre prestanda och färre skrivningar mot NVRAM).

Okej... De databaser jag jobbat med är mer 1:5 i bästa fall iaf, ofta närmare 1:3, där en kund skriver in något tex i en bokning och sen ligger den där och de har en lokal cache, och det är sällan de läser allt, utan att skriva ny info. Så om du tror du kan hitta en databas med 1:20, så okej, då kan det fungera. Känns ändå lite som 8" floppy...

Skrivet av Yoshman:

Hanteringen rent logiskt är ju trivial, i normalfallet är allt minne program ser DRAM. Sedan måste det finnas ett separat anrop som mappar upp fysiskt 3D-Xpoint RAM i processens virtuella minnesrymd. Faktum är att man rent teoretiskt dynamiskt skulle kunna skifta denna minnesarea mellan att vara DRAM-backat och 3D-Xpoint-backat, applikationen skulle inte se någon skillnad alls bortsett från prestanda.

Okej, så du lägger mao ett lager mellan denna hantering... som jag precis ovan sa, kostar CPU resurser och sämre latency (då den måste hitta vf det är lagrat i en egen databas, och sen hitta datan).

Skrivet av Yoshman:

Allt stöd för detta finns redan i dagens OS. Skriver man högpresterande nätverksapplikationer är det i bl.a. Linux möjligt att mappa in minnet som nätverkskortet använder som sänd/mottagarbuffertar. För applikationen hanteras den minnesarean precis som vilket minne som helst, är ju MMUn som sköter allt och OSet som bestämt hur MMUn är konfigurerad. Så biten att DRAM och 3D-Xpoint finns i samma system är ett totalt icke-problem.

Men åter... slits nätverkskortets buffert sönder efter ett visst antal skrivningar? Det är ju där komplexiteten börjar, och plötsligt krävs det lagret du skrev ovan, och sen hantering av slitage-hantering på det. Att du kan adressera det är ju inte problemet, att du måste adressera det med helt andra spelregler är ju problemet. Och ja... det går i "8-tums floppy världen" att lösa, men det gör ändå Optane totalt värdelöst som RAM ersättare, utom i just den speciella miljön du beskriver ovan, vilket är min poäng sedan första posten.

@Yoshman Btw kolla in detta (Länk från FYNXER), så ser du att tom Intel inte ens verkar vilka stå för sin egen Optane disk specs längre. Så hade jag varit dig hade jag inte litat ett skit på Optane tills man får 3:e part info, för det verkar mer och mer "bull-shit" från Intel när de försöker gömma och förfalska info.

Vi kan även justera ner även mina hemska beräkningar ovan med denna info (Intels spec)... TBW 12,3PB... inte ens de 20PB du trodde gav 2,5år ovan, utan vi är nere på ca 1,5år nu, för 250MB/s-62,5k IOPs. Vi är rätt skrämmande nära eMLC NAND nu.

Lagt till lite mer info.
Permalänk
Datavetare
Skrivet av Paddanx:

"Även om vi tittar på säg hela disken @ 250MB/s, så blir det ändå 20000TBW/21.6 per dag = 925 dagar. Så även om du på något magiskt sätt använder allt "perfekt jämt", så är den i lägsta kö-djup, redan död inom 2,5år."

Du missade nog en del... 250MB/s, så 62.5k IOPS i QD1. Är det max den klarar nu? Så du påstår att din Optane "RAM-disk" har sämre skriv-IOPs prestanda än min 850 SATA SSD? Detta är nyhet för mig...

Det enda jag inte gjort är räkna med läsning. Varför?, pga hur påverkar den? Du kan läsa oändligt antal gånger, och du kan läsa 8 gånger snabbare än denna nivån tom på deras SSD, så det spelar ingen roll om du kör 100% skrivning eller 12,5% skrivning i det fallet... Min poäng att du på den "då" 375GB Optane SSDn, endast kan skriva i SATA SSD nivå ändå, innan det slits ut, typ som SLC NAND.

Okej... De databaser jag jobbat med är mer 1:5 i bästa fall iaf, ofta närmare 1:3, där en kund skriver in något tex i en bokning och sen ligger den där och de har en lokal cache, och det är sällan de läser allt, utan att skriva ny info. Så om du tror du kan hitta en databas med 1:20, så okej, då kan det fungera. Känns ändå lite som 8" floppy...

Okej, så du lägger mao ett lager mellan denna hantering... som jag precis ovan sa, kostar CPU resurser och sämre latency (då den måste hitta vf det är lagrat i en egen databas, och sen hitta datan).

Men åter... slits nätverkskortets buffert sönder efter ett visst antal skrivningar? Det är ju där komplexiteten börjar, och plötsligt krävs det lagret du skrev ovan, och sen hantering av slitage-hantering på det. Att du kan adressera det är ju inte problemet, att du måste adressera det med helt andra spelregler är ju problemet. Och ja... det går i "8-tums floppy världen" att lösa, men det gör ändå Optane totalt värdelöst som RAM ersättare, utom i just den speciella miljön du beskriver ovan, vilket är min poäng sedan första posten.

@Yoshman Btw kolla in detta (Länk från FYNXER), så ser du att tom Intel inte ens verkar vilka stå för sin egen Optane disk specs längre. Så hade jag varit dig hade jag inte litat ett skit på Optane tills man får 3:e part info, för det verkar mer och mer "bull-shit" från Intel när de försöker gömma och förfalska info.

Vi kan även justera ner även mina hemska beräkningar ovan med denna info (Intels spec)... TBW 12,3PB... inte ens de 20PB du trodde gav 2,5år ovan, utan vi är nere på ca 1,5år nu, för 250MB/s-62,5k IOPs. Vi är rätt skrämmande nära eMLC NAND nu.

Håller inte på speciellt mycket med databaser, så har dåligt koll på det och har försökt läsa på lite. Idag finns ju varianter som Datomic som aldrig raderar en post utan bara lägger till. Läste lite om NoSQL och där beskrevs ett gäng typfall, bl.a. hade man 100 % läsning, 95 % läsning + 5 % tillägg, 95 % läsning + 5 % modifiering som typfall (man hade även 50% läsning / 50 % skrivning som typfall, så finns nog alla varianter här).

Alla dessa fall går ju utan problem att hantera med 3D-Xpoint. Den stora fördel är att dessa fall nu kan ha hela databasen direkt i RAM vilket kommer öka antal transaktioner man kan göra per tidsenhet med tiopotenser mot vad är fallet idag.

Och hur löser man "vanliga" databaser om de skriver så ofta? Är ju trots allt så att NAND tål klart färre P/E-cykler jämfört med 3D-Xpoint. Kör man fortfarande magnetiska diskar i databas-servers?

Optane disken med 375 GB verkar tåla att man skriver totalt 12 PB, så har man då ett par TB som RAM kan man skriva ~100 PB (det med dagens nivå). Hur många servers finns det ute på företagen där man kommer skriva >100 PB under 3 år (antar att det är garantitiden, så tiden systemet ska överleva)? "killer-app" här är ju att långt mindre spelare än idag kan få råd att köpa en en server med RAM i TB nivå och man kan ha sitt ofta accessade data i minne. Lagrar man det sedan med någon persistent datastruktur har man data på ett format som bara orsakar skrivning när man lägger till information och det går att läsa från multipla trådar utan explicit synkronisering -> bättre nyttjandegrad av CPU med många kärnor.

Vidare: om man använder 3D-xpoint för att få enormt med RAM så skulle det ändå vara väldigt lönsamt att köra 3D-Xpoint över DRAM även om man måste byta ut minnet en gång per år. DRAM är mer än tio gånger dyrare om är ute efter TB kapacitet.

Varför anser du att det finns något extra lager mellan CPU och RAM? 3D-Xpoint skulle ju hanteras exakt på samma sätt som DRAM idag, det betyder att varje minnestransaktion översätts mellan virtuella och fysiska adresser men det är ju ingen EXTRA overhead över vad man alltid har. Det är ju en översättning som alla OS med minnesskydd hela tiden måste göra (och alla moderna OS använder minnesskydd för applikationer).

Finns också HW-stöd i alla moderna MMUer så att man enkelt och effektivt (i princip noll overhead i genomsnitt) kan beskriva sina "pages" på ett sätt så de som bara läses mappar direkt mot 3D-Xpoint och vid skrivning har man ett "working-set" av DRAM-utrymme. Är bara när man måste återanvända en skrivnings-page som man skriver ut innehållet mot 3D-Xpoint, det virtuella minne man ofta skriver till är backat mot DRAM. En sådan lösning är enkel att göra (d.v.s. det är ett löst problem), applikationen behöver inte göra någonting utan policy för detta dikteras helt av OS. Detta är helt analogt med hur en minnasmappad disk fungerar, skillnaden är att motsvarande "flush-to-disk" operationen kommer vara ~100 gånger snabbare.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk

Kanske slänger in en sån att komplettera min vanliga SSD med.
Men med dessa storlekar, ja, då blir det endast till "pagefile" och diverse "temp filer/mappar".

Visa signatur

Dator: EEE901 N270/ 1GB / 20GB SSD ... Kraftigt nedbantat/tweakat Win7 x86 for speeeEED!
Facebook användare? Hatar tidslinjen? gå med i denna FB-grupp:
Undo Timeline ...med lite tur får h*lvetet ett slut!

Permalänk
Medlem
Skrivet av Yoshman:

Håller inte på speciellt mycket med databaser, så har dåligt koll på det och har försökt läsa på lite. Idag finns ju varianter som Datomic som aldrig raderar en post utan bara lägger till. Läste lite om NoSQL och där beskrevs ett gäng typfall, bl.a. hade man 100 % läsning, 95 % läsning + 5 % tillägg, 95 % läsning + 5 % modifiering som typfall (man hade även 50% läsning / 50 % skrivning som typfall, så finns nog alla varianter här).

5% versioner lär nog fungera, men andra, nej.

Skrivet av Yoshman:

Alla dessa fall går ju utan problem att hantera med 3D-Xpoint. Den stora fördel är att dessa fall nu kan ha hela databasen direkt i RAM vilket kommer öka antal transaktioner man kan göra per tidsenhet med tiopotenser mot vad är fallet idag.

Och hur löser man "vanliga" databaser om de skriver så ofta? Är ju trots allt så att NAND tål klart färre P/E-cykler jämfört med 3D-Xpoint. Kör man fortfarande magnetiska diskar i databas-servers?

Kör du bara 1TB lagring?
Du kör NAND med både inbyggd wear-leveling, samt flera gånger mer NAND med RAID. Du skriver dessutom de flesta transaktioner mot just... RAM, inte disk.

Skrivet av Yoshman:

Optane disken med 375 GB verkar tåla att man skriver totalt 12 PB, så har man då ett par TB som RAM kan man skriva ~100 PB (det med dagens nivå). Hur många servers finns det ute på företagen där man kommer skriva >100 PB under 3 år (antar att det är garantitiden, så tiden systemet ska överleva)? "killer-app" här är ju att långt mindre spelare än idag kan få råd att köpa en en server med RAM i TB nivå och man kan ha sitt ofta accessade data i minne.

Så du antar att du använder dagens nivå, trots att du flertalet gånger ovan säger att du vill ha just RAM för att öka prestanda. Är lite som att trimma motorn och tro att den drar lika lite bränsle.

Du också har nu gått från 375GB till "flera TB", så jag antar att du "kompenserar" verklighetens problem, genom att 3-dubbla mängden RAM, men på något magiskt sätt.., ändå inte förbruka mer skrivningar. Vem är det nu som har orealistiska scenario.

Du antar att man kommer använda RAM prestanda, mindre än SATA prestanda, vilket jag inte förstår hur du kan anse det användbart, när du själv säger att det just är en flaskhals.

Skrivet av Yoshman:

Lagrar man det sedan med någon persistent datastruktur har man data på ett format som bara orsakar skrivning när man lägger till information och det går att läsa från multipla trådar utan explicit synkronisering -> bättre nyttjandegrad av CPU med många kärnor.

Vidare: om man använder 3D-xpoint för att få enormt med RAM så skulle det ändå vara väldigt lönsamt att köra 3D-Xpoint över DRAM även om man måste byta ut minnet en gång per år. DRAM är mer än tio gånger dyrare om är ute efter TB kapacitet.

Där har vi ju den hantering jag har undrat över från början. Just att du har en lösning som kan minska skrivningarna så att det kan gå. Varför har du inte tagit upp detta tidigare undrar jag.

Oavsett så vet jag inte var du får tio-gånger dyrare priser ifrån, men om de inte är hämtade ur luften, utan stämmer, så okej, då kan jag förstå din situation. Det är mer ekonomiskt att behöva återställa databasen från backup, stänga ner allt man gör i en dag, byta Xpoint minnet varje år och sen upp och få igång allt. Det visste jag inte.

Skrivet av Yoshman:

Varför anser du att det finns något extra lager mellan CPU och RAM? 3D-Xpoint skulle ju hanteras exakt på samma sätt som DRAM idag, det betyder att varje minnestransaktion översätts mellan virtuella och fysiska adresser men det är ju ingen EXTRA overhead över vad man alltid har. Det är ju en översättning som alla OS med minnesskydd hela tiden måste göra (och alla moderna OS använder minnesskydd för applikationer).

Wear-leveling finns inte i denna hantering idag. Även om du kan dedikera skrivning på ett annat sätt, så måste du ändå hantera denna slitage-algorim, med ett lager någonstans. Annars får du som sagt inte dina 100PB du fick fram från ingenstans ovan.

Skrivet av Yoshman:

Finns också HW-stöd i alla moderna MMUer så att man enkelt och effektivt (i princip noll overhead i genomsnitt) kan beskriva sina "pages" på ett sätt så de som bara läses mappar direkt mot 3D-Xpoint och vid skrivning har man ett "working-set" av DRAM-utrymme. Är bara när man måste återanvända en skrivnings-page som man skriver ut innehållet mot 3D-Xpoint, det virtuella minne man ofta skriver till är backat mot DRAM. En sådan lösning är enkel att göra (d.v.s. det är ett löst problem), applikationen behöver inte göra någonting utan policy för detta dikteras helt av OS. Detta är helt analogt med hur en minnasmappad disk fungerar, skillnaden är att motsvarande "flush-to-disk" operationen kommer vara ~100 gånger snabbare.

Okej, så du kan separera delar av X-point så att du hanterar skrivningarna optimalt, vilket då inte borde påverka läs latency iaf. Då börjar jag förstå hur du tänkt.

Permalänk
Medlem
Skrivet av Paddanx:

Okej... De databaser jag jobbat med är ... där en kund skriver in något tex i en bokning och sen ligger den där och de har en lokal cache, och det är sällan de läser allt, utan att skriva ny info.

Och den info som skrivs lagras i samma fil som formuläret, så varje gång formuläret öppnas medföljer all tidigare inskriven information?
Programmeras det som ett tomt formulär där inmatad data lagras i en stack eller liknande så är det ju bara det tomma formuläret som kommer hamna i cachen. Övriga data läses bara vid behov, alltså sällan, och användaren skriver (som jag uppfattat det) aldrig direkt till cachen.

Så som jag förstått det är hanteringen av cachen att datoranvändaren bara har läsrättigheter.
Skrivning till cachen sköts av styrprogrammet som avgör vilka lagrade filer (från HDD/SSD) som läses tillräckligt ofta för att kopieras till cachen. Det är fullt möjligt att styrprogrammet tycker att en fil räknas som "ny", och därmed hamnar sist i kön till cache, varje gång den modifieras.

Jag förväntar mig alltså att om en dator frekvent kör samma program med ett minimum av variation blir det väldigt lite skrivningar till cachen.

Permalänk
Datavetare
Skrivet av Paddanx:

5% versioner lär nog fungera, men andra, nej.

Kör du bara 1TB lagring?
Du kör NAND med både inbyggd wear-leveling, samt flera gånger mer NAND med RAID. Du skriver dessutom de flesta transaktioner mot just... RAM, inte disk.

Så du antar att du använder dagens nivå, trots att du flertalet gånger ovan säger att du vill ha just RAM för att öka prestanda. Är lite som att trimma motorn och tro att den drar lika lite bränsle.

Du också har nu gått från 375GB till "flera TB", så jag antar att du "kompenserar" verklighetens problem, genom att 3-dubbla mängden RAM, men på något magiskt sätt.., ändå inte förbruka mer skrivningar. Vem är det nu som har orealistiska scenario.

Du antar att man kommer använda RAM prestanda, mindre än SATA prestanda, vilket jag inte förstår hur du kan anse det användbart, när du själv säger att det just är en flaskhals.

Där har vi ju den hantering jag har undrat över från början. Just att du har en lösning som kan minska skrivningarna så att det kan gå. Varför har du inte tagit upp detta tidigare undrar jag.

Oavsett så vet jag inte var du får tio-gånger dyrare priser ifrån, men om de inte är hämtade ur luften, utan stämmer, så okej, då kan jag förstå din situation. Det är mer ekonomiskt att behöva återställa databasen från backup, stänga ner allt man gör i en dag, byta Xpoint minnet varje år och sen upp och få igång allt. Det visste jag inte.

Wear-leveling finns inte i denna hantering idag. Även om du kan dedikera skrivning på ett annat sätt, så måste du ändå hantera denna slitage-algorim, med ett lager någonstans. Annars får du som sagt inte dina 100PB du fick fram från ingenstans ovan.

Okej, så du kan separera delar av X-point så att du hanterar skrivningarna optimalt, vilket då inte borde påverka läs latency iaf. Då börjar jag förstå hur du tänkt.

Anledningen att jag lägger gränsen vid "flera TB" är då det är gränsen för hur mycket fysiskt RAM som går att ha i Xeon E5 idag. Givet priset för 3D-Xpoint minne verkar det rimligt att man i det läget lägger sig på maximal mängd fysiskt RAM, DRAM långt man har råd och fyll resten med 3D-Xpoint. Skylake Xeon E5 lyfter dagens 1,5 TB RAM per socket gräns till 6 TB RAM per socket, så max kapacitet blir 12 TB på en dual-socket maskin (som är rätt standard).

Det man vill åt är ju att kunna ha data som ofta används i RAM, även om man har en maskin med TB storlek på RAM så är ju DRAM volatilt så allt data måste hela tiden speglas mot disk. Med 3D-Xpoint är ju det data som ligger där icke-volatilt och även med en "DRAM cache" på de minnes-pages som skrivs mycket är kostnaden för att spegla data till NVRAM tiopotenser lägre än med NVMe.

MMUer tillåter ju att man sätter attribut på pages, så för 3D-Xpoint backat minne är ju en uppenbar default policy att alltid markera minnet som read-only (det gör man ofta även för DRAM för att implementera något som kalla copy-on-write, en optimering som undviker kopiering av RAM som logiskt är privat men man vet är samma för flera trådar/proceser så länge ingen skriver till minnet). Så åter igen ett "löst problem" och något som är helt HW-optimerat.

För 3D-Xpoint kan man då i stället utnyttja detta till att växla över till DRAM backade pages för sådant som nyligen modifierats, skrivning till en "read-only" page orsakar en anrop till OSet som då avgör vad som lämpligt händer. Läsningar behöver man överhuvudtaget inte bry sig om, de kommer fungerar riktigt bra "automatiskt" p.g.a. prefetching och cache i dagens CPUer.

Började fundera på hur de system jag använder dagligen fungerar när det kommer till datalagring. Inser att ALLA systemet är ju av formen: X reads och Y inserts.

Hur vanligt är det att man någonsin raderar data idag? Om man bara har läsningar och tillägg är ju P/E ett icke-problem då ingen cell kommer skrivas mer än en gång i genomsnitt. Detta pekar också att traditionella relationsdatabaser är idag "broken by design" på så många sätt (det var en bra idé på 80-90 talet när storlek på diskar kontra normal datamängd var en flaskhals). Datomic och liknande system är hur man idag borde hantera data idag (sättet Datomic hanterar data gör också en låg rad potentiell race-buggar, som är rätt vanliga när man använder relationsdatabaser, omöjliga).

Både NAND och 3D-Xpoint är ju väsentligt mycket billigare per byte än DRAM (som är väsentligt mycket billigare än SRAM). Så notera: säger inte att 3D-Xpoint är billigare än NAND, det är dyrare men i samma härad. Om NAND hade rent praktiskt fungerat att använda som RAM är jag övertygad att man redan gjort just p.g.a. att DRAM på TB-nivå blir extremt dyrt (gå in på någon server-site och konfigurera en server med 1-2 TB RAM, kolla prislappen...).

Och varför jag inte nämnde det tidigare kring MMU? Inläggen blir långa som det är, har ju ingen aning om vad folk generellt sett vet om hur CPUer fungerar. Just designen kring MMU är ju något som inte ändrats sedan 80-talet (fanns säker CPUer med MMU i IBMs labb redan på 60-talet), för mig är det därför en självklarhet så tänker inte på det. Men inser att de flesta har inte läst OS-design och än färre har jobbat med OS-utveckling.

Edit: implementera "wear-leveling" m.h.a. en MMU är ju trivialt. Dela upp allt fysiskt RAM som mappar mot 3D-Xpoint i page-stora chunks (detta måste ändå göras, man gör så med DRAM också). Se fritt minne som en cirkulär buffer, allokera genom att plocka i ena änden och fria genom att lägga i andra änden. Du har nu en LIFO buffert där du garanterat att alla page-chunk kommer användas helt jämt. Efter varje (eller kanske varje N för att riktigt minimera overhead) skrivning till en page friar man det fysiska minnet och byter ut det mot en nytt page-sized chunk (även här har man HW-stöd från MMU att göra denna book keeping).

Blir inte "wear-leveling" på bytenivå men väl på pagenivå (som normalt är 4k). Vidare så jobbar inte en CPU mot RAM med mindre chunk än cache-lines, vilket för dagens x86/ARM är 64 bytes.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Anledningen att jag lägger gränsen vid "flera TB" är då det är gränsen för hur mycket fysiskt RAM som går att ha i Xeon E5 idag. Givet priset för 3D-Xpoint minne verkar det rimligt att man i det läget lägger sig på maximal mängd fysiskt RAM, DRAM långt man har råd och fyll resten med 3D-Xpoint. Skylake Xeon E5 lyfter dagens 1,5 TB RAM per socket gräns till 6 TB RAM per socket, så max kapacitet blir 12 TB på en dual-socket maskin (som är rätt standard).

Det man vill åt är ju att kunna ha data som ofta används i RAM, även om man har en maskin med TB storlek på RAM så är ju DRAM volatilt så allt data måste hela tiden speglas mot disk. Med 3D-Xpoint är ju det data som ligger där icke-volatilt och även med en "DRAM cache" på de minnes-pages som skrivs mycket är kostnaden för att spegla data till NVRAM tiopotenser lägre än med NVMe.

MMUer tillåter ju att man sätter attribut på pages, så för 3D-Xpoint backat minne är ju en uppenbar default policy att alltid markera minnet som read-only (det gör man ofta även för DRAM för att implementera något som kalla copy-on-write, en optimering som undviker kopiering av RAM som logiskt är privat men man vet är samma för flera trådar/proceser så länge ingen skriver till minnet). Så åter igen ett "löst problem" och något som är helt HW-optimerat.

För 3D-Xpoint kan man då i stället utnyttja detta till att växla över till DRAM backade pages för sådant som nyligen modifierats, skrivning till en "read-only" page orsakar en anrop till OSet som då avgör vad som lämpligt händer. Läsningar behöver man överhuvudtaget inte bry sig om, de kommer fungerar riktigt bra "automatiskt" p.g.a. prefetching och cache i dagens CPUer.

Började fundera på hur de system jag använder dagligen fungerar när det kommer till datalagring. Inser att ALLA systemet är ju av formen: X reads och Y inserts.

Hur vanligt är det att man någonsin raderar data idag? Om man bara har läsningar och tillägg är ju P/E ett icke-problem då ingen cell kommer skrivas mer än en gång i genomsnitt. Detta pekar också att traditionella relationsdatabaser är idag "broken by design" på så många sätt (det var en bra idé på 80-90 talet när storlek på diskar kontra normal datamängd var en flaskhals). Datomic och liknande system är hur man idag borde hantera data idag (sättet Datomic hanterar data gör också en låg rad potentiell race-buggar, som är rätt vanliga när man använder relationsdatabaser, omöjliga).

Både NAND och 3D-Xpoint är ju väsentligt mycket billigare per byte än DRAM (som är väsentligt mycket billigare än SRAM). Så notera: säger inte att 3D-Xpoint är billigare än NAND, det är dyrare men i samma härad. Om NAND hade rent praktiskt fungerat att använda som RAM är jag övertygad att man redan gjort just p.g.a. att DRAM på TB-nivå blir extremt dyrt (gå in på någon server-site och konfigurera en server med 1-2 TB RAM, kolla prislappen...).

Och varför jag inte nämnde det tidigare kring MMU? Inläggen blir långa som det är, har ju ingen aning om vad folk generellt sett vet om hur CPUer fungerar. Just designen kring MMU är ju något som inte ändrats sedan 80-talet (fanns säker CPUer med MMU i IBMs labb redan på 60-talet), för mig är det därför en självklarhet så tänker inte på det. Men inser att de flesta har inte läst OS-design och än färre har jobbat med OS-utveckling.

Edit: implementera "wear-leveling" m.h.a. en MMU är ju trivialt. Dela upp allt fysiskt RAM som mappar mot 3D-Xpoint i page-stora chunks (detta måste ändå göras, man gör så med DRAM också). Se fritt minne som en cirkulär buffer, allokera genom att plocka i ena änden och fria genom att lägga i andra änden. Du har nu en LIFO buffert där du garanterat att alla page-chunk kommer användas helt jämt. Efter varje (eller kanske varje N för att riktigt minimera overhead) skrivning till en page friar man det fysiska minnet och byter ut det mot en nytt page-sized chunk (även här har man HW-stöd från MMU att göra denna book keeping).

Blir inte "wear-leveling" på bytenivå men väl på pagenivå (som normalt är 4k). Vidare så jobbar inte en CPU mot RAM med mindre chunk än cache-lines, vilket för dagens x86/ARM är 64 bytes.

Okej... jag köper ditt 8" floppy disk fall

Jag har som sagt mina tvivel till hållbarheten, då RAM fel normalt bara kan hanteras på bit nivå, inte hel 4k page som "försvunnit"/blivit korrupt, men det bör gå att lösa redundans på något sätt (syftar på när det väl slitits ut).

Och med priset i aspekt för detta specialfall så förstår jag att det kan finnas platser där Optane fungerar.

Det återstår väl nu mest och se vad det verkligen klarar. NAND klarade ju betydligt mer än man trodde, men då var vi just på SLC nivå och på typ 50nm+. Optane är ju redan på 20nm, och SLC, så det kan typ bara bli sämre (precis som NAND är idag).

Permalänk
Datavetare
Skrivet av Paddanx:

Okej... jag köper ditt 8" floppy disk fall

Jag har som sagt mina tvivel till hållbarheten, då RAM fel normalt bara kan hanteras på bit nivå, inte hel 4k page som "försvunnit"/blivit korrupt, men det bör gå att lösa redundans på något sätt (syftar på när det väl slitits ut).

Och med priset i aspekt för detta specialfall så förstår jag att det kan finnas platser där Optane fungerar.

Det återstår väl nu mest och se vad det verkligen klarar. NAND klarade ju betydligt mer än man trodde, men då var vi just på SLC nivå och på typ 50nm+. Optane är ju redan på 20nm, och SLC, så det kan typ bara bli sämre (precis som NAND är idag).

Vad betyder 8" floppy fallet? Är väl snarare att på den tiden när vi körde 8" floppy fanns det en poäng att designa databaser så de kunde byta ut innehåll då det inte fanns utrymme för allt. Idag kan vi i de flesta fall lagra precis allt, d.v.s vi kan nu hantera data som faktum (d.v.s. en notifiering om ett visst tillstånd, det är en konstant oberoende av tid).

En databas som kan förändra historien lagrar inte faktum och finns en lång rad saker som är svårt eller i många fall helt omöjliga att hantera om man inte jobbar med faktum. Vilken organisation vill inte kunna gå bakåt i tiden i sina lagrade data vid behov? När man jobbar på detta sätt (och det måste vara dit hela databasmarknaden går) skrivs ju varje cell max en gång om det är huvudlagring (blir ju fler gånger om lagringen är en form av cache).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Skrivet av Paddanx:

Delvis håller jag med dig, men som sagt, det du beskriver är inget nytt. Det har använts i laptops sedan 2011... Fanns massor med maskiner som körde just 20-32GB SSD + 500-1000GB HDD, och dessa använder en cache som typ Smart Response. En snabb titt på Ebay visar också dessa olika SSD lösningar.

Att idag göra liknande skedde fortfarande typ 2015-2016, men då lödde man fast NANDet på moderkortet istället. Och med tanke på att du kan få kapslar med hela 512GB SSD i ett chip, med kontroller och allt inbyggt, så kan du väldigt billigt få en liten SSD som cache till en HDD.

Problemet är att en HDD + bärbart media är döende tänk. HDDn tål inte rörelser och den är för tjock. Den kostar också i mindre storlekar som en billig OEM SSD, vilket gör att 250GB SSD har idag börjat ta över detta helt.

På en stationär/laptop, som har 2 SATA platser iaf, och ett av de SRT kompatibla chippen, så kan du redan idag själv slänga in en 500GB-3TB HDD och en valfri SSD och köra som jag har beskrivit ovan, oavsett Windows/Linux, då det sker på blocknivå.

Så att betala extra pengar för 32GB optane vs en SSD ger så lite vinst, att det är bortkastade pengar, både för OEM som kör budget och för dig som vill bygga billig lagring. Du kan dessutom använda det på en icke systemdisk, något Optane tydligen inte kan.

Enda jag såg skulle kunna hamna under 650kr är ju 16GB... och då är inte ens HDDn inräknad. Räknar du med HDD + Optane så är du redan uppe och börjar sniffa på 250-500GB SSD i pris. För en dator som "bara ska gå" behövs inte direkt en M.2 SSD heller, utan en enkel SATA räcker och blir över många gånger om om du inte behöver mer prestanda.

Och behöver du den prestandan från början, så förstår jag inte varför ens en HDD är med i bilden, eller tänkte du boosta en SSD?

Ja, alltså den anledning till att man skulle behöva en eller flera HDD med i bilden skulle ju eventuellt vara till exempel övervakningssystem bundet till datorn, att använda bara WD Purple diskar och optane t.ex.

https://www.inet.se/kundvagn/visa/10307103/

I t.ex. det här bygget, som jag har sparat i en kundvagn kan man t.ex. se hur man skulle kunna spara lite pengar på att använda Optane istället för en dyr M.2 SSD. Jag kan tänka mig att Optane fyller en marknad mellan "Jag vill inte använda stora SSD enheter" men vill kunna ha en snabb dator ändå, det är lite.. konstigt, det håller jag med om, men jag kan ändå tänka mig att skippa SSD diskar i t.ex. vissa specifika byggen, men tyvärr är Optane en flopp om man tittar på att använda de som jag hade tänkt, i en andra M.2 slot när man redan har en M.2 SSD, det verkar vara helt onödigt i dagsläget.

EDIT:

Okej, nu verkar det vara så att Optane endast stödjs av Core CPUer, dvs i3, i5 och i7.. vilket gör hela min idé ogiltig, haha. Back to M.2 SSDs it is. Nej om Intel skjuter sitt eget lågsegment i foten, så blir den lilla rutan på marknaden jag känner att Optane kunde fylla helt plötsligt icke existerande.

Nu ser jag inte längre varför någon skulle vilja ha den här typen av enheter om de inte går att använda i billiga byggen.

Visa signatur

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X