Názory k článku
Linus měl problémy s vadnou pamětí v pracovním počítači
-
Tady nejde o to, jak dlouho paměť vydrží, to ECC neřeší. Smyslem ECC je předejít "silent data corruption", tedy poškození dat v důsledku chyby paměti, kterého si nevšimnete, protože nemáte žádný kontrolní mechanismus, který by ho odhalil. Tady to způsobilo ICE, ale ten může mít i spoustu jiných příčin a vadná paměť není obvykle to první, co by člověk prověřoval (aspoň pokud se to nestane krátce po instalaci nových modulů). V horším případě ale může dojít k tomu, že poškozená data uložíte a pak se s nimi dál pracuje, aniž by kdokoli věděl, že jsou poškozená.
-
Zjistit to mohu tak, že něco nefunguje jak má (tak, jako Linusovi). Což se ostatně už někdy stalo určitě i vám. A pokud to fungovalo jak má, pak mi může být jedno, že byl/je nespolehlivý a spolehlivost je tedy zjevně pro běžné desktopové použití dostatečná. Nikde jsem nepsal, že jsem si něčím byl jistý. Ani to není podstatné.
Běžný desktop není server pro sto zákazníků, nemá na něm být SLA 99.99 % ani na něm neběží kritická infrastruktura. A ano, samozřejmě vím, že pro ne úplně malou část čtenářů root.cz je zcela nepochopitelné, že lze bez ECC spokojeně žít.
-
Vtip je v tom, že zapíšeš 1 a přečteš 0. Nemáš žádnou šanci zjistit, že to je špatně. Může se to stát i na úplně perfektně fungujících modulech. Klidně jen jednou nebo jednou za několik měsíců. A samozřejmě bude trvat roky, než přijdeš na to, že je něco špatně, pokud na to vůbec přijdeš. Proto se tomu říká silent data corruption. Ne vždycky se chyba projeví tak jako Linusovi.
-
Já to samozřejmě chápu. Ale pokud mě to nějak neobtěžuje, může mi to být celkem jedno. A protože to je desktop a ne server s daty zákazníka, ani mě nikdo nezažaluje za to, že mu přehozenej bit poškodil třeba databázi.
Moc ale nechápu, co řešíme. Celým tím jsem chtěl říci, že výrobci desek ECC paměti neřeší možná třeba proto, že se bez ECC dá docela spokojeně žít. Reálně ho atokonto velká část uživatelů prostě nepotřebuje. Takže proč by z něj neudělali prémiovou vlastnost?
-
Zjistit to mohu tak, že něco nefunguje jak má (...) A pokud to fungovalo jak má, pak mi může být jedno, že byl/je nespolehlivý a spolehlivost je tedy zjevně pro běžné desktopové použití dostatečná.
Nepoznáte to, není to pass/fail.
V consumer aplikacích je drtivá většina obsahu paměti multimedia (buffery videa, framebuffery, textury, 3D geometrie, ...) ve které se náhodný bit flip projeví jako lokální málo postřehnutelný artefakt: prsknutí v hudbě, "kostičky" ve videu, proužek na textuře, ostrý polygon na modelu ve hře. Pokud k tomu dojde při zápisu na disk, tak je škoda trvalá. Děje se to běžně (několik událostí za měsíc a GB v DDR4).
-
Tohle si pamatuju z dávných dob. Člověk udělal zálohu fotek (JPG) ze starého disku nebo počítače na nový a po letech si všiml, že v nějaké je chyba (pokud větší, tak od půlky obrázku dolů např. nesmyslné barvy). Byl problém v RAM, přes kterou ta data tekla? Ve zdrojovém nebo cílovém disku? V přenosu po LAN? Tohle v domácích podmínkách člověk nemá přímo ošetřené. I když stabilita jednotlivých komponent asi vzrostla, protože se s tím v posledních letech setkávám méně až vůbec (ale je fakt, že toho na PC takto dělám méně).
17. 10. 2022, 16:44 editováno autorem komentáře
-
-
FíkZlatý podporovatelNevím o tom. Toto je sice staré, ale mají tam DDR2 a vliv teploty taky. Asi je rozdíl, jestli chcete detekovat náhodné překlopení třeba 1 bit za rok v 1 TB RAM, s čímž se asi nedá nic dělat (kosmické záření, radioaktivní pozadí). Nebo chcete ECC použít k tomu, abyste našel a vyměnil vadný DIMM, který chybuje daleko častěji.
-
Dnešní paměti jsou tak spolehlivé, že ECC se nevyplácí. za dva roky s 64GB DDR4 ECC jsem v logu neviděl žádnou událost.
DDR5 mají on-die ECC, takže bit rot ne v podstatě vyloučený.
Největším nepřítelem dat dneska je porucha napájení, porucha celého DIMM, porucha CPU.Pokud se bavíme o RAM, mnohem větší smysl má zrdcadlení kanálů RAM, protože dokáže ochránit proti selhání DIMM a selhání paměťového řadiče.
-
Muzete nejak dolozit to "deje se to porad"? Mam v serverech dohromady 1TB pameti s ecc, zapnuty memory patrolling a reportivani 1bit chyb a za poslednich 5 let nic.
Doma mam pocitac s 256GB RAM bez ecc z toho bezne 128+ obsazeno (cele stado virtualnich pocitacu). Statisticky by se za ~3 roky co ten pc mam neco muselo trefit do mista, ktere by zpusobilo pad hosta nebo nektereho z guestu ... a take nic.
-
a jaké chyby to reportuje, jen ty urecoverable?
Asi nejrozsáhlejší studie je 12 let stará, http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf, probíhala dva a půl roku s několikatisíci servery. Vyšel jim průměr mezi 14 - 40 1bit chyb na každý gigabit paměti. Ty tady tvrdíš, že 5 let nemáš žádnou chybu, z mých zkušeností to je těžko uvěřitelné číslo, spíše koukáš na jinou metriku než o které se bavíme.
Stejně tak tady už nějakou dobu máme útok Rowhammer/ECCPLOIT, který způsobuje právě flip bitů sousedících buněk, tady na rootu se o tom píše pravidelně již několik let. Ukázkových a testovacích nástrojů máš celou řadu, můžeš si sám vyzkoušet jak je tvůj monitoring spolehlivý a jak probíhá silent corruption pamětí.
Na tohle se těžko argumentuje, protože pořád se bavíme o statistice a šanci, že něco nastane. Vždy v takovýhle případech můžeš vytáhnout příklad, který podpoří kteroukoliv verzi.
-
Ok, pojdme pryc od statistiky a vyzkousejme tvoje cisla aplikovat do praxe.
Pojdme odhadnout, kolik pameti je natolik kriticke, ze flip bitu v ni zpusobi pad OS. Dovolim si tvrdit, ze bit flip v executable casti jadra vetsiny pouzivanych subsystemu a ovladacu bude znamenat oops, bit flip v kodu syscalu zpusobi, ze se bude hroutit userspace. Dale jsou kriticke datove struktury, kde bitflip zpusobi skoro jiste pad. Ignorujme male veci jako tabulky procesu atd. a zamerme se na velke. Nejvetsi bude na tuty tabulka PTE stranek. To je steuktura velka 32bit na kazdou 4KB stranku + nejaky overhead. Separatne uvazme exe/lib casti softu v userspace a jejich data (interni datove struktury, nikoliv multimedia), ty budou pusobit pady tech aplikaci. Separatne uvazme velke struktury ve SLABu, treba DENTRY cache atd. kde by flip mohl pusobit divne chovani a to jeste jen nekdy (kdyz se zrovna dana DENTRY pouzije).
Dovolim si tvrdit, ze takovy bezny desktop bude mit minimalne 128MiB pameti (tedy jeden gigabit), kde flip zpusobi brzky pad OS. Dale pak 512MiB (4 gigabity) pameti, kde flip bitu zpusobi s velkou pravdepodobnosti problemy v userspace.
Pri 14 flipech na gigabit na mesic to znamena v prumeru 14 padu OS na mesic a 56 mist, ktere s velkou pravdepodobnosti zpusobi problem v userspace (pri dlouhem uptime a/nebo suspend to roam/hibernaci) se tohle navic bude kumulovat. A to jsem bral minimalni odhady uplne u vseho.
Slucuje se ti to s realitou, kterou pozorujes v beznem svete, nebo jsi ochoten uznat, ze to je cele jeden velky BS?
-
Jeste jedna snadno overitelna metrika, kterou si ostatne kazdy muze snadno vyzkouset, me napadla. Po sestaveni sveho PC jsem ho nechal projet 24h memtestem. 2 terabity po dobu jednoho dne pri 14-40 flipech na mesic a gigabit - statisticky mel memtest odhalit 955 az 2730 chyb. Odhalil 0. Dooost divne, ne? Jakoze doooost dost divne. Kolik smerodatnych odchylek by bylo treba, aby se tohle to stalo?
Nebo pro lidi, kteri by namitali, ze flip nastane v situaci, kdy je hodnota v pameti dlouho (coz bude spis nesmysl, pac se jedna o dynamickou pamet, ktera se refresuje kazdych par ms) navrhuji vyvtorit ramdisk a nakopirovat tam soubor s 1GB nul. Po mesici by tam melo byt 112-320 bajtu s nenulovou hodnotou. Spoiler alert -budou tam same nuly ;-)
-
tohle je pěkný bias. Ta statistika 14 - 40 výskytů na měsíc mluví o souhrnném čísle za 2,5 roku provozu několika tisíc serverů. Vůbec nic ti ale neříká o jediném serveru v dvoudenní zátěži.
Dokud budeš konfrontovat statistická data s jediným vzorkem a jiným způsobem měření, asi se nemáme o čem bavit.
-
Tvá definice pádu (OS, aplikace) je příliš katastrofická, většina dat v paměti je obsah, data, která se někam zapisují nebo čtou, nikoliv instrukce samotné.
Mám přístup do nižších stovek serverů, kde přes EDAC tohle sledujeme a vidím, že to CE vyskakuje průměrně v jednotkách na server denně (jsou ale servery, které nemají měsíc nic). UE tam za posledních 6 měsíců (více dat nemám) není.
To je ale strašně malý vzorek a pořád se jedná o nějakou pravděpodobnost, dokonce tak malou, že jí měřit na jednom serveru je velice obtížné.
Ne ECC servery nikde po ruce nemám a doma na notebooku mám tak malý provoz, že nestabilitu asi nemá šanci pozorovat.
-
To je mi jasne, ze vetsina bitflipu problem nezpusobi (to je aegument proti nutnosti ecc btw). Proto jsem celou pamet redukoval na kritickych 128MiB.
Fajn, takze se z 14-40 chyb na gigabit dostavame na 1 chybu na server a mesic. Pokud mas zapnuty patroling (a tedy kazdy flip je odhalen a to i u bunek, ktere by se normalne nikdy neprecetly) a servery maji v prumeru 64GB tak to uz se dostavame do teritoria, se kterym jsem ochoten souhlasit - 0,015 chyby na GB a mesic. To je o nekolik radu mene nez v tom paperu.
Pro PC s 16GB ram vychazi 3 flipy na rok pri 24/7 provozu, pricemz (cucam z prstu) 90 % flipu je benignich -> ergo kladivko ecc je pro bezneho uzivatele zbytecna. S timto vysledkem souhlasim a neni treba dale o tom diskutovat :)
18. 10. 2022, 16:38 editováno autorem komentáře
-
"kolik pameti je natolik kriticke, ze flip bitu v ni zpusobi pad OS. "
V závislosti na konkrétnom použití môže byť oveľa kritickejšie ak dôjde k poškodeniu dát, než k tomu, že sa zrúbe OS s následným rollbackom otvorených transakcií.
Opäť sa mi vynára ironická veta, ktorou si robili chalani supportujúci SAP určitú srandu z linuxákov (podporujúcich OS/HW) a ich prístupu k veci: "Operačný systém je na to, aby bežal."
-
Já bych řekl, že silně záleží na use case. My máme po světě mraky serverů a ecc chyby se objevují jen když ty moduly "zestárnou", zato kolega, co dřív dělal SAPy mi říkal, že na prakticky identickém hardwaru měnili RAM skoro denně, protože ho tlačili na hranici, a řekl bych, že zrovna Linus s kompilací jádra se tomuhle blíží taky.
-
Přímý přenos dat mezi zařízeními - bez cesty skrz CPU a System RAM jako vyrovnávací buffer - je novinka až posledních let. Např. v nových konzolích a na PC pod názvem DirectStorage si sama GPU čte (a dekomprimuje) soubory z NVMe disku přímo do své Video RAM.
17. 10. 2022, 16:47 editováno autorem komentáře
-
Ak sa poškodí hlavička súboru, tak sa poškodí súbor,... ak sa poškodia obsahové dáta (obrazová/zvuková informácia), tak to nevadí vôbec... nikto nerozozná rozdiel že vo filme v 42 minúte 16 sekunde na 14 snímku v tej danej sekunde je na jednom pixely na súradnici x: 824 y: 544 farba #fc32b8 namiesto #fc31b8 a keďže obrazové data tvoria najväčšiu časť súboru, tak je v podstate nulová šanca že jeden prehodený bit by poškodil súbor. Ale záleží aj od programu v ktorom to spúšťaš, lebo niektoré si môžu podľa kontrolných súčtov zistiť že sa niečo stalo, zmenilo a odmietnuť to spustiť (aj keď nie je k tomu u stratovo komprimovaných súboroch dôvod). Pri kopírovaní máš ale aj vyrovnávaciu pamäť, a to už je náchylnejšie, tam sa to stať môže. Ale to skôr zlyhá kopírovanie, než že by to úspešne skopírovalo a následne nespustilo.
17. 10. 2022, 16:19 editováno autorem komentáře
-
FíkZlatý podporovatel
Flac má přepínač -t, který soubor otestuje. Jak moc dobře detekuje individuální bit flip by se muselo zkusit.
-
> Nakonec přidal poznámku, že nesnáší výrobce za to, že dělají z ECC pamětí něco speciálního.
Jo to me taky stve, u moji desky v QVL je pro U-DIMM 42 stranek po 20 modulech a pro ECC dohromady 11 modulu, z toho zadny 32GB a ani se bezne nedaji tady sehnat.
Jo vetsina lidi si nevsimne, ale az se to jednou trefi, ze nekomu nabori krypto penezenku, tak ho to asi docela zamrzi :).
Kdyz neco muze fungovat o dost spolehliveji, tak by melo byt normalni, ze jsou lidi, kteri jsou ochotni si za to trosku priplatit (a presto pouzivat jejich oblibeny format - desktop se serverovou deskou neni zadny zazrak a notebook s ECC je jeste tezsi najit).
U pneumatik se taky nenabizeji "bezne", ktere prubezne trosku uchazeji a celkem vyjimecne praskaji (nastesti ve vetsine pripadu kdyz auto stoji), takze vetsine lidi to moc nevadi a "lepsi", ktere proste neuchazeji dokud do nich neco nezapichnes a praskaji prakticky az po konci zivotnosti.
-
Nie - pneumatiky, ktoré používame u nás v Európe či už Michelin, Good Year ale aj Barum či Matador sú v rozvojových krajinách "prémiové za extra príplatok so zlou dostupnosťou". Naopak čínske značky, ktoré si u nás nikto nekúpi sú tam považované za štandard. Takže je to rovnako ako s tými pamäťami len uhol pohľadu ;)
-
Filip JirsákStříbrný podporovatelDnes zmiňoval na přednášce inženýr z Googlu, že z monitoringu ECC pamětí mají statistiku, jak často dochází k bit-flipům a dvojitým bit-flipům (bohužel ta čísla nejsou veřejná). Mají z toho i spočítané, jak často dochází k překlopením tří bitů, což už ECC paměti nedokáží detekovat – ale z těch statistik plyne, že k tomu musí docházet.
Je to tým, kteří řeší ukládání dat, denně prý přenesou exabajty dat (při přenosech mezi datacentry). Opakovaně se tam počítají kontrolní součty dat na různých úrovních, protože při těchto objemech dat už se pravděpodobnost, že někde dojde ke změně, mění na jistotu.
