Dotaz: vymena hw AMD za XEON ubuntu 20.04

[sten_f]

Zdravim vas damy a panove,

mate pls. nekdo zkusenost s vymenou HW, deska, ram, cpu AMD za intel Xeon na "zivem" systemu bez nutnosti reinstalace?

Mam nainstalovan ubuntu 20.04 s zfs a virtualizacema a chci vymenit HW.

Pojede to?

Dekuji za zkusenosti a nazory.

Odpovědi

[Pavel 'TIGER' Růžička]

V rámci jedné platformy to nebývá problém. Ale u změny platformy mohou nějaké problémy nastat. Já bych si udělal zrcadlo disku a někde vedle na stole si to vyzkoušel. Lepší, než být potom nemile překvapen.

[trekker.dk]

Zásadní otázka není, jestli to půjde, ale proč chcete dělat takovou ptákovinu. (Jako měnit AMD za Intel v době, kdy hardware od AMD poráží Intel snad ve všech aspektech kromě marketingových svinstev typu "prémiová" maximální kapacita pamětí.)

Nicméně moje zkušenosti jsou takové, že vyměnit nainstalovaný Linux do jakéhokoliv jiného podporovaného hardwaru je bezproblémová operace. Teda samozřejmě kromě drobností, se kterými se musíte vypořádat z principu, jako že se například přejmenují síťovky.

Jediné, na co je potřeba dát si pozor, jsou disky, pokud nemáte stejný hardware - konkrétně pokud např. v tom původním stroji je nějaký hardwarový RAID, zatímco v tom novém ne. Ale hádám, že ZFS s hardwarovým RAIDem asi neprovozujete.

[sten_f]

Diky za reakci.

Potrebuju ECC, vykonove mi xeon 2136 bohate staci a cenove je to stejne.

[LarryL]

Nevím co to máš za AMD, ale u nějakých novějších se tady na fóru řešilo, že AMD umí ECC, akorát to oficiálně neuvádí.

[Max]

Některé desky umí ECC v tom smyslu, že je sežerou a funguješ. Zda fungují i všechny ECC fce včetně notifikací o chybách, to fakt nevím. Osobně bych do toho nešel.
Zdar Max

[LarryL]

V této diskuzi na to přišla řeč.

Na firemním serveru bych do toho taky nešel, ale pokud to má být jen na takovéto domácí žvýkání a v nějaké recenzi bude uvedené, že kombinace určité MB a ECC RAM fungují spolehlivě, tak není důvod ušetřit nějakou tu kačku.

[j]

Predevsim je naprostej nesmysl, do neceho takovyho ECC davat. Pokud to neumi reportovat a pripadne nejak reagovat, je to zcela khovnu.

---

Dete s tim guuglem dopice!

[LarryL]

Ale to nevíme jestli to neumí reportovat a reagovat. Původní myšlenka byla, že AMD pouze ECC oficiálně nepodporuje v běžném segmentu, ale jinak je ECC funkční. Když tak se proklikni na ten článek v tom odkazu třeba tam zjistíš víc.

[Petr Fiedler]

Příloha:

• mt86Screen-20210813-212302.jpg (58105 bytů)

Já teď mám:

• MB ASRock B550 Steel Legend
• CPU AMD Ryzen 7 5800X
• RAM 2x Kingston KSM26ED8/16ME ECC

Na stránkách ASRocku u mojí MB ve specifikaci v sekci "Memory" uvádí:
"AMD Ryzen series CPUs (Vermeer) support DDR4 4733+(OC) / 4666(OC) / 4600(OC) / 4533(OC) / 4466(OC) / 4400(OC) / 4333(OC) / 4266(OC) / 4200(OC) / 4133(OC) / 4000(OC) / 3866(OC) / 3800(OC) / 3733(OC) / 3600(OC) / 3466(OC) / 3200 / 2933 / 2667 / 2400 / 2133 ECC & non-ECC, un-buffered memory*".

V "Memory QVL (Vermeer)" uvádějí, že mimo jiné podporuje:
"DDR4 Kingston 2666MHz 16GB KSM26ED8/16ME (ECC)".

Když jsem na netu hledal, jak poznám, že mi ECC RAM neběží v režimu NON ECC, tak jsem vždy našel, že by to měl ukazovat Memtest86+. Tak jsem jej pustil a ukazuje mi, že ECC je zapnuto viz. příloha.

[LarryL]

Bylo by skvělé kdyby Max nebo J navrhli nějaký test jak zjistit zda fungují i všechny ECC fce včetně notifikací o chybách. Hodně by mne zajímalo (předpokládám, že tebe taky) jestli v této "levné" (dektopové) konfiguraci je to opravdu plnohodnotné ECC nebo zda tomu něco chybí a je to jen ECC placebo.

[Petr Fiedler]

Ano, bylo by to skvělé a taky by mě to zajímalo.

BTW: Andrejovi ten report funguje.

[Max]

V jednom threadu na redditu jsem četl, že to týpek na AMD platformě testoval tak, že paměti přetaktoval a pak koukal, zda bude docházet ke korekcím chyb, co vznikaly tím přetaktováním.
Kromě tedy ukázky z memtestu, že je ECC aktivní, to ještě testovali takto.
Zdar Max

[Max]

Tady je jeden z těch článků, na které jsem narazil včetně popisu, jak to ověřit.
Guide: How to confirm unbuffered / unregistered ECC RAM is working on Ryzen.
Zdar Max

[Petr Fiedler]

Super. Jak bude čas, tak to zkusím. Ten návod je už 3 roky starý, tak snad bude funkční.

[Petr Fiedler]

Tak jsem se pustil do toho Maxem odkázeného postupu. Autor v něm jako příklad uvádí, že když máš RAM, která pracuje na 2400MHz, tak jí máš přetaktovat např. na 3200MHz a pokud ti OS z LiveUSB nenabootuje, tak máš jít třeba na 3000MHz a když se ti povede nabootovat, tak pak pokračovat dále viz. ten postup. Moje RAM pracuje na 2666MHz, takže jsem jí přetaktoval na 3600MHz a v pohodě nabootoval Live. Bál jsem se pak ještě přidat, protože s přetaktováváním nemám vůbec žádné zkušenosti a nechtěl jsem si paměti nějak poškodit. Každopádně z 2666MHz na 3600MHz mi přišlo dost. Vypnul jsem swap soubor, nainstaloval memtester a edac-utils a spustil test.

mint@mint:~$ sudo memtester 28G
memtester version 4.3.0 (64-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 28672MB (30064771072 bytes)
got  28672MB (30064771072 bytes), trying mlock ...locked.
Loop 1:
  Stuck Address       : testok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : ok         
  Checkerboard        : ok         
  Bit Spread          : ok         
  Bit Flip            : ok         
  Walking Ones        : ok         
  Walking Zeroes      : ok         
  8-bit Writes        : ok
  16-bit Writes       : ok

Tohle jelo asi 2 hodiny. Nejdéle z toho jel test na "Bit Flip", asi 40 minut a podle testu OK. Po dokončení testu se spustilo druhé kolo, takže to jsem stornoval.

Loop 2:
  Stuck Address       : testing   7^C
mint@mint:~$ edac-util --v
edac-util: Error: No memory controller data found.

Bohužel ten druhý příkaz mi ale nic kloudného nevrátil. Myslím ale, že ECC by fungovat mělo. RAM jsem přetaktoval skoro na 4GHz a "Bit Flip ok". Pro test jsem použil Linux Mint 20.2 s jádrem 5.4. Raději bych aktuální jádro, ale neměl jsem to jak udělat.

Jeslti máš (nebo někdo) nějaký nápad jak se dostat k tomu výpisu, tak to klidně ještě zkusím. Klidně i s více přetaktovanou RAM, pokud mě někdo ujistí, že jí nezničím.

[LarryL]

U toho druhého příkazu mají překlep (chybí "s"). Správně má být edac-utils --v

[Petr Fiedler]

Nemají tam překlep. Při instalaci píšeš "edac-utils" a při aplikaci "edac-util". Nebyl jsem si tím ale jistý úplně a tak jsem to zkusil ještě jednou. Všechny fans jsem pustil naplno, u RAM jsem zvedl takt na 4000MHz a Live jsem v pohodě nabootoval. Test jsem ale do konce běžet nenechal, protože "edac-util --v" mi vracelo stejnou chybu jako včera. Ze zvědavosti jsem zkusil "inxi -m" a bylo vidět, že RAM moduly mají takt 4000MHz. Proč ale nefunguje "edac-util --v" nechápu. Třeba někdo něco poradí.

[Petr Fiedler]

Ještě mě něco napadlo. Když pustíš "sudo memtester 28G", tak to pak píše "try mlock ..." "locked". Možná "mlock" znamená memory lock. Takže to nějak uzamče tu RAM a pak k tomu edac-util nemá přístup. Když jsem to včera při druhém kole stornoval, tak se možná ta RAM neodemkla. A dnes jsem to zkusil během testu, kdy je zamknutá, takže edac-util zase možná neměl přístup. Zkusím to pustit ještě jednou s parametrem "1" pro [loop] a po dokončení to možná už přístupné bude. Jdu na to. Pak napíšu.

[LarryL]

Omlouvám se za mystifikaci s překlepem, na první pohled to tak vypadalo. Mrkni na článek kde používají taky EDAC. Je tam "# edac-util -v" takže je asi nutné to spustit jako root nebo se sudo.

[Petr Fiedler]

Tak to bylo tím jádrem. Stáhl jsem ten Mint Edge s jádrem 5.11.*, který odkazoval Radek a tam už edac-util fungovalo. Jenomže 4000MHz bylo pořád stabilní a k žádným chybám nedocházelo a tak jsem si hrál s takty, až mi přestal fungovat pc. Jdu položit dotaz co s tím?

[LarryL]

Vypadá to, že otestovat ECC není tak triviální. Tady jsem našel článek když to testovali na Windows 10 a verdikt je, že single-bit chyby to dokázalo opravovat, ale two-bit chybu už ani ECC opravit neumí a celý systém by se měl zastavit, aby nedošlo k poškození dat, což se ale nestalo a systém běžel dál:

HOWEVER, things are not quite perfect. On that last line you will notice “1 UE”. That is an uncorrected error (UE), otherwise known as a two-bit error or a hard error. Two-bit errors cannot be corrected by ECC memory. What is supposed to happen when they occur is that they should be detected, logged and ideally the system should be immediately halted. These are considered fatal errors and they can easily cause data corruption if the system is not quickly halted and/or rebooted. Regrettably, only 2 of the 3 steps happened. The hard error was detected and it was logged, but the system kept running. The only reason that it’s the last line on that image is because we immediately took a screenshot just in case the system would halt, but that never happened.

Možná, že Linux by se u two-bit chyby zastavil, těžko říct.

[LarryL]

...aha, jak sem se do toho začetl, tak ten citovaný anglický odstaveček se týká Linux a až potom píší jak je to na Windows 10.

[Petr Fiedler]

Tak jsem přetaktoval RAM na 4000MHz, pustil ten test a u testu na bit flips systém spadl. Nemyslím si, že by to bylo two-bit chybou, protože kdyby se systém korektně vypnul, tak by to zůstalo viset na hlášce "~ Vyjmětě prosím instalační médium a stiskněte ENTER". Takže si myslím, že 4000MHz už prostě bylo moc. Tak jsem to přenastavil na 3600MHz, pustil test znovu a tentokrát dojel do konce. Po zadání "sudo edac-util -v" jsem ale dostal stejnou chybu, jako včera. MOŽNÁ ještě zkusím nějaké distro s novějším jádrem, než 5.4.0-*. Moc se mi ale nechce ty RAMky takhle trápit. Uvidím.

[k3dAR]

Mint ma (se Cinnamon) variantu Edge ktera ma cerstvejsi (aktualne 5.11) jadro...

[Petr Fiedler]

Dobře, ještě to zkusím, i když už jsem nechtěl, protože teď jsem to zkoušel z Ubuntu 21.04 a tam mi edac-utils nešlo nainstalovat ani z terminálu, ani deb balík. Přitom byl pro Ubuntu 21.04, ale jádro hlásilo nějaký problém (už nevím jaký).

Díky

[j]

System kterej umi ECC ti predevsim bude reportovat v BIOSu ze to umi, a tamtez najdes informace o pripadnych chybach. A ty informace jsou typu "nastala opravitelna/neopravitelna chyba ECC" typicky by ses tam mel i dozvedet na kterym modulu, ale to uz neni tak uplne pravidlo (coz pak znamena hrat diskoteku s modulama pri pokusech zjistit kterej to je, abys trebas ve finale zjistil, ze zadnej, protoze je to MB).

Pretocenim ramky vetsinou nedosahnes ECC chyb, spis se to chova tak, ze bud jeste spolehlive funguje nebo uplne zdechne. A kupodivu, naprosto drtiva vetsina chyb rameti ( i non ecc) vede k padu systemu, pravdepodobnost, ze v ramce failne prave jeden bit a to jeste v datech je 0,0 .... 0 nic.

Kdyz uz, tak dava daleko vetsi smysl udelat v ramce R1 (neboli zrcadlo), coz lepsi HW umi, ovsem jeste sem nevidel nikoho to pouzivat, protoze tim osetris jednu z nejmene pravdepodobnych chyb, a daleko efektivnejsi je mit druhej server, protoze tim osefujes chyb daleko vic.

Kdyby byla pravda co tu blaboli Andrej, tak by na planete uz davno zadny data nebyly, protoze by vsechny poskodily chyby v ramce.

---

Dete s tim guuglem dopice!

[LarryL]

System kterej umi ECC ti predevsim bude reportovat v BIOSu ze to umi, a tamtez najdes informace o pripadnych chybach.

V tom článku se píše:

This lack of settings severely hampers the overall ECC functionality, since a big part of it is that the motherboard should be able to log errors. Right now, no such logging capability exists.

Takže MB ASRock X370 Taichi to neumí logovat (neuměla v době psaní článku), ale to podle mne neznamená, že neumí opravovat single-bit chyby.

Pretocenim ramky vetsinou nedosahnes ECC chyb, spis se to chova tak, ze bud jeste spolehlive funguje nebo uplne zdechne.

Jak se dívám, tak v tom článku se místo zvýšení frekvence rozhodli pro změnu časování a pak na tom spustili Stress:

Instead of pushing up the memory frequency, we decided to cause instability by tightening the timings. Much to our surprise, the Crucial DDR4-2400 ECC modules proved to be quite remarkable. In order to cause instability we had to tighten the timings from 17-17-17-17-39 all the way down to 14-14-12-11-21. Sticking to Ubuntu for now, we ran the 'Stress' utility (sudo apt-get install stress) to stress the memory with 50 processes, each requiring 256MB, for a grand total of 12.8GB of heavy RAM usage.

PS: případný návod pro Petra Fiedlera => místo frekvence změnit časování.

[Petr Fiedler]

Ten článek jsem zatím ještě nečetl, ale přečtu si jej a možná to i zkusím. Dost zásadní je i tohle.

[Radek]

K čemu přesně potřebuješ ty ECC paměti? Obcas to bývá precenovane, respektive problémy nastávají jinde, než v paměti.

[sten_f]

?

Tak doufam, ze kdyz nastane problem v HW RAM, jakoze se zmeni nejaky bit jinak nez "korektnim zapisem", tak to poznam.

Nechapu proc by nekdo pouzil non-ECC, kdyz ma za podobnou cenu ECC.

 

 

 

 

[alkoholik]

Nechapu proc by nekdo pouzil non-ECC, kdyz ma za podobnou cenu ECC.

CAS latency?

[j]

Pokud v tom nemas nejaky veci kompilovany primo pro danej CPU, nemel by to v tomhle ohledu byt problem. Jak uz zaznelo, problem muze nastat s tim, ze ty nevymenis jen CPU, ale komplet vse, a muzes narazit na to, ze pro nejaky soucasti nebudes mit ty spravny moduly.

Takze "nejak" by to nastartovat melo, a zbytek by mel byt resitelny. Jen pocitej s tim, ze je treba mit po ruce stroj, kterej se dostane na net, protoze jednou z komplikaci muze byt, ze ti nenabehne sit a to tak ze vubec (to ze se sitovky v ramci "predvidatelneho pojmenovani" budou jmenovat zcela random je 100% jisty).

---

Dete s tim guuglem dopice!

[Max]

Reinstalace nebude nutná. Měnil jsem architekturu několikrát. Na Linuxu s tím není problém, jen se zavedou jiné moduly a funguje se dál.
Zdar Max

[Jendа]

Ano, naprosto bez problému, čekal bych, že to nabootuje rovnou bez nutnosti jakýchkoli úprav. (potenciální problém: ZFS modul zkompilovaný s -march=native)

Nainstaloval bych balíček intel-microcode.

[trekker.dk]

čekal bych, že to nabootuje rovnou bez nutnosti jakýchkoli úprav

Jako že se na úplně jiném hardware trefí jména síťovek? To je hodně odvážné očekávání...

[Jendа]

Tak mně se teď na Debianu děje, že když je síťovka jedna, tak se vždycky jmenuje eth0 (už si to, zdá se, nepamatuje MAC adresy že by to pak inkrementovalo čísla).

Ale jinak jsem tím myslel nabootuje tak, že se přihlásí na konzoli, ne že hned pojede i síť.

[trekker.dk]

Vážně eth0? I když to možná máte v grubu nějaké to net.ifnames=0, mně to dělá ta "předvídatelná" jména, což je u integrovaných síťovek en[ops]X a u síťovek v PCI slotech jakási změť číslic a písmen. (Proto považuju nabootování s funkční sítí za nepravděpodobné, boot do konzole asi v pohodě.) Ale jinak jo, IIRC od verze (Debianu) 10 lze udev ještě donutit, aby síťovku podle MAC adresy pojmenoval, ale nové mají vždycky nějaké výchozí jméno. Od verze 11 udev nastavení dle MAC zcela ignoruje.

[Jendа]

Ano, všude mám net.ifnames=0 biosdevname=0.

[Petr Fiedler]

Když jsem Clonezillou naklonoval OS z PC na NB, tak mi vše fungovalo hned. Jen jsem v /etc/hostname a /etc/hosts změnil název stroje a hotovo. Kdybych ale v jedné LAN neprovozoval oba stroje současně, nemusel jsem dělat ani to.

[Peter Golis]

Kvôli tomuto sa pred rokmi začali nazývať názvy sieťových rozhraní podľa PCI slotu, alebo v prípade USB zas podľa MAC adresy. Vtedy to ľuďom vadilo, lebo boli zvyknutí na zjednodušený zápis kde dva rovnaké kusy s rôznymi MAC adresami občas urobili galibu. Keď sa pri štarte OS nainicializovali v opačnom poradí.

Ale to je v tomto prípade asi už jedno, ak človek naozaj nevypol takúto funkcionalitu prehľadného premenovávania.

[Jendа]

Kvôli tomuto sa pred rokmi začali nazývať názvy sieťových rozhraní podľa PCI slotu

Ano, to bylo nejlepší, přidal jsem grafickou kartu nebo SATA řadič a přejmenovaly se síťovky!

[k3dAR]

stejna zkusenost, na jednom serveru sem nechal vychozi "predvidatelne", pak mi tam zapojili sata radic a prestala fungovat sit protoze sitovky se prejmenovaly...

a to mi pripomelo ze do jineho serveru mi pred par dnama take dali sata radic, sit bezela takze me to netrklo, ale ted koukam ze to prejmenovalo jednu ze dvou internich sitovek (zrovna tu co neni pripojena takze proto sit sla) a pak to prejmenovale nektere ve slotu, takze bonding nejede na 8x GLAN ale jen na 6x GLAN...

[k3dAR]

konkretne to z 10 prejmenovalo 5 sitovek... (jen pridani SATA radice)

enp0s31f6
enp9s0 => enp10s0

enp3s0f0
enp3s0f1
enp4s0f0
enp4s0f1

enp16s0f0 => enp17s0f0
enp16s0f1 => enp17s0f1
enp17s0f0 => enp18s0f0
enp17s0f1 => enp18s0f1

[Peter Golis]

Pokiaľ sa zmenilo to číslo za "P", tak sa z nejakého dôvodu zmenila pozícia v PCI(e) slote. Či už fyzicky, alebo kvôli "optimalizácii" APIC v UEFI.

[alkoholik]

To je jeste v pohode. Stare HP servery mely v BIOSu stejny slot pro obe onboard sitovky, tak jsi pri bootu se systemd dostal nastaveni site ciste nahodne.

[sten_f]

Jede to bez problemu. Nechal jsem 18.04 s kernel 5.4.0-81-generic

- trochu rve nouveau driver, ale jede.

[   54.146801] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 3 [007fb16000 systemd-logind[1852]] subc 0 class 9297 mthd 0d78 data 00000004

Kontrola ECC jsem nasel:

- lshw -class memory

capabilities: ecc
configuration: errordetection=ecc

- dmidecode -t memory

Total Width: 72 bits ( bity navic pro ecc)
Data Width: 64 bits

 

Tak diky za poskytnute info.