Új hozzászólás Aktív témák

• #4 Abu85 HÁZIGAZDA Oliverda #2

  Új Válasz 2021-01-05 13:59:50 #4

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Oliverda #2 üzenetére

  Az nem jelent semmit. Azt ki is kell használni. A HBM2 memóriáknál sincs olyan lapka, ami ne támogatna ECC-t, mégse aktív minden gyorsítón. Az, hogy ezt a szabvány kötelező részévé teszed, még nem jelent automatikus működést. Ahhoz platformszintű támogatás kell majd, vagy esetleg egy memóriamodulra helyezett chip erre a feladatra. Ha ezek nincsenek meg, akkor ugyanúgy nem lesz ECC, függetlenül attól, hogy a megvásárolt memórialapkák megfelelnének hozzá.

  A szabványalkotók a HBM és a DDR új specifikációinál azt akarták elérni, hogy a memóriagyártóknak ne legyen más választásuk, így kötelező ECC-t támogató memórialapkákat tervezniük, de az már nem kötelező, hogy ez a funkció működjön is egy rendszerben.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #6 Abu85 HÁZIGAZDA Oliverda #5

  Új Válasz 2021-01-05 14:30:12 #6

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Oliverda #5 üzenetére

  Jaj... oké segítek...

  Az on-die ECC azt jelenti, hogy egy adatbájtonként kötelező alkalmazni egy ECC bitet. Ettől a memória még nem tud ECC-t számolni, csak tárolja az információt. Az ECC valós támogatásáról vagy egy memórialapkán kívüli apró chip gondoskodik a tényleges modulon, vagy maga a platform (CPU és alaplap kombó). Ha egy modulon nincs erre külön lapka, és a platform sem támogatja, akkor ugyan bájtonként elméletben lehet egy ECC bit, de lószart sem tud vele kezdeni a rendszer, mert nincs támogatva a compute.

  Ugyanez a követelmény megvan a HBM2 specifikációban, de ott is csak a memóriára vonatkozik. Ha a rendszer nem biztosítja ez egy extra bitnyi információt, akkor a tárterület számára csak úgy bájtonként van és ennyi.

  Amit Linus felvetett, azt ez a specifikáció nem oldja meg, mert ha mondjuk az Intel nem kezdi el támogatni, akkor a DDR5 memóriákon is csak lehet bájtonként egy extra bitnyi információ, aminek örülünk, de szart sem tudunk vele kezdeni, ha nem lesz a tárterületre leszámolva. A modulra helyezett ECC compute pedig elég drága. A végfelhasználói piac árérzékeny, ott inkább platformszintű támogatás kellene, olyasmi, amit az AMD csinál, akár nem hivatalosan.

  Szóval a specifikáció annyit csinál, hogy előírja a kötelező ECC biteket bájtonként, vagyis a memóriagyártóknak úgy kell terveznie a memórialapkákat, hogy ennek ott kell a hely. De a specifikáció maga az ECC számításáról nem gondoskodik.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #9 Abu85 HÁZIGAZDA Oliverda #7

  Új Válasz 2021-01-05 14:45:28 #9

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Oliverda #7 üzenetére

  Ez nem megoldás. Nekünk valós ECC kell, ami a teljes modulon működik. A lapkaszintű valójában semmit sem ér, mert ilyeneket már eleve csinálnak a gyártók most is, csak nem szabványos formában. Ez viszont nem helyettesíti a modulra működő ECC-t, ami azért igen sok bitig tud hibát javítani. Már a DDR4 lapkák esetében is nagy a bithibák száma, amit nem szabványos technológiával oldanak meg. Mindenki csinálja, mert 10 nm-es osztályú memóriákat nem lehet ezek nélkül gyártani.

  Amiről Linus beszél az egy teljesen más követelmény. Nem a gyártást segíti, hanem a működést, és ahhoz annyi nem elég, hogy egy bitnyi információt tudjunk javítani. Sok bitnyit kell a teljes modulra.

  A HBM2-nek van egy ugyanilyen követelménye, ugyanezért. Ott is az történt, hogy az első generációs HBM-hez már voltak gyári megoldások a problémára, amire a HBM2 hozott szabványost. De ettől, hogy volt bájtonként egy ECC bit, még nem működött automatikusan a teljes stackre, kellett hozzá a rendszerszintű támogatás, mert a teljes stackre azt számolni is kellett, amit a szabvány nem biztosít. Itt sem biztosít ilyet a szabvány a teljes modulra. Ehhez kellenek külön kiegészítések, noha az már előrelépés, hogy a memóriákat eleve ECC-re kell tervezni, csak magától teljes modulra még így sem fog működni.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #19 Abu85 HÁZIGAZDA Oliverda #12

  Új Válasz 2021-01-05 15:21:28 #19

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Oliverda #12 üzenetére

  A gyártástechnológiai fejlődéssel növekszik a bithibák száma, és ezeket transzparens megoldásokkal kezeli az összes gyártó már ma is. De ez nem helyettesíti a teljes modulra vonatkozó ECC-t, az egy teljesen más probléma, és más megoldás kell rá.

  Pont arról ír Torvalds, hogy nem felesleges. Elég komoly érveket is írt, amik ellen a memóriagyártók kb. annyit tudnak felhozni, hogy "csak".

  #18 Emilió : Az on-die ECC nem egyenlő a teljes modulra vetített ECC-vel. Utóbbit mindenképpen kell támogatni platformszinten. Ez csak úgy nem tud működni egy memóriamodulon, hacsak nem raknak a modulra egy külön lapkát, az ECC compute-hoz, de az nagyon drága.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

• #22 Abu85 HÁZIGAZDA Emilió #20

  Új Válasz 2021-01-05 15:48:10 #22

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Emilió #20 üzenetére

  El kellene olvasniuk újra a specifikációt.

  Ez a fajta ECC nem helyettesíti a teljes modulra levetített ECC-t. Az on-die verzió arra való, hogy a lapkán belüli bithibákra adjon valami szabványos választ, de nem szabványosan már így is alkalmaznak különböző technológiákat a gyártók, mivel a gyártástechnológia fejlődik, ezekkel pedig nő a bithibák száma, amit korrigálniuk kell. A DDR5 megoldása erre a problémára egy szabványos funkció, de az amiről Linus Torvalds beszél, azt nem tudja megoldani, mert nem az volt a célja.
  A teljes modulra vetített ECC-hez egyrészt ECC-t támogató memórialapka kell, ahol van elég cella ahhoz, hogy bájtonként legyen egy ECC bit, ami a DDR5 esetében szerencsére kötelező lesz. De teljes modulra levetítve ezt számolni kell, és ehhez két opció van. Vagy kell olyan platform, ami támogatja az ECC-t (akár nem hivatalosan is), vagy kell a modulra rakni egy olyan chipet, ami képes számolni az ECC biteket. Utóbbi esetben a teljes modulra levetített ECC anélkül is működhet, hogy lenne a platformnak rá támogatása, de ilyenkor a modul ára is nő, hiszen kell rá egy extra lapka, amiben van egy csak ECC-t számoló processzor.
  A DDR5-től tehát nem lesznek kisebbek az ECC kiépítésének költségei, de ezek amúgy sem nagyok már.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Új hozzászólás Aktív témák