Linus Torvalds skyller ECC-döden på Intel

Permalänk
Medlem

Hade en filserver för ett tag sedan som fick tyst minneskorruption, började upptäcka konstiga fel i filer, och efter lite analyserande bara i sådana som jag visste att det skrivits i. Tog mig en stund att räkna ut att det var minnes fel då jag utöver nån enstaka hängning inte sett några andra konstigheter med maskinen, och inga antydningar i loggar.
Detta är rätt otrevligt då det nästan är omöjligt att kunna veta exakt vilka filer som påverkats, och dessutom när. Att man hade backuper hjälpte ju liksom inte då även dom såklart var korrupta då det förmodligen pågått under en längre tid.

Det vara sista filservern utan ECC för min del, passade även på att gå över till ZFS (Truenas) i samma veva, så nu borde risken vara betydligt lägre för fel, och blir det några lär jag förhoppningsvis se det.

När det gäller AMDs AM4 plattform stödjer dom ju officiellt ECC på Pro varianterna av CPUerna, så risken för att man skulle få nån dummy implementation som rapporterar att ECC är på fast det inte funkar tror jag inte på, även med icke Pro varianterna av Ryzen. Stödet finns ju uppenbarligen både i kislet, och i firmware, och enligt AMD finns det inget tekniskt som begränsar användningen i vanliga Ryzen proppar.

Permalänk
Inaktiv
Skrivet av ddelin:

Hade en filserver för ett tag sedan som fick tyst minneskorruption, började upptäcka konstiga fel i filer, och efter lite analyserande bara i sådana som jag visste att det skrivits i. Tog mig en stund att räkna ut att det var minnes fel då jag utöver nån enstaka hängning inte sett några andra konstigheter med maskinen, och inga antydningar i loggar.
Detta är rätt otrevligt då det nästan är omöjligt att kunna veta exakt vilka filer som påverkats, och dessutom när. Att man hade backuper hjälpte ju liksom inte då även dom såklart var korrupta då det förmodligen pågått under en längre tid.

Det vara sista filservern utan ECC för min del, passade även på att gå över till ZFS (Truenas) i samma veva, så nu borde risken vara betydligt lägre för fel, och blir det några lär jag förhoppningsvis se det.

När det gäller AMDs AM4 plattform stödjer dom ju officiellt ECC på Pro varianterna av CPUerna, så risken för att man skulle få nån dummy implementation som rapporterar att ECC är på fast det inte funkar tror jag inte på, även med icke Pro varianterna av Ryzen. Stödet finns ju uppenbarligen både i kislet, och i firmware, och enligt AMD finns det inget tekniskt som begränsar användningen i vanliga Ryzen proppar.

Hade varit ganska fint om även AMD erbjöd egna referensmoderkort som följer tanken bakom plattform, där officiellt ECC-stöd också erbjuds. Är inte partnertillverkarna inte intresserade så får AMD göra deras jobb helt enkelt.

Permalänk
Medlem
Skrivet av Yoshman:

Tänk igen och läs också vad Torvalds skrev i första inlägget: grejen med de fel som ECC kan rätta är att de i majoriteten av fallen är "tysta", d.v.s. oavsett hur teknik-kunnig man är kommer man inte kunna göra något åt felen då man inte ens kommer se dem. Det var min invändning mot det jag markerade.

I första inlägget klagar Torvalds specifikt på att vi aldrig kommer få veta hur vanligt fel som t.ex. Rowhammer faktiskt är då dessa är nästan alltid "osynliga" (i.e. de ger inget fel som kan observeras), vilket är en helt korrekt observation men som går i klinch med att man inte behöver ECC om man är "tech savy".

Just hur osynliga dessa fel normalt är (för felen händer i de flesta av våra maskiner som saknar ECC) belyser vilket icke-problem det egentligen är för normalanvändaren.

Jag fick inte bilden att han påstod att man inte behöver ECC om man är "tech savvy" utan att han menade att hans irritation inte kommer ifrån att han själv behöver ECC, något han förklarar med att han kan hantera eventulla problem som uppstår på grund av bitflips eller har koll nog att sätta upp sin egen rigg för att minimera risken.

Skrivet av Yoshman:

Zoomar man in specifikt på spelriggar kommer det enda observerbara resultatet bli ~10 % högre RAM pris och upp mot ~10 % lägre prestanda. ~10 % är väl ungefär vad man tappar om man faktiskt kör med JEDEC specifikationer mot typiska "gaming RAM" som används idag.

Finns trådar på bl.a. Phoronix där de diskuterar överklockning av ECC RAM och är förvånansvärt snabbt man börjar se fel vid överklockning, fel som med stor sannolikhet inte skulle märkas på en spel-PC. Jag skulle inte vilja köra min PC med sådana RAM-inställningar, men använder heller inte dator för spel och inser att jag knappast representerar någon form av "normalanvändning" av en dator.

Okej men igen så var ju inte poängen vad ECC presterar idag utan vad det potentiellt hade presterat om fokus för utvecklingen legat där för hela PC-marknaden och inte bara server/workstation.

Måste fråga, motsätter du dig att ECC skulle vara något som är användbart för personliga datorer som koncept eller just att det är Linus Torvalds kommentarer runt det som får uppmärksamhet?

Han är defintivit problematiskt grälig i sina argument rätt ofta, vilket han visar senare in i tråden också som ses nedan. Jag uppskattar att höra personliga åsikter och inte marketing bullshit, och jag litar aldrig på en enda källa för något ändå. Det vore schysst om han kunde lugna ner sig men hellre en käbblig Linus än att de enda åsikter man hör från honom gått genom en censurkommitte först.

> > Linus
>
> Except if we're talking about malicious attacks, researchers figured out they could flip three bits
> and cause an undetectable error.

BS.
They could do so only by causing a lot of single-bit flips
Why is this so hard to understand? ECC would detect the attack. It really is that simple, and that's a fundamental fact.
People who argue about undetectable 3-bit flips are incompetent and don't understand what they are talking about. They are either actively trying to be bad actors, or they have bought into the fairy tale from the bad actors.
And yes, in some theoretical universe you could have a single 3-bit flip without getting any single-bit flips. Anything can happen in theory. But that's like worrying about a meteorite targeting you personally. It's simply not a realistic worry, and it's not an argument against ECC.
Do you argue against airbags because they wouldn't save you from being killed in your car by a stray meteorite?
Can you really not see how stupid your argument is?

Visa signatur

Gamingrigg: MEG x570 ACE, 5950X, Ripjaws V 32GB 4000MT/S CL16, 6800XT Red Devil LE, HX1200i.
Laptop: XPS 9570 x GTX 1050 x 8300h + 16GB Vengeance 2666Mhz + Intel AX200
Valheim server: i7-8559 + Iris Plus 655 + 32GB + 256GB
Printers? Yes. Ender 5, Creality LD-002R, Velleman VM8600, Velleman K8200

Permalänk
Datavetare
Skrivet av Shiprat:

Jag fick inte bilden att han påstod att man inte behöver ECC om man är "tech savvy" utan att han menade att hans irritation inte kommer ifrån att han själv behöver ECC, något han förklarar med att han kan hantera eventulla problem som uppstår på grund av bitflips eller har koll nog att sätta upp sin egen rigg för att minimera risken.

Okej men igen så var ju inte poängen vad ECC presterar idag utan vad det potentiellt hade presterat om fokus för utvecklingen legat där för hela PC-marknaden och inte bara server/workstation.

Måste fråga, motsätter du dig att ECC skulle vara något som är användbart för personliga datorer som koncept eller just att det är Linus Torvalds kommentarer runt det som får uppmärksamhet?

Han är defintivit problematiskt grälig i sina argument rätt ofta, vilket han visar senare in i tråden också som ses nedan. Jag uppskattar att höra personliga åsikter och inte marketing bullshit, och jag litar aldrig på en enda källa för något ändå. Det vore schysst om han kunde lugna ner sig men hellre en käbblig Linus än att de enda åsikter man hör från honom gått genom en censurkommitte först.

> > Linus
>
> Except if we're talking about malicious attacks, researchers figured out they could flip three bits
> and cause an undetectable error.

BS.
They could do so only by causing a lot of single-bit flips
Why is this so hard to understand? ECC would detect the attack. It really is that simple, and that's a fundamental fact.
People who argue about undetectable 3-bit flips are incompetent and don't understand what they are talking about. They are either actively trying to be bad actors, or they have bought into the fairy tale from the bad actors.
And yes, in some theoretical universe you could have a single 3-bit flip without getting any single-bit flips. Anything can happen in theory. But that's like worrying about a meteorite targeting you personally. It's simply not a realistic worry, and it's not an argument against ECC.
Do you argue against airbags because they wouldn't save you from being killed in your car by a stray meteorite?
Can you really not see how stupid your argument is?

Ställer mig frågande till att man försökt segmenterat marknaden för att öka marginaler, finns ju publik data kring detta som inte alls stödjer den tesen. Dels Pentium/i3 modeller med ECC för "embedded" och dels i5-i9 modeller med ECC i form av Xeon G, prispåslaget på CPU-delen är allt för liten för att styrka att segmentering gjorts i vinstsyfte.

Då tror jag mer på att CPU-tillverkare och kanske främst moderkortstillverkare genuint helt enkelt inte ser ett mervärde med ECC för konsumenter. Apple, som numera kontrollerar hela sin HW-design, verkar inte heller sett tillräckligt mervärde av ECC för att stoppa in det i M1. Däremot lär vi se ECC-stöd i MacPro serien.

Personligen vill jag precis som Torvalds se ECC som standard. Tror däremot att han är fel ute i varför massmarknaden saknar ECC. Man (==tillverkare av CPU och moderkort, tror inte RAM-tillverkarn har något emot att mer ECC används...) kan ha dragit fel slutsatser, så vänder mig inte mot den delen, vi har t.ex. Rowhammer som möjligen kan komma att användas på sätt som är negativt för normalanvändaren. Lite svårt dock att se att man gjort segmenteringen för att öka marginaler, det verkar snarare så att man faktiskt från tillverkarhåll inte sett vilket mervärde det skulle ge för normalanvändaren, samtidigt som det är merjobb för CPU, RAM och moderkortstillverkare när de ska erbjuda validerat ECC-stöd.

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

Ja detta är ju en diskussion som pågått i 20 år, det är inte bara Linus T som drivit den. Men problemet med random minnesfel skalar ju med mängden minne man använder (egentligen dess throughput), och med tanke på hur mycket minnesanvändandet ökat de senaste 20 åren, så blir ju bristen på ECC en mer brännande issue med tiden. Inte konstigt att diskussionen briserar då och då, med ökad intensitet minst fram till dess att DDR5 rullas ut

Detta från Linus T tycker jag plockar ut poängen:

Skrivet av Shiprat:

Don't fall for the bullshit. ECC is not for servers. ECC is for everybody, and wanting to pay a bit extra for RAM shouldn't mean that you are then limited in other ways.

Linus

"Limited in other ways" är problemet, oftast finns inte alternativet att betala en rimlig merkostnad för ECC
utan att offra något mer.

Själv har jag övervägt ECC vid alla köp sen 10 år tillbaka, i tävling med andra features som ofta fått vinna i slutändan. I mitt fall inte features som möjligheten att klocka minnen över JEDEC, har aldrig varit intresserad av det, men antal kärnor mm. När jag köpte min 6c Coffe Lake i signaturen letade jag ECC-alternativ, men närmaste alternativet hos Intel var Kaby Lake Xeon E3 med 4 kärnor. Eftersom 4c var för lite för mig, så föll det bort då (tittade på AMD också, men oklarhet kring IOMMU samt bristen på iGPU avgjorde i slutändan). Så det är inte bara prisskillnaden som spelar roll.

Torvalds generella poäng är ju dock mer den status, support och nytta för majoriteten användare som ECC hade kunnat ha om det inte varit för segmenteringen. Det är såklart en annan sak än mina och andra swecares entusiastpreferenser. Jag tycker han har bra poänger kring detta, särskilt som sagt när 32Gb ram snart är mainstream, och nya riggar klarar 128Gb.

Skrivet av Yoshman:

Här tycker jag data inte alls styrker att primära drivfaktorn för marknadssegmentering är att öka lönsamheten för serversidan. Torvalds har helt rätt i att Intel har segmenterat ECC stödet till servers och "embedded", men kollar på de CPU-modeller som finns både med och utan ECC stöd är prisskillnaden konsekvent <10 %. Kollade upp ett par i3-modellerna som finns i "embedded" variant (som har ECC) stöd, de var <5 % dyrare än motsvarande desktop-variant.

D.v.s. råder inget tvivel om att Intel segmenterat marknaden, men orsaken kan knappast vara för att öka lönsamheten på produkter med ECC-stöd då prispåslaget är helt enkelt så litet att det knappast kan göra mer än täcka den faktiska merkostnaden.

Påslaget för ECC varierar och verkar vara större när vi går uppåt i prestanda, ta t.ex. Xeon W-2265 vs. I9 1920X, där är Xeon 35% dyrare för såvitt jag kan se samma kisel och klocka (introduktionspris enligt ark: 944usd vs. 700usd). Lägg till det tidslagget för release mellan konsument- och workstationversionerna av samma processor. Hur det kvantifieras i pengar är såklart subjektivt för användaren, men Intels marknadsavdelning har garanterat en beräkning på vad det gör för skillnad för företaget.

Men, du har säkert rätt i att det finns fler skäl bakom segmenteringen än bara prisskillnaden. Jag förstår såklart att det finns en massa fördelar med att låta enterprise-hårdvaran lagga efter 6 månader så att gamers och inte företag får upptäcka evt. hårdvarubuggar. Om det istället varit samma hårdvara - ja, marknadsstrategierna hade behövt vara rejält annorlunda, det är helt säkert.

Citat:

Kikar vi på SweClockers testar kring hur minneshastighet påverkar minnesprestanda blir då den verkliga frågan: vilket värde skulle ECC ge för dagens gamers? För vad de faktiskt kommer "se" är ~10 % högre pris och upp till ~10 % lägre prestanda med noll skillnad i upplevd stabilitet (om man nu inte överklockat sitt system idag till en nivå där det kraschar ett par gånger per år)...

Jag tycker Linus T har en stark poäng om nyttan även för klockare, även om det såklart var ett sidospår (han svarar väl på påståendet att gamers inte behöver ECC). Poängen är väl inte att felkorrigeringen hos ECC ska kompensera för alltför hårt klockade minnen genom att rätta felen, utan att överklockare ska kunna få veta när bitfelen drar iväg. Men självklart kommer man att nå taket tidigare med minnen som är oförskämda nog att tala om för en när maskinen börjar bli instabil... finns garanterat de som föredrar att vara lyckligt ovetande istället.

Givetvis förutsätter det att branschen tänker annorlunda kring både ECC och minnesklock/timings, hade ECC varit seriöst etablerat i alla segment så hade vi haft en annan idé om hur långt minnen kan pressas, och vad stabilitet innebär. Men det är lite inbyggt i argumentet att den resulterande idén hade varit en bättre idé, baserad på information som vi i teorin kan få (med ECC) men nu inte ens har. Var vi hade varit om allt arbete som gjorts för att uppfinna snabbare minnen, gjorts med hänsyn till ECC, vet vi såklart inte. För att "vi" (Intel, branschen, ...) har valt att inte veta det.

Skrivet av Yoshman:

Tänk igen och läs också vad Torvalds skrev i första inlägget: grejen med de fel som ECC kan rätta är att de i majoriteten av fallen är "tysta", d.v.s. oavsett hur teknik-kunnig man är kommer man inte kunna göra något åt felen då man inte ens kommer se dem. Det var min invändning mot det jag markerade.

I första inlägget klagar Torvalds specifikt på att vi aldrig kommer få veta hur vanligt fel som t.ex. Rowhammer faktiskt är då dessa är nästan alltid "osynliga" (i.e. de ger inget fel som kan observeras), vilket är en helt korrekt observation men som går i klinch med att man inte behöver ECC om man är "tech savy".

Jag ser inte någon inkonsekvens i Linus argument, hela hans poäng med inlägget (om man tar honom på orden) är ju att det inte är hans behov som är de viktiga. Rowhammer och random bit flips är ett problem, det faktum att man inte får veta utan ECC att minne är instabilt eller håller på att gå sönder är ett annat. Man kan försvara olika fördelar med ECC för olika användare, samtidigt. Correction och detection är olika diskussioner, men såklart kommer ens "tech-savyness" att styra hur länge det tar att upptäcka ett trasigt minne om man inte har ECC med fungerande felrapportering. Med ECC däremot, då är tech-savyness inte en faktor längre, precis som det bör vara.

Hans argument om gamers fokuserar också uppenbart på detection, inte correction. Poängen är ju att ECC fixar båda. (hade man velat hitta en sweet spot för att monitorera överklockning hade det kanske räckt med en enklare paritetslösning, t.ex. en checksum-bit per 64bit eller så för enbart detection, vilket hade varit betydligt billigare än ECC. Men paritet har väl inte förekommit sen SIMM-tiden, antar jag?)

Skrivet av ddelin:

När det gäller AMDs AM4 plattform stödjer dom ju officiellt ECC på Pro varianterna av CPUerna, så risken för att man skulle få nån dummy implementation som rapporterar att ECC är på fast det inte funkar tror jag inte på, även med icke Pro varianterna av Ryzen. Stödet finns ju uppenbarligen både i kislet, och i firmware, och enligt AMD finns det inget tekniskt som begränsar användningen i vanliga Ryzen proppar.

Skrivet av anon5930:

Hade varit ganska fint om även AMD erbjöd egna referensmoderkort som följer tanken bakom plattform, där officiellt ECC-stöd också erbjuds. Är inte partnertillverkarna inte intresserade så får AMD göra deras jobb helt enkelt.

Jag började gräva i ECC-stödet på AM4 i en annan tråd nyligt. En del av hindren för utbrett ECC-stöd på AM4-moderkort är att även om fel korrigeras, så loggas de inte av moderkortet pga att plattformen inte stödjer detta (enligt mejlkorrespondens under 2019 mellan AMD-ingenjörer och ASRock Rack, se länkade inlägget). Verkar finnas mjukvaru-workarounds för loggning, men avsaknaden av loggning enligt standard bidrar kanske nog till att moderkortstillverkarna inte så entusiastiskt försöker göra ECC till en feature. Så ansvaret ligger ganska mycket hos AMD också.

Jag såg i mejltråden som Linus T skriver i, att Ian Cutress explicit tar upp risken att AM4-riggar rapporterar ECC-stöd utan att det fungerar. Det kan dock bygga på fall där felkorrigeringen fungerar, men rapporteringen inte gör det, vilket såklart gör det till en definitionsfråga om man ska säga att "ECC fungerar" eller inte.

Gräver gärna vidare i detta, fast kanske hellre i den andra tråden, känns som att vi inte behöver en "Men AMD då?"-diskussion här

Lade till länk
Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Datavetare
Skrivet av Oegat:

Påslaget för ECC varierar och verkar vara större när vi går uppåt i prestanda, ta t.ex. Xeon W-2265 vs. I9 1920X, där är Xeon 35% dyrare för såvitt jag kan se samma kisel och klocka (introduktionspris enligt ark: 944usd vs. 700usd).

Där är skillnaden större än bara ECC, Xeon-varianten stödjer LRDDR4 vilket är orsaken att den fixat 1 TB RAM. Snabb jämförelse på Ark pekar på att Xeon-varianten även har ett par säkerhetsfinesser som saknas på i9:an.

Det lär vara mer eller mindre exakt samma krets i grunden, men de är inte uppenbart samma krets som t.ex. i7-9900 och Xeon 2288G.

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:

Där är skillnaden större än bara ECC, Xeon-varianten stödjer LRDDR4 vilket är orsaken att den fixat 1 TB RAM. Snabb jämförelse på Ark pekar på att Xeon-varianten även har ett par säkerhetsfinesser som saknas på i9:an.

Det lär vara mer eller mindre exakt samma krets i grunden, men de är inte uppenbart samma krets som t.ex. i7-9900 och Xeon 2288G.

Aha, ja det med minnet hade jag inte sett. Vilket tar oss lite tillbaka till ursprungsproblemet, att vill man ha ECC så måste man kliva upp några pinnhål på flera parametrar, förutom i de lägre segmenten (fast det har blivit bättre senaste åren).

Jag tycker inte heller man kan bortse från helheten när man funderar på hur segmenteringen hänger ihop med prissättningen. Betalar Workstation-köparna extra främst för ECC, eller för att kunna ha mer minne? För om man kräver ECC men nöjer sig med 256Gb ram så måste man väl ändå gå W-2265 i mitt exempel? (Jag hittar inget exempel med 4 kanaler ECC-UDIMM i Intels repertoar, åtminstone inte under W-label. Men det kan vara mina grävarskills som fallerar.)

Hade Core iX stött ECC och kostat 10% mer så är frågan om så många hade köpt W-2265 enbart för minneskapaciteten. Dvs ECC kan vara det som driver vinstpotentialen i segmenteringen, även om Intel måste acceptera ett lägre påslag för enbart ECC i de segment där de har konkurrens.

Men ja, det har blivit mycket bättre på bara några år. Tittar man på Xeon W-1xxx så ligger dessa närmare motsvarande Core iX, i både pris och features.

W-1270P (431$) vs. i7-10700KF (361$): 11%
W-10885M (623$) vs. i9-10980HK (583$): 7%

(https://ark.intel.com/content/www/us/en/ark/compare.html?prod...)

Större påslag för desktop/workstation än för laptop/mobile workstation. Säkerhetsfeatures skiljer också något, men utöver det är det nog bara ECC-stödet. Är man ointresserad av IGP så är effektiva påslaget från i7-10700K (ej KF) till W1270P 19% (hittar inga Xeon W 1xxx utan IGP). Men det är positivt att dessa alternativ finns, och att de verkar ha släppts samtidigt. Situationen är mycket bättre än 2017 när jag sist köpte ett Intel-system.

En sak som ändrats i ekosystemet sedan 2017 är såklart mer press från AMD (korrelation vs. kausalitet, jag vet...).

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Medlem

Trevligt att DDR5 har ECC som standard, det hade jag helt missat.
Det tyder ju lite på att det kanske inte är så oviktigt iallafall, lite som Torvalds säger.