Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
nevím co amd zvládla, ale ecc taky alespoň v desktopu není úplně jednoduché rozchodit a amd negarantuje funkčnost, btw: ecc v desktopu nikoho nezajímá, jelikož snižuje výkon
https://diit.cz/clanek/ryzen-ecc
Neni jednoduche rozchodit?
-koupim procesor co podporuje ECC
-koupim desku co ma ve specifikaci napsanu podporu ECC rezimu
-koupim ECC pameti pozadovaneho typu.
-Slozim
-Pokud by nahodou nefungovala autodetekce tak zapnu v UEFI/BIOSu.
Jak by to melo byt snadnejsi?
Tak snadnejsi by to byt mohlo. Mohle se treba u zavedeni DDR4 (DDR3) stanovit, ze ECC je v desktopu a NB povinne, pro servery ECC2.
Pak by to fungovalo s kazdym procesorem, deskou i pametmi automaticky a odpadlo by kolecko spravneho vybirani komponent.
No aspon ze v DDR5 uz ECC bude integrovane, ale to melo byt uz davno. Radiace a kosmicke zareni je svinstvo, a vzdy poskodi nejake bity v RAM. Cache, ruzne I/O buffery, dokonce i sbernice ECC davno maji .... jen DDR odolavaly.
Pokud vyberu správné komponenty, tak to funguje i u Intelu;-)
Pokud vím, tak AMD v destopu funkčnost ECC negarantuje, takže ten výběr tak jednoduchý není.
Ja jsem kdysi ECC unbff. paměti používal s DDR2 ( ASUS P5WDG2-WS PRO i975X + Xeon aka Q6600) a nepozoroval jsem žádné extra pozitiva ... jediné úskalí to mělo že ty paměti měli o něco málo horší časování ( cca o jednu jednotku oproti standartu) ...
To už se tu probíralo 100x a stejně jsou první dva příspěvky v diskuzi jak od ignorantů. Záleží kolik máš RAM a co na PC děláš.
tak nám to ignorantům, může osvětlit jak to linus myslel
Je škoda, že diit už před lety vypustil popisky pod fotkama ( na fotce je Adata ECC registered ? ) ... ad článek, není jasné jasné jestli Linus mluví o ECC unbuff. či ECC registered ... ale dle odkazu na AMD .. potažmo na AMD desktop CPU, tuším že myslel ECC unbuff. - tam bych viděl u Intela provinění v zabití ECC ( unbuff.) ( mám na mysli to že asi klasické desktop Ryzeny podporují jen ECC unbuff. ) nevím jak je to nyní , ale kam mi mysl sahá tak čipset/ pam. řadič co umí ECC reg. paměti tak umí jen a jen ECC reg. a čipset/pam. řadič co umi/podporuje ECC unbuff. umí obojí - non-ECC ( klasické dimmy) a i ECC unbuff.
Já jsem od toho upustil z časových důvodů v recenzích, musím to udělat ručně u každého obrázku a zabere to dost času, kterého mám málo, byť z toho úplně nemám radost.
Napr. pro Haswell / 4th gen - desktop cpu umi ecc v Celeron/Pentinum/i3 rade, v i5/i7 nikoliv, a znova az u Xeon E3, coz jsou ty preznacene i5/i7. A musite jeste mit serverovej chipset (Cxxx), ne obycejnej desktopovej.
Desktop cpu umi non-ecc / ecc-unbuff (v zavislosti na chipsetu), a server cpu (2011 socket) umi navic i registered pameti, pak je otazka biosu, zda dojedna nastaveni i pro ecc-unbuff, nebo non-ecc pameti, kterych ale muzete osadit do dane platformy mene (zrejme 2DPC).
Podle me Linus kritizovat to umele omezeni, ktere se vaze na detekci ruznych ID od procesoru a chipsetu, protoze kremik bude stejnej a tudiz umet bude oboji, otazka podpory registered pameti je zcela marginalni co se pametoveho radice tyce, a pochybuji ze delaj ruzne verze radicu.. je to jednoduse fused-off, aby to neslo nakonfigurovat.
ECC pameti by nemeli byt pomalejsi, u reg-ecc se spozdeni o takt kvuli registru/bufferu samozrejme ocekava.
A pak existuji nedodelane/zkriplene serverove biosy, ktere i kdyz ta vec ma umet non-ECC, tak zahlasi chybu pri bootu (Supermicro Post code 15 napr.), kdyz tam nejsou ECC pameti, coz je dalsi virtualni omezovani.
Bohuzel chipset TEHCHNICKY NIJAK nesouvisi s tim, jaky pameti budou pouzity/povoleny. Je to jen virtualni omezeni skrze VID:PID. To, na cem zalezi je navrh desky - at se ten extra segment bitu 65 az 72 pripoji do dimm slotu, z cpu pouzdra.
Ten modul na fotce je fakt hezkej. Trochu mě překvapilo, že ho nedokážu vygooglit podle kódu na samolepce - ale při bližším pohledu se tolik nedivím. Jednak A-DATA zjevně nevede na webu tabulku parametrů staršího zboží, jednak ten modul bude odhadem dost exot. DDR3L, podle počtu čipů v řadě (9) i podle samolepky (72) určitě s paritou. A na otázku, zda je "registered", odpovídám "velmi pravděpodobně ano". Podle mého je buffer implementován tím velikým švábem uprostřed. Ten na unbuffered pamětech nenajdete. Ono ty čtyři řádky čipů (možná dokonce po obou stranách?) by možná ani nešlo na modul umístit/naadresovat klasickým unbuffered způsobem. Takže ten buffer je tam potřeba už jako "multiplexer" - a není se čemu divit, že je pouzdro tak veliké, ten musí mít na břiše asi hodně kuliček. Dál si nevybavuju, jestli jsem někdy viděl serverové paměti ve variantě DDR3 "elkové" - ale fakt je, že jdou servery dost mimo mě. Taky olbřímí kapacita 64 GB na modul byla v té době (DDR3) patrně high end (možná spíš ultra-předražený snob end) a těžko by se proto mohlo jednat o unbuffered modul, ty byly použitelné pouze do desktop / entry-level server desek kde 64 GB bylo (je?) cca maximum na celou desku (resp. CPU / patici). Takže registered snob end. Velmi teoreticky se podobné veliké buffery vyskytovaly taky na "fully buffered" DIMMech, ale to je záležitost DDR2, v generaci DDR3 se to pokud vím prakticky už nevyskytovalo (tím méně v DDR3L).
Ja jsem uz chtel taky napsat, ze tohle je prave neco jako "Fully buffered" DDR3, protoze to oddeluje i datovou zbernici, nejenom ridici, jako v pripade bufferu v registered dimm, ale FBDIMM je jiz pojmenovani ktere se pouziva pro zcela jiny standard - vyuzivajici AMB - advanced memory buffer, ktery preklada daisy-chain zbernici na DDR2, tudiz to je spis translace, nez buffering. Typicky se tyto (z obrazku) plne DDR3 buffery pouzivaj na memory riserech pro quad-socket systemy, kdy se pameti strkaj do karty a karta pak na zakladni desku. Slouzi to prave k redukci zateze, protoze se ty 4 banky chipu budou jevit jen jako 1 zatez pro host system, diky plnemu bufferu.
Relavantni standard je pak tento:
https://www.jedec.org/standards-documents/docs/jesd82-30
Pro pouziti v diskretnejsi forme (ne na dimm modulu), viz google images k X10QBI-MEM1 coz se strka do https://www.supermicro.com/en/products/motherboard/X10QBI
myslim ze lrdimm.........
myslím, že to je správná odpověď - díky :-)
> Nyní už začali výrobci pamětí implementovat ECC interně, protože se dopracovali k poznatku, že bez ECC to už absolutně nejde.
100% this. Videl jsem nejake prezentace od inzenyru Micronu, tusim GDDR, a tech ECC jsou tam interne mraky.
Ono je to logicky dusledek toho, jak jde celej vyvoj kupredu. Kdysi davno vsechno fungovalo na 5V-a-vic napeti, tak si clovek mohl dovolit aby signal degradoval o nekolik Voltu a zadnej problem. ECC nebylo potreba. Dnes kdyz vsechno bezi "blsi prd nad absolutne minimalnim napeti" tak se bez ECC neda spolehlive udelat temer nic. Pro plebs muzou vyrobci placat pohadky, ze elektronika je "spolehliva", ale realne ta spolehlivost existuje protoze je uplne vsude nacpano ECC.
Klasický způsob řešení ECC spočíval v tom, že se na paměťový modul přidal jeden chip navíc, do kterého se ukládal paritní bit. Pokud při čtení dat z paměti tento bit nesouhlasil, nemá systém žádnou možnost problém vyřešit, může pouze zapsat chybu do systémového logu a doufat, že systém nespadne.
Pokud je ECC integrováno přimo do jednotlivých paměťových chipů, musí být ke každému paměťovému slovu být přidáno více paritních bitů, tak aby bylo možné chyby nejenom detekovat, nýbrž i opravovat.
ECC pro celý systém vůbec neschází, úplně stačí, když samotné paměťové chipy budou fungovat spolehlivě. Je to totiž jenom jenom takový workaround, který řeší chybu při návrhu paměťových chipů.
A Linus ať se jde vycpat, pokud se bez ECC neobejde, může si koupit serverovou desku, CPU a paměti. Vyjde ho to sice na dvojnásobek, ale bude tam mít ECC.
ECC a paritní bit jsou dvě dost odlišné záležitosti. Zatímco parita dokáže pouze detekovat některé chyby, ECC dokáže některé chyby (vzniklé třeba kosmickým zářením) i opravovat a odhalovat rozsáhlejší než co svede pouhá parita.
Skor nez kozmicke ziaranie by som cakal problem ked je na blizku mobil, pripadne vysavac. Clovek by musel mat pocitac u okna a este priehladnu skrinu aby tam mohol byt problem s tym kozmickym ziarenim.
Jsou ruzne druhy a hlavne energie kosmickeho zareni, nepr takova neutrina proleti skrz celou zemekouli - nechapou, proc by tohle mela vsrva cihel, betonu, plechova strecha ci kovovy case odstinit.
Neplette si vysoce energeticke castice (co je kosmicne zareni) s beznym el.mag zarenim (ktereho od slunce jde taky dost).
Aka je sanca se neutrino bude interagovat v pameti?
42! To tvoje neutrino ta prave zasiahlo.
To ako keby si chcel prstom ukazat na neutron atomu kyslika a spytat sa tvoju hlupu otazku. A to je kyslika v atmosfere len cca 21%.
Máte podivné představy o kosmickém záření. V úvahu totiž připadá právě jen to elektromagnetické. Částice s nábojem (protony, elektrony...) strhne magnetosféra směrem k pólům, volné neutrony, které s poločasem rozpadu 15 minut můžou přilétat prakticky jenom od slunce, ty zastaví atmosféra, která má podobný efekt, jako 10m tlustá vrsta vody. Neutrina vůbec řešit nemusíme, ta jsou tak rychlá, že jsou pro ně překážky ve směru jejich pohybu v důsledku relativistické kontrakce délek prakticky neviditelné. Takže zbývají fotony s vysokou energií, čili elmag. záření.
aaa
kedysi som skusal origo soft na injektovanie chyb do ram, na g34 platforme to fungovalo bez padu.
Pokud nastane pouze jedna chyba, tak je při aktuální používané konstrukci tuto chybu možné lokalizovat a opravit, do těch přídavných čipů se totiž neukládá pouze jeden bit pro celou buňku.
A k chybám prostě dochází, pomohlo by tak možná (trochu) umístění RAM modulů za půl metru římského olova.... Když vám běží celé dny výpočet nějakého CFD/MKP/... a objeví se tato chyba, tak to nejen nasere, ale i potrápí peněženku. A dříve (nevím jak teď) se třeba v letectví musely provádět výpočty pouze s ECC RAM.
Linus má Threadripper a ECC, problém má hlavně s tím, že pak lidi od jádra mrhají časem na zkoumání "chyb", které jsou ve skutečnosti způsobené nestabilním HW.
Mě přijde že si spíš maloval, že časem budou JEN ECC paměti a ono nic a tak prská. Moje zkušenosti s ECC jsou rozporuplné. Nejde nijak ověřit že fungují jak mají (áno DMI,BIOS,UEFI,OS, ale všichni říkají jedno "mělo by to jet"). Fajn fičura je, že člověk vidí teplotu modulu a většinou i ví, kterej modul odešel. Moc fajn už není, že i když byl server osazen ECC paměťma, jeden modul ho poslal společně s jednou databází do toalety. A DELL tento problém vyřešil pokynem k aktualizaci firmware. *thumb up* Pravda, od té doby problém nebyl a databáze se nerozpadají. Takže nevím co si o tom myslet.
Doma provozuju domácí "server" s několika VM už víc jak dekádu, bez ECC a zatím nic.
servery a jejich bugy ve FW radicu, desek, sitovek, FC a ja nevim v cem jsou kapitola sama pro sebe. To s ECC jako takobvym asi uplne nesouvisi
Ověřit funkčnost ECC můžeš s trochou štěstí vhodným přetaktováním paměti někam k hranici stability, nebo jsem četl třeba o tom, že někdo paměti zkoušel fénovat :) (to bych asi radši nedělal). Pak jsem snad kdesi zahlídnul, že některé BIOSy snad jde přepnout do nějakého testovacího režimu a dochází k vytváření chyb při práci s pamětí (ačkoliv nevím, jak přesně by to mělo ve skutečnosti fungovat) a snad to umí i nějaká placená verze Memtestu.
Zrovna před pár dny jsem si poskládal stroj na domácí "server" s Ryzenem Pro a ECC pamětí, tak bych pak taky rád vyzkoušel, že ECC opravdu funguje - asi zkusím štěstí s tím přetaktováním a snad se zadaří to udržet stabilní a sem tam vygenerovat nějakou opravitelnou chybu.
Muzes udelat ECC disable + fen, a monitorovat teploty dimmu. Melo by to spadnout u nejake. A pak zapnout ECC a snad to vydrzi o neco dele.
Osobne bych to resil spis jehlou s malym odporem vuci zemi a zkratovaval datove signaly :) Bez ecc to ma sletet hned, s ECC nikdy (kdyz budu delat jeden signal naraz).
Tak hlásím úspěšné otestování :). Na to zkoušení s jehlou jsem tak úplně neměl koule, ale zkusil jsem kombinaci přetaktování + fén. Teplotu se mi bohužel monitorovat nepovedlo - buď ji modul nezobrazuje, nebo nevím, jak se k ní dostat.
Každopádně, kdyby to někoho zajímalo - mám kombinaci AMD Ryzen Pro 2200GE + ASRock B450 Steel Legend + Kingston 9965745-002.A00G. Na napětí ani frekvenci CPU jsem v rámci testu nesahal, napětí paměti zůstalo na 1,2 V (nejde mi s ním hýbat), frekvenci jsem změnil z 2666 MHz na 3066 MHz. Systém naběhnul a běžel stabilně, nechal jsem ho chvíli trápit s téměř zaplněnou pamětí pomocí stress-ng. Ani po cca 5-10 minutách se v kernel logu neobjevilo nic nového, tak jsem sebral odvahu a došel pro fén :-). Kratší fénování, cca 1 minuta, na nejnižší stupeň a furt nic, tak jsem přitopil pod kotlem a přepnul na druhý stupeň (pocitově teplota tak kolem 50 °C). A za chvíli už jsem viděl detekovanou a opravenou chybu, tak jsem pokus úspěšně ukončil. Zkoušet vyvolat neopravitelnou chybu se mi už fakt nechtělo :-).
Tady jsou ještě relevantní kousky informací týkající se paměti/opravené chyby, pokud by někdo chtěl vědět, jak se to ve skutečnosti projevuje v systému (pro mě třeba bylo tohle první setkání s ECC a vůbec celkové bádání kolem toho, co a jak kolem ECC na Ryzenech (ne)funguje, taky nebylo zrovna přímočaré):
# dmidecode -t memory
Handle 0x000E, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Multi-bit ECC
Maximum Capacity: 128 GB
Error Information Handle: 0x000D
Number Of Devices: 4
Handle 0x0015, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000E
Error Information Handle: 0x0014
Total Width: 128 bits
Data Width: 64 bits
Size: 16 GB
Form Factor: DIMM
Set: None
Locator: DIMM 0
Bank Locator: P0 CHANNEL A
Type: DDR4
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 3066 MT/s
Manufacturer: Kingston
Asset Tag: Not Specified
Part Number: 9965745-002.A00G
Rank: 2
Configured Memory Speed: 3066 MT/s
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V
# dmesg
[ 988.487839] mce: [Hardware Error]: Machine check events logged
[ 988.487843] [Hardware Error]: Corrected error, no action required.
[ 988.489381] [Hardware Error]: CPU:0 (17:11:0) MC15_STATUS[Over|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0xdc2040000000011b
[ 988.491028] [Hardware Error]: Error Addr: 0x0000000223f74a40
[ 988.491029] [Hardware Error]: IPID: 0x0000009600050f00, Syndrome: 0x000040200a401000
[ 988.491031] [Hardware Error]: Unified Memory Controller Ext. Error Code: 0, DRAM ECC error.
[ 988.491045] EDAC MC0: 1 CE on mc#0csrow#0channel#0 (csrow:0 channel:0 page:0x243f74 offset:0xa40 grain:64 syndrome:0x4020)
[ 988.491046] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD
# edac-util -rfull
mc0: csrow0: mc#0csrow#0channel#0: 1 Corrected Errors
mc0:csrow0:mc#0csrow#0channel#0:CE:1
mc0:csrow1:mc#0csrow#1channel#0:CE:0
mc0:noinfo:all:UE:0
mc0:noinfo:all:CE:0
Bozi!
Jsem zapomnel dodat ze MCE (machine check exception) je treba v kernelu zapnout (ne vzdy tam bejva), a pak jeste existuje app-admin/mcelog balicek.
ten pán s těma mínusama má v celku pravdu... 8+1 bit (9 ram chipů místo 8) je parita a opravdu jen víte že chybujete, ale opravit nic nejde. Pokud chcete opravovat, tak záleží jak moc odolné to chcete - kolik chyb chcete být schopni opravit - čím odolnější to bude tím více ochranných bitů je třeba. Doporučuji kouknout na wiki na reed-solomonův kód....
No právě že pravdu nemá když píše, že parita je klasický způsob řešení ECC. Není, parita je jen řešení EDC (a ještě pro detekci pouze jedné, resp. lichého počtu chyb) ;)
Boha jeho, zadnych "8+1 bit s deviti cipama" a "jen paritou" se v pripade dnesnich DIMM nejedna!
DIMM je bud osazen jako 64-bit (non-ECC), nebo 72 bit (ECC). A tech 8-bit pri pouziti ECC zarucuje single-bit error correction a double-bit error detection.
To, ze ma dimm 8/9 cipu je jenom implementacni detail - kdyz tam jsou pameti s 8-bit rozhranim. Klidne muze mit dimm i 16/18 cipu, nebo take 32/36 cipu, pripadne nejakou asymetrickou kombinaci. Vzdy se jedna ale o 64bit vs 72bit konfiguraci.
Nvidia pro vypocetni Tesly umoznovala zapnout ECC - a clovek tim prisel o cast kapacity (protoze tam nebyl onen devaty cip, a gpu nemelo jinou siri zbernice). Proste se tam ty ECC data namixovali, ve stylu jako kdyz prekonfigurujete R0 pole na R5 pole, bez pridani noveho disku - vyuzitelna kapacita klesne.
To by mohlo byt dobre reseni i na urovni klasické RAM ne ? Stačilo by pár obvodů v CPU a člověk by si mohl určit úroveň ECC přímo v biosu (čímž by samozřejmě zaplatil velikostí RAM, ale who cares při dnešních cenách)
U CPU by to melo znatelnejsi dopad na vykon, protoze tam mate par jader a ty vicemene cekaji na data z pameti (ktera se cte v dost random poradi), pokud se nepouzije nejaky chytrejsi pre-fetch. Teoreticky muze vykon klesnout i na polovinu (potrebujete dva BL8 prenosy aby jste vyhovel puvodnimu BL8 cteni), a zaplatite dvojnasobkem pameti - takze 4x zhorseni.. to uz radeji ten Xeon nebo AMD :-)
U GPU jsou ty extra latence marginalni, z pohledu cele karty, protoze architektura je navrzena na masivni paralelismus a data se spis zpracovavaj sekvencne (pokud je vypocetni kernel tedy optimalizovan), takze kdyz to na milion cyklech udela start/stop latenci treba i 100 taktu, tak je to zanedbatelny. GPU holt tolik "neseekuje" a jde tam optimalneji naskladat data.
Jeste u tech GPU se pouziva urcity druh wear-levellingu, tj. stranky ktere vykazuji ecc chyby nebudou nadale pouzivany: https://docs.nvidia.com/deploy/dynamic-page-retirement/index.html
(a neverim ze neco takoveho existuje u CPU, ze kdyz to zahlasi MCE, tak aby kernel tuhle cast odmigroval do zcela jine stranky)
Tak to jsem si to představoval moc jednoduše :)
Jeho ústa mluví o náhodných chybách, ale jeho tělo mluví o mimozemšťanech. Sdílejte, než to No-X (pozemské jméno? Sotva!) smaže.
:-DD Sdělení dne! Té nejzásadnější důležitosti! :-D
Nepřijde mi to vůči Intelu fér.
Neviděl jsem ještě mobil s ECC pamětí, a to jsou zařízení, které se rebootují daleko méně často, než desktopy s Intelem bez ECC, tudíž je tam mnohem větší prostor pro projev vzniklé chyby.
Jinak samozřejmě souhlas, na druhou stranu kdo chce, ten si může koupit starší pracovní stanici, nestojí to majlant, v podstatě za určitou daň (záruka, spotřeba, ne tak vysoký výkon, pokud člověk chce maximum) je to i levnější.
Zrovna v mobilech je paměťový čip integrovaný buďto pár milimetrů od SoC nebo i přímo v pouzdře SoC. Žádné moduly, žádné sloty, žádné dlouhé dráhy v PCB. Paměti v mobilech jsou podstatně kvalitnější (LPDDR…) než co máme v desktopu. Dále jsou paměti v mobilech používané na nominální JEDEC frekvenci, zatímco paměti v desktopu (vše nad DDR4-3200) jsou z hlediska JEDEC standardu přetaktované. K tomu ani v mobilech nedochází k tak intenzivnímu vytěžování, jako v desktopu. Takže je tam mnohem méně příležitostí ke vzniku chyb než v desktopu. To jen k fér / nefér srovnávání.
Tím, co popisujete, snížíte riziko chyby při přenosu. Ale ne riziko vzniku chyby přímo v paměťové buňce, kde nechápu, proč by low power paměti měly mít vyšší odolnost (to spíš naopak).
Už nějakou dobu je známý např. bitsquatting, https://www.securitee.org/files/bitsquatting_www2013.pdf , například pokud dostatečně dlouho uchováváte DNS cache, tak je vysoká šance, že se vám flipne bit, a omylem polezete někam jinam. Toho je aktivně využíváno, jak je v tom papíru k dočtení, a na mobilu máte mnohem větší šanci, že se s tím potkáte, protože ta cache je tam mnohem delší dobu.
Samozřejmě i cache se dá chránit softwarově a je možné, že to Android třeba zrovna v tomto případě řeší, jde mi spíš o princip, že paměť v mobilech považuji za náchylnější.
„nechápu, proč by low power paměti měly mít vyšší odolnost“
To jsem taky uvedl v předchozím příspěvku:
„Dále jsou paměti v mobilech používané na nominální JEDEC frekvenci, zatímco paměti v desktopu (vše nad DDR4-3200) jsou z hlediska JEDEC standardu přetaktované.“
Já mám v mobilu 4GB paměti a v pracovní stanici 64GB RAM.
Takže náchylnost na vznik jedné chyby v PC mám 16× větší než v mobilu.
Mobily jsou pro decka, chlapi si vypijou :-)
Linus +1
Nevím proč Linus řeší ECC když v DDR5 už je povinně - zbytečná diskuze.
- Hlavním faktorem pro ECC je výroba na technologické hranici. Tlak na maximální výkon a minimální náklady vede k tomu, že single bit chyby už nejsou náhodné a vzácné, ale software běžící na DDR5 by bez ECC byl nestabilní a nepoužitelný.
- Druhý hlavní důvod není radiace, ale útoky typu Rowhammer.
Nicméně ECC není uplnou ochranou před bit-flip útoky.
- Běžně stačí otočit 1 bit, pro ECC je potřeba otočit 3 bity... je to těžší, ale jde to:
https://www.vusec.net/projects/eccploit/
Tak celé to hodně připomíná hon na čarodějnice. Vymyslíme problém, ukážeme na viníka a předhodíme ho davu. A dav s nadšením lynčuje.
Kdo chtěl ECC mohl ho mít roky. Navíc nastupující generace bude mít ECC vždy, takže dělat kolem toho povyk je spíše jeho PR nebo klikbait mediálních prostitutů...
ja som to skor pochopil v tom vyzname, ze vdaka "ignorovaniu" resp. doslova potlacaniu/brzdeniu ECC, nebol po nich dostatocny dopyt a teda nasledne aj vyvoj/vyroba/cena a teda celkova dostupnost ..
Dobre chapu co se resi.
Nechapu na co mi ta ECC realne ale bude.
Prileti kosmicke zareni, flipne bit a? Jednou rocne mi crashne hra? Zkompiluje spatna binarka? Zartefakti se 1 frame filmu?
Proc by me tak mala chyba mela zajimat u osobniho pocitace?
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.