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.
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š.
Tak samozrejme ze soubor neni stejny ale musi se na to vcas prijit. Ktery bezny zpusob kopirovani souboru automaticky pocita hashe obou souboru a pak to pro kazdy soubor porovnava?
"Zrovna pro kopírování souborů by bylo dobré mít i nějakou kontrolu na aplikační úrovni."
A kde by to vsude jeste bylo dobre? Proc zrovna jen u kopirovani souboru?
Asi nedava smysl aby system byl navrzeny aby vsechno neustale overoval. A co kdyz je to napoprve dobre a selze kvuli bitflipu az to overeni, to by to tam vsude melo byt jeste potreti. To zni dost slozite.
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
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/optimalizaci 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
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
(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
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.
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
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.)
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.
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.
Mate asistencku/odtahovku 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ě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