Vlákno názorů k článku
Linus Torvalds skládal počítač na youtubovém kanále Linus Tech Tips od Uncaught ReferenceError: - jsem rád, že ECC pronikají i do osobních...

jsem rád, že ECC pronikají i do osobních počítačů. Jak nám paměť rostě, vše se zmenšuje, vliv je nemalý. Zajímavé ale je kolik lidí je schopno se rvát do krve, že ECC je zbytečná, že jí nemá a nikdy žádné problémy nepozoroval.

Paměť bez ECC neumí ani chyby odhalit, takže je pak těžké vůbec říct, jestli se dějí. Řada chyb v paměti nemusí vůbec nic způsobit nebo to má tak malý vliv, že to nelze zpozorovat. To je argument bez dat.

Zo zvedavosti by som sa chcel opýtať, aký je scénar, keď by mi na osobnom počítači vadilo, že sa mi preklopí bit v pamäti RAM?

Třeba se ti blbě zkopíruje soubor. V lepším případě ti něco crashne, nebo třeba přijdeš o nějakou práci. Tisíce možností, co se může stát.

Zrovna pro kopírování souborů by bylo dobré mít i nějakou kontrolu na aplikační úrovni. To není jen RAMka, ale i řadiče disků, disky a jejich firmware a případně síť, pokud to není v rámci jednoho počítače.

Ale viete že TCP používa kontrolné sumy.

Ty kontroly všude jsou a budou ok. Když se ti v RAM flipne bit, tak ten soubor prostě zapíšeš poškozený, a všechy ty řadiče disků s tím budou souhlasit, protože neví, že ten bit má být jiný.

Ono hodně záleží na tom, kde se to flipne. U nějakého video streamu to třeba jen pokazí pár framů. U něčeho důležitějšího to může ale způsobit, že ty data nenačteš.

Pokud systém na nějakou pozici v paměti zapíše nějaká data, tak očekává že tam následně ta stejná data budou.

jak preklopi? jako blip a to prece nemuze vadit? KOmiku.

tyden mi padal firefox, nic jineho. silel jsem z toho. ztratil furu casu. az mne napadlo run mem test a samozrejme ta horni cast pameti, kam obcas firefox s mnoha taby doputoval, sedel na DImmu plnym chyb.

alespon paritni pameti kdyby zustaly standardem

Tu nehovorím o PEBKAC, ale o reálnej potrebe ECC.

PEBKAC se za mě říkalo uživatelské chybě, když někomu padá program a pak zjistí že je závada v HW, tak to není PEBKAC, a je to dobrá ukázka proč by se hodilo chybu detekovat rychleji, ne?

Já se nejvíc bojím neopravitelné chyby filesystému (bitflip v nějakých zásadních metadatech, kvůli kterému se ztratí přístup k části stromu) nebo databáze (spousta aplikací používá sqlite pro ukládání uživatelského nastavení a dat).

Nepříjemné to může být i pokud děláte nějakou dlouho běžící numerickou simulaci/opti­malizaci a nemůžete věřit výsledkům, podezříváte, že jste do programu zanesli bug atd.

4. 12. 2025, 11:49 editováno autorem komentáře

Muzes pouzivat FS, ktery chrani data opravnymi kody a nebo blokove zarizeni, ktere to dela nezavisle na FS. Pstore a ubifs, ktere cili na potencialne nespolehlive pameti, to delaji by default.

Opravdu to chrání (meta)data před poškozením když se s nimi manipuluje v RAM? Běžné FS s checksumy (btrfs, zfs) chrání data při zápisu na disk (a jinak metadata má checksumované i třeba ext4). Uvedené FS neznám ale co jsem si vygooglil tak pstore je nějaká specialita pro ladění crashů, a ubifs vypadá jako že spočítá právě checksum bloku při zápisu na disk - ono chránit se proti chybě RAM asi ani v principu spolehlivě nejde, když nemůžeš věřit svým vlastním výpočtům.

Tak jestli jedna oblíbená hra spadne do CTD 3x denně kvůli modům, zatímco druhá vydrží týden+, tak to jsou dostatečně průkazná empirická data k podobnému tvrzení.
To samé platí třeba co se týče nutných přeinstalací Win.

Ve vědě se tomu říká upper limit/upper bound, a samozřejmě, že je to relevantní údaj (se kterým je třeba správně pracovat - asi něco jiného je use case serveru, a něco jiného je herní PC, kde případný efekt je prostě zastíněn mnohem výraznějšími efekty, jako nestabilita hry nebo nějakého driveru).

Chyba, ktera nic nezpusobi nebo jeji nasledky jsou tak male, ze nejdou pozorovat, tzn. ze bitflipy pokud se deji, tak jsou casto benigni - takovy argument bych cekal spise od odpurce ECC, ne od zastance :)

Ja rozhodne nejsem militantni odpurce ECC, zejmena v profi nasazeni. Vlastne jsem 6 let pouzival dual Xeon s ECC (behem te doby zadnou chybu neodchytil, reportovani bylo zapnute a memory patrolling take). Ale musim se pridat na hromadku tech, kteri problemy nepozoruji... v 2022 jsem ublognul "Dva roky uptime na PC s Windows aneb příběh jedné sázky" zde

https://www.abclinuxu.cz/blog/Mihovy_sochory/2022/12/dva-roky-uptime-na-pc-s-windows-aneb-pribeh-jedne-sazky

(pokus probihal na PC s 256GB, z nichz je vetsina trvale obsazena) a je tam i kapitola venovana ECC. Pokud bude mezi svatky cas, tak tam dam pokracovani: "Pet let uptime na PC bez ECC". Aj, to bude stavnata diskuze pod clankem ;-)

2. 12. 2025, 10:14 editováno autorem komentáře

Jenže to, že to zrovna tobě vyšlo, statisticky nic neznamená.

Zrovna v tomhle mam dobrou zkusenost z produkcniho nasazeni radove stovek tisic instanci vestaveneho systemu, kde si zakaznik z duvodu uspory rozhodl v dobe produkce prestat pouzivat ECC pameti. Rozdil crashu se lisi az ve 3. radu (0.00..0XXX vs 0.00..0XXY), takze to je to z pohledu nasazeni naprosto zanedbatelne a hlavni problem je, ze pri analyze padu clovek nevi, jestli mohlo dojit k prepnuti bitu a nebo ne. To vyresili tak, ze se analyzuji pady primarne z tech asi 10% systemu, ktere ECC maji.

bitflip se mohl přihodit třeba v paměti, která aktuálně není využívaná nebo v oblasti, která obsahuje nestrukturovaná binární data (třeba video), kde změna nemusí být žádný velký vliv na venek. Ne vždy jsme schopní exaktně tu změnu poznat a detekovat, to jsem myslel.

Je to prostě hra na ruskou ruletu, nikdy nevíš, kdy to může být příčinou jaké nestability nebo problému s chováním.

Je nějaká statistika, jak časté jsou chyby paměti (bitflip)? U nás na TB RAM jsem ECC chybu paměti ještě neviděl.

Ja pouzivam osobne pocitace bez ECC 40 rokov a zatial som mal jednu vadnu RAM.

RAMky nestály za moc v dobách DOS a Windows 9x. Windows NT, pro domácí uživatelé to znamenalo od Windows 2000, shit sestavy padaly kvůli RAMce. Výrobci RAMek zlepšili jejich kvalitu a od té doby je to pro běžné používání většinou bez problému.

EDIT: On jako počítač při bootu RAMky zkontroluje na základní úrovni, což vyřadí většinu RAMek dřív, než byste do nich lil data. Mně třeba odešel slot na RAMku kvůli prachu a zkratu, moduly fungují v ostatních slotech.

2. 12. 2025, 12:38 editováno autorem komentáře

Za 30 let a destiky TB ... sem chyby ram videl reportovat jen jednou, na dellim serveru, a chyba nebyla v ram ale v MB a bylo to false pozitive.

Takze bych to videl tak, ze ECC je sice fajn mit, ale neni to nic zasadniho a na desktopu ... lol.

1-4TB RAM sestavy na levnem hw( dell/hp x86) uz jde nejake ecc chyby vidět zkrz 60 stroju. Je to male DC ( stará ustredna AT&T). Servery jsou ve vrchních patrech coz muze hrát určitou roli. Sever USA.

2. 12. 2025, 13:12 editováno autorem komentáře

My máme aktuálně cca 60TB RAM celkem a ještě nic. Je pravda, že serverové ram jedou na velmi konzervativních frekvencích, na desktopu se to může stát i kvůli velmi rychlému a méně častému refresh, ale na serveru jsem ECC ještě neviděl. To neznamená, že tam nemá být, já jsem příznivec ECC i na desktopu, ale těch chyb obecně není tolik, kolik bych čekal.

(Totéž platí i pro disky, od roku cca 2006 si dělám u všech souborů sha sumy (aktuálně sha3-512) a žádný soubor nikdy nezměnil ani jeden bit.)

Uvědomujete si, že ve spoustě aplikací je jedno, že systém nebo aplikace prostě tu a tam spadne? Nevítězí věci nejlepší a nejfunkčnější. Používá se to, co je dostatečně dobré. A to je veliký rozdíl.

Dostatečně dobre je relativní pojem. Treba neni problem kdyz systém spadne. Ale S JAKYMI daty spadne!!! Jak je invalidujete, jak oddělit dobrá data od špatných atp.

2. 12. 2025, 15:28 editováno autorem komentáře

Pokud by např. spadl před zápisem špatných dat, tak je to ještě hodně v pohodě. prohrabávat se daty a řešit, co je dobře, je masakr :-)

2. 12. 2025, 15:30 editováno autorem komentáře

Herni pocitac, kdyz pada hra vic nez malo: prava krysa -> properties -> Installed Files -> Verify integrity of gaming files"
Těch míst, kde by případný bitflip nebo pád průměrného "Počítač v kuchyni" vadil, je opravdu minimálně, a míst, kde by nehrozilo řádově vyšší nebezpečí (třeba že odejde disk úplně, nebo to ani nemá UPSku...) jen velmi stěží budete hledat problém.
Však "resetni instalaci desítek do defaultu" je dost časté řešení wokeních problémů already ;-)

Z druhé strany u databáze nebo fileserveru samozřejmě není co řešit, u nějakého frontendu, na kterém nejsou data, bych se sice z principu ne-ECC bránil zuby nehty taky ale asi (pokud přes to netečou prachy) by asi nebylo úplně triviální to obhájit, zvlášť když se při jakémkoli problému dá strašně rychle ta instance zrušit a nechat vyprovisionovat dvě jinde.

Jistě:// https://theregister.com/2025/12/01/a320_software_rollback/

Pojdme si pohovorit o tom co znamena slovo "treba". A take si pojdme pohovorit o sirsim kontextu diskuse. Neresime zde specializovane embedded systemy na avioniku ale obycejna pecka.
To co zminuji je uplne nejvic worst case supacky scenar kdy akceptuji ze dany system spadne. A kdy dejme tomu akceptuji i poskozeni dat in transit.
Je avionika/FBW takovy system kde je to akceptovatelne? Kdy si zaparkuju na oblacku a dam si kafe nez se rozhodnu co dal protoze mam dost casu? Neni! Proto jsem pouzil slovo treba.

A pak ti prijde nejaky trdlo a chce si na non-ecc systemu postavit nasku nebo co já vím home bgp core router s kubernetes hostujici cely startup o trech lidech. Od toho snurou na prádlo připojené disky/sitovka přes USB... A ostatní tomu tleskání bububu Trident je srab, ma totiz strach ze ho bit flip baci...
Vzdyt ECC mají uz snad i poslední raspi.

A čo ako. Na 99.999% to bude fungovať. Ak je to dostačujúce v čom je problém? Ja v aute tiež už nemám rezervu, šialené že?

Mate asistencku/od­tahovku nebo lepení ( ktere stejne moc nefunguje). Ze zákona musite mít nějaké z těch reseni. Vyměnila se jen forma ochrany proti nenadále události ale nepřestala se resit uplne.
Navíc u řady aut je kolo porad optional nebo standard ( off roady).

2. 12. 2025, 15:28 editováno autorem komentáře

V drtivý většině případů to bude úplně jedno. Jenže pak jednou přijde monstrózní blb a zapomene se zmínit, že na tom chce pást informační systém lékařský dokumentace nebo řízení etylénovejch pump v rafinérce.

Většinou tyhle kraviny vymysli develove nebo manažeři mimo IT co se lituji do infra. Důkaz je ze 8 let se nic nestalo a tak se nestane nic i v příštích letech a podobné koniny. Bez nejake kalkulace mozne skody. Treba je potencialni skoda tak mala ze pad nějakého keplu nestoji ani MD vyvojare.
Rozumný devel ví kde jsou jeho hranice a mazer jsy se ma zeptat. Já taky neradim našim expertům na routing.
Ideální je papírová valka/SLA/prevzeti odpovednosti a vse si archivovat. Nechcete byt odpovedni za cizi rozhodnutí a pak to resit az treba u soudu.
Tedy za predpokladu ze vam to nereguluji normy daneho odvetvi/securitaci. Tam pak mate lehci praci.

3. 12. 2025, 14:41 editováno autorem komentáře

Moje "NAS" je starý desktop s nízkou spotřebou, kterému se o nějaké ECC může nechat jen zdát. Platí pro něj přesně to, co jsem napsal nahoře. Ale samozřejmě vy víte vždycky nejlíp, co potřebují ostatní, jasné... Jak jsem psal, nakonec je vždy nejúspěšnější to, co je dostatečně dobré, nikliv nejlepší. A pro drtivou většinu SOHO aplikací (včetně valné většiny domácích NAS) je prostě dostatečně dobrá i non-ECC RAM.

Víc v tom fakt nemá smysl hledat.

2. 12. 2025, 17:27 editováno autorem komentáře

pro něj přesně to, co jsem napsal nahoře - sebeklam neni důkaz o vhodnosti.
Řekněte kolik tam hostujete dat a jaké mate toky a co je to za data?Máte tam treba btrfs/zfs? Máte shared volumy? Nějaká file based db? Slozitejsi lockovani souboru?
Dneska každý uz ma dneska aspon desítky TB dat nekde doma.
Na druhou stranu kapesní nas je rada ze ma dobry kontakt na sd kartě a tam ecc typicky neresite- druha hranice problemu.

2. 12. 2025, 23:56 editováno autorem komentáře

"Dneska každý uz ma dneska aspon desítky TB dat nekde doma."

o'rly?