Dotaz: Bezproblémový chod AMD Ryzen 9 5950X pod Linuxom - aká doska a RAM?

[/dev/null]

Zdravim, chcem poradiť najlepšie od vlastníkov Ryzen 9 5950X - potrebujem bezproblémový a stabilný chod 5950Xka pod Linuxom (Ubuntu) - akú dosku zvoliť (chipset/výrobca) a akú RAM? Máte niekto skúsenosti s prevádzkou 5950X s 64GB alebo 128GB RAM ? A čo 2 x PCIe 4.0 nvme - koľko dokážu v SW raid0 dať rýchlosť čítania a zápisu ? A čo chladič ? Ísť do uzatvoreného vodníka ? V zostave bude jednoduchá GPU, CPU bude celé dni kompilovať/renderovať.

---

---

Odpovědi

[Max]

Tak chceš Asrock nebo nějaký Asus s chipsetem X570.
Paměti chceš nějaké ofiko kompatibilní. Nebrat tedy podle specifikace, ale podle ofiko compatibility listu. Čipy se na pamětech mění, takže stárá infa o "B-Die"(Samsung), J-Die (Hynix), E-Die (Micron) už nebudou platit a budou mít asi jiná označení. Každopádně pořád platí, že Samsung a Micron jsou na tom s kompatibilitou nejlépe. Crucial má v sobě převážně čipy od Micronu, takže velmi dobrá kompatibilita + fungují i XMP profily. Platí ale, že raději si i ten vybraný Crucial modul zkontroluj, zda tam neudělali soudruzi nějakou změnu .
Je to k nevíře, ale kompatibilita pamětí je prostě stále problém a jen na specifikace nelze hledět.
Zdar Max

[Petr Tomášek]

Jaký je tvůj argument proti Gigabyte nebo MSI (ne, že by to byly pro mě sympatické značky)?

(Mně osobně nejsympatičtější jsou AsrockRack a Supermicro, jenže většinou chybí serverovým deskám alespoň jedna, dvě zásadní vlastnosti pro desktop...)

P.S. Zajímavé je, že u posledních X570 desek je to právě Gigabyte a MSI, kdo zveřejňují v manuálu blokové schéma desky, což je pro mě výrazné plus...

[LarryL]

A čo 2 x PCIe 4.0 nvme - koľko dokážu v SW raid0 dať rýchlosť čítania a zápisu ?

Zrychlíš jen sekvenční čtení a zápis. Náhodné tím nenavýšíš.

[Petr Tomášek]

Náhodné tím nenavýšíš

Zdroj?

[LarryL]

Nenajdu to. Byl to článek včetně bechtestů, kde měřili rychlosti SSD v RAID0. U náhodného čtení k žádné změně nedošlo. Google ti určitě nějaké takové články najde.

Zároveň mi to připadá logické, protože RAID0 ti zkrátí pouze čas pro přenos souborů (sekvenční čtení/zápis), ale nedokáže zkrátit prodlevu pro nalezení buňky ve které se nachází požadavaná data (náhodné čtení), to záleží na řadiči v SSD.

[Petr Tomášek]

Mně to teda logické nepřipadá, pokud máš dostatečně rychlý procesor, bude "prodleva pro nalezení buňky" poloviční (čtvrtinová, atd), protože to "nalezení buňky" probíhá paralelně ve dvou (nebo více) SSD.

Podle mě to bude velmi závislé na rychlosti procesoru a konkrétní sestavy a nedá se to takto paušálně říct, že raid na NVMe se *vždy* chová takto... Samozřejmě každý procesor přidá nějakou latenci, ale je otázku jakou...

[LarryL]

pokud máš dostatečně rychlý procesor, bude "prodleva pro nalezení buňky" poloviční

Nerozumíme si. Ta prodleva (latence) nenastává v procesoru, ale přímo v řadiči v SSD.

Samozřejmě i různé filesystému mohou být různě rychlé, ale o tom teď nemluvím.

probíhá paralelně ve dvou (nebo více) SSD

To paralelní čtení/zápis se ti hodí právě až ve chvíli když si řadič na SSD našel co potřeboval a už se jen sosá. V tu chvíli bude bottleneck max. rychlost sekvenčního čtení/zápisu daného disku, případně maximum co dokáže přenést SATA/PCIe. Takže dejme tomu, že sosáš max. rychlostí 2500 MB/s a když máš 2 disky tak můžeš sosat dohromady rychlostí 5000 MB/s.

Kdybys pracoval jen se 4KB soubory, tak zapojením dvou NVMe do RAID0 v podstatě nic nezíkáš. Čím jsou soubory větší tím větší rychlost u RAID0 získáš, protože ta rychlost je složena právě z konstatního času pro nalezení buňky (režie řadiče) a z variabilního času, který je dán propustností dat. A ty tím RAID0 zvýšíš jen propustnost.

[j]

Ehm ... ani ve snu. R0 dela presne to, co napsal predrecnik - v idealnim pripade zkrati pristupy na 1/2.

Mel by ses doucit jak fungujou disky ... kazdej disk ma zakladni parametr, kterej se jmenuje IOps. To je presne to, co definuje vykon disku. Zapojeni disku do libovolnyho raidu = scitani IOps, v zavislosti na typu raidu. R0 ma jedinej ucel - zvednout IOps. A pochopitelne cim vyssi IOps ten diskovej system ma, tim kratsi pristupovy casy vykazuje. R0 === vysledne IOps odpovidaji souctu IOps vsech disku v poli.

Uz to ze sem tahas MB ukazuje jednoznacne na to, ze o tom nevis vubec nic!

---

Dete s tim guuglem dopice!

[LarryL]

Rád se něco nového přiučím. Pokud už mi nechceš nutit myšlenku, že swapfile je soubor jako každý jiný, tak pojďme diskutovat o zkrácení času při náhodném čtení

Dejme tomu, že jeden Samsung 980 PRO má latenci 41 mikrosekund. Tato latence je dána technickými parametry daného disku. Když zapojíš do RAID0 dva takové disky, tak jak dokážeš technicky nebo softwarově zajistit, aby latence klesla pod 41 mikrosekund?

[PetebLazar]

Asi jde o to, že teoreticky mohou mít dva následné požadavky celkovou latenci 41us, na jednom SSD 82us.

[LarryL]

Hodil jsem do googlu a hned první odkaz je na YT. Náhodné čtení i zápis je na single AORUS rychlejší než když je AORUS zapojen v RAID0. Pokud ale Jéčko bude znát způsob jak pomocí RAID zvýšit náhodné čtení, tak ať to sem hodí. Myslím, že mu místní komunita utrhne ruce. Kdo by nechtěl zdvojnásobit náhodné čtení, že jo? Jenom blázen by utrácel za Intel Optane když by na to existoval tak jednoduchý způsob, že stačí jen zapojit 2x NVMe do RAID0.

[Petr Tomášek]

Jenže to je "anekdotická evidence", která rozhondě nemusí platit ve všech případech.

[LarryL]

A terazky mi povedztě, Kefalín, čo vy si predstavujetě pod takým slovom "anekdotická evidence"?

[Petr Tomášek]

Prostě to, že ten člověk udělal test, který může záviset na mnoha možných i nemožných okolnostech a ty to zobecňuješ a děláš z toho „svatou pravdu“.

To je blbost, to video nedokazuje nic víc a nic míň, že v té konkrétní sestavě, na konkrétním CPU (AMD), s konkrétní implementací RAIDu (m$ widlous), s konkrétními NVMe disky s jistým typem řadiče není v náhodném čtení a zápisu rozdíl. SO WHAT?

To nic nevypovídá o jiné sestavě, s jiným CPU, s jinou implementací RAIDu a možná ani o jiném NVME s jiným typem řadiče.

Prostě to tvoje zobecnění je špatně...

[LarryL]

To nic nevypovídá o jiné sestavě, s jiným CPU, s jinou implementací RAIDu a možná ani o jiném NVME s jiným typem řadiče.

I když se rozkrájíš tam z náhodného čtení vymáčneš úplné minimum. K čemu to je? Při práci z desktopem to nemáš šanci poznat. Poznáš jen zvýšené sekvenční čtení a zápis, když se ti budou spouštět např. rychleji hry (jak jsem ti dole vložil ty dva odkazy).

[Petr Tomášek]

No, supr, takže když jsme tady ukázali, že „NVMe RAID0 nefunguje“ je z obecného hlediska blbost, tak přijdeš s tezí, že "při práci s dektopem to nemáš šanci poznat".

To je argumentace nahovno.

[LarryL]

Stejná odpověď jako na tvůj komentář níže: Odroluj si na moji první odpověď. Nikde jsem netrvdil že „NVMe RAID0 nefunguje“.

"při práci s dektopem to nemáš šanci poznat"

Ano, náhodné nemáš šanci na desktopu poznat. Tahle diskuze se týká desktopu. Sekvenční se zvýší. To říkám od začátku. Pokud by jsi se na začátku zeptal na detaily mezi náhodným a sekvenčním čtením/zápisem, tak jsme si to mohli v klidu vysvětlit.

[Petr Tomášek]

Měřil's to (šanci poznat)?

Neměřil!

Tak nevykládej hlouposti...

[LarryL]

V této diskuzi máš 2 odkazy na články kde to celkem podrobně měřili + odkaz na video. Klidně můžeš napsat vlastní článek, pak nám sem hoď odkaz.

[Petr Tomášek]

Dal jsem odkaz na měření, které ukazují opak, což jasně ukazuje, že co tvrdíš, neplatí za všech okolností. Prostě se s tím smiř, to jsou fakta.

[LarryL]

Ano dal. To byly obrázky z německého fóra s nárustem náhodného čtení 4KB QD4 ve výši cca 5%, na které se tě ptám níže.

[PetebLazar]

Ono nemusí jít o hodnotu jednotlivého přístupu, ale typicky mnoha přístupů. Pokud jsou tyto požadavky dohromady uspokojitelné v kratším celkovém čase paralelně ze dvou nezávislých zařízení logicky by výsledná souhrnná/průměrná latence (všech požadavků) měla být nižší, než když se všěchny přístupy uspokojovalí z jednoho device (v RAID1 to mohou být libovolná data, u RAID0 asi případný profit bude záležet na poměru dat čtených z memberů). Uvažuji v kontextu ideálního případu.

Oč byl svět jednodušší v časech, kdy bylo vizuálně zřetelné proč paralelismus může zkrátit latence.

[LarryL]

Pokud jsou tyto požadavky dohromady uspokojitelné v kratším celkovém čase paralelně ze dvou nezávislých zařízení logicky by výsledná souhrnná/průměrná latence (všech požadavků) měla být nižší, než když se všěchny přístupy uspokojovalí z jednoho device

No jo, ale kdo rozhodne zda "jsou tyto požadavky dohromady uspokojitelné v kratším celkovém čase paralelně"? Jak to udělat u náhodného čtení, když "ta věc", která by rozhodovala o tom zda jsou "požadavky dohromady uspokojitelné v kratším celkovém čase", nemá tušení který 4KB soubor se bude číst o setinku později? Má "ta věc" čekat na další požadavek na náhodný 4KB soubor, aby zkrátila dobu při paralelním čtení nebo čekat nemá, protože by doba čekání byla delší než okamžité načtení souboru? Mnoho otázek, které určitě databázoví specialisté řeší od rána do večera , ale u desktopu, který nechrlí požadavky na jeden 4KB soubor za druhým by taková režie pro náhodně čtené soubory byla jen prodloužením odezvy.

[GeorgeWH]

Pri citani 8KB suboru z jedneho disku by si mal latenciu 82μs. Pri citani toho isteho suboru z RAID0 (2x SSD) by si mal lateciu 41μs, pretoze bude citat paralelne z oboch diskov naraz.

[LarryL]

Ne. Při načítání 8KB souboru bude latence cca 41μs + přenesení_8KB_dat v single. V RAID0 bys 8KB soubor rozdělil na dva SSD, takže na každém disku by latence byla cca 41μs + přenesení_4KB_dat.

Už vidím jak se přiřítí Jéčko a vytkne mi, že jsem tam nepřičetl nějakou další režii FW SSD . Jenomže pak bychom tam museli přičíst i režii RAIDu. Ten výpočet jen jednoduše ukazuje, že náhodné čtení se nezmění na rozdíl od sekvenčního, které se zvýšuje, protože u RAID0 stačí přenést jen 4KB dat, ale u singlu se musí přenášet 8KB. Viz níže, kde je odkaz na benchtesty kde zkoumali co se v RAID0 změní při reálném použití. To považuji za důležitější než nějaké naše teorie o latencích.

[Petr Tomášek]

Jenže nikoho nezajímá latence přenesení jednoho bloku 8KB dat.

To, co tě zajímá, je nastřádaná latence, když to takhle uděláš 1000x nebo 100.000x. A když to paralelizuješ na dva disky, tak se ta latence v ideálním případě sníží skoro na polovinu.

Otázka je, jak dobře je to paralelizovatelné a jestli naopak tím paralelizováním tam nevneseš další latenci.

Ale z obecného hlediska nelze naprosto říci, že se latence nesníží...

[PetebLazar]

Myslím, že je to obecným principem. Zmiňuje ho jako první i Performance Tuning Guide Oracle RDBMS.

8.2.4.1 Stripe Everything Across Every Disk

The simplest approach to I/O configuration is to build one giant volume, striped across all available disks. To account for recoverability, the volume is mirrored (RAID 1). The striping unit for each disk should be larger than the maximum I/O size for the frequent I/O operations. This provides adequate performance for most cases.

Pro zajištění dostatečné paralelizace na straně RDBMS běží více procesů pro obsluhu IO, osazuje více řadičů atd.

Tady jsou dva příklady dříve zmíněného TPC-C benchmarku

z roku 2008 s 6760 HDD a výkonem 4 000 000 tpm.

z roku 2010 kdy k více než dvojnásobnému výkonu již stačilo jen 200 SSD a 200+ SAS/SATA HDD.

[LarryL]

Otázka je, jak dobře je to paralelizovatelné a jestli naopak tím paralelizováním tam nevneseš další latenci.

Přesně tak. U databází můžeš získaz u desktopu ne - o pár komentářů výše

[PetebLazar]

Kdyby Microsoft dodělal WinFS nemuseli jsme se tu teď přetahovat.

[Petr Tomášek]

U databází můžeš získaz u desktopu ne

Blbost

[Petr Tomášek]

U databází můžeš získaz u desktopu ne

Jinak, z mého hlediska jsou databáze např. jako sqlite jakožto součást firefoxu to, co do velké míry způsobuje „pomalost desktopu“. Takže to, co říkáš, považuji za dvojnásob nesmyslné...

[LarryL]

Viz níže se ptám na Firefox.

Trolíš nebo jsi vážně nepochopil, že se bavím o vytížených databázích na serverech a né o nějakém sqlite na desktopu? Na db serverech už se samozřejmě nebudeme dívát na QD1, ale třeba na QD64 nebo QD128.

[PetebLazar]

Zrychlení čtení platí snad u některých implementaci RAID1 HDD (je jedno kde se požadavek na čtení vyřídí, oba členi mají stejny obsah). Asi to teoreticky bude platit i pro RAID1 SSD.

U RAID0 si nejsem jist zda lze vůbec z pohledu FS docílit operace nezahrnujici oba cleny (možná pokud je alokační blok mensi/roven stripe).

[Petr Tomášek]

No, tak ono taky bude záležet na tom, JAK je to paralelizováno a jestli například máš zároveň několik souběžných požadavků na RAID0 zařízení.

Prostě tím chci říct, že je to složitější a že to závisí na mnoha faktorech. Je jasné, že 2x větší propustnost u náhodného čtení dosáhnout možné není, ale někde mezi 1x a 2x to bude a to, jestli to bude spíš 1x nebo spíš 2x záleží na mnoha věcech.

Rozhodně tvrzení, že RAID0 nic nepřinese je z obecného hlediska nepravda.

[LarryL]

Rozhodně tvrzení, že RAID0 nic nepřinese je z obecného hlediska nepravda.

Dal jsem odkaz na video, které ukazuje, že u náhodného čtení RAID0 u NVMe nic nepřinese. Právě naopak. Teď jsi na tahu ty nebo Jéčko, abyste sem hodili odkaz, který dokazuje vaše tvrzení.

[Bohumil]

Tady je odkaz na video, které ukazuje, že náhodné čtení z RAID0 NVMe je rychlejší. Hint: 10:12.

[LarryL]

Pravdu máš. Čtení (které nás zajímá nejvíc) stouplo z 61 na 62 MB/s

U náhodného zápisu je ten rozdíl taky minimální - z 232 na 240 MB/s.

Jenom abychom si rozumněli. Netvrdím, že třeba u databázového serveru kdyby se to šikovně poskládalo k tomu se přidala optimalizace, aby se příkazy řadily za sebe, že by se z toho nedokázal vymáčknout nějaký ten MB/s navíc. Tazatel podle dotazu má obyčejný desktop a tam náhodné čtení zůstane po zapojení do RAID0 +- stejné, tak to je.

[PetebLazar]

Pokud bychom se bavili v intencíh HDD tak tam pouhé rozložení dat na více device může znamenat, že si v souhrnu HDD v RAID0 do své cache načtou dvojnásobek dat (track) na první otáčku, pokud následný požadavek je v rámci těchto dat může být z cache HDD uspokojen rychleji. V případě dat z jediného device se bude pro stejná data nutno posunout o stopu a čekat aspoň jednu otáčku.

[LarryL]

Souhlas. Kdysi jsem poslouchal přednášku z Kiwi.com, jak museli pořád navyšovat a navyšovat výkon databází. Museli přecházet na jiné databáze, myslím, že tam říkali, že tam kde potřebovali bleskový výkon používali Intel Optane, ale zase pro jiné části DB kupovali levnější. Je to alchymie.

[PetebLazar]

Stačilo se v minulosti podívat na listy specifikací k TPC-C (OLTP) benchmarkům, kde bylo trvalého výkonu v řádu 2 000 000+ tpm (Trasactions Per Minute) dosahováno za osazení tisíců HDD (s desítkami FC ve stovkách polí). Při benchmarku transakční zátěž produkovaly desítky serverů jako klienti. Celkový objem DB nad kterou byl benchmark definován byl snad 10TB, pro něž bylo z každého HDD asi využito jen pár GB (masivní partitioning). Při typických latencích v řádu desítky ms to nakonec asi nejde jinak. Výsledkem reportu byla i cost/tpm z cenové výčetky veškerého HW/SW(serveru) a dosaženého výkonu. Cena/tpm vycházela v řádu jednotek US$/tpm (při výkonu v milionech tpm cena dosahovaly řádu vyšších milionů US$ za řešení). Většina nákladů řešení šla typicky za licencemi.

[Petr Tomášek]

hele

[Petr Tomášek]

a hned vedle

[LarryL]

No nevím, takové obrázky v diskuzi. Lepší je toto:

https://www.eteknix.com/year-nvme-raid-0-real-world-setup/6/ . V programu AS SSD Benchmark náhodné čtení v RAID0 kleslo a v CrystalDiskMark stouplo, tak si vyber Výsledek recenze je takový:

Pros

Better Sequential Performance Two drive’s capacity as one volume Coolness factor and bragging rights

Cons

Slower access times

Neutral

Random read IOPS down but writes up.

Další https://www.pctechreviews.com.au/2019/07/14/amd-nvme-raid-explained-and-tested/3/ To co bude zajímat nejvíce je dole v "Real World Use":

- při renderování žádný rozdíl v časech

- při extrahování archivu taky žádný rozdíl

- až u gamingu se ukázalo, že hry se při RAID0 spouští rychleji. Což dává smysl, protože se načítají objemnější soubory, takže se tam ukazuje výhoda sekvenčního čtení.

[Petr Tomášek]

Je to důkaz, že obecná poučka „NVMe RAID0 nic nepřináší“ je nepravdivá.

Správná odpověď je: „záleží na mnoha faktorech a když potřebuju vědět, jestli mi to k něčmu je, musím to na konkrétní sestavě s konkrétním OS/softwarem a s konkrétní zátěží změřit.“

A to je, o čem tu celou dobu mluvím, tak prosím přestaň srát očividné nesmysly a nepravdy...

[OldFrog {Ondra Nemecek}]

Odroluj si na moji první odpověď. Nikde jsem netvrdil, že „NVMe RAID0 nic nepřináší“. Celou dobu říkám, že sekvenční se zvýší, ale náhodné ne. To tvrdím stále. Při práci s malými soubory nic při zapojení do RAID0 nezíkáš. Honit tady triko, kdy si budeme přeposílat grafy jestli v nějakém grafu stouplo nebo kleslo náhodné čtení o 1% nebo 3% je k ničemu. Pořád je to něco co v reálném životě nemáš šanci poznat. U optimalizace datábází a jiných libůstek je to zase něco jiného, tam vstupuje do hry více faktorů. V této diskuzi tazatel neoptimalizuje databáze, ale ptá se co to udělá když do MB na desktopu strčí 2x NVMe do RAID0.

[OldFrog {Ondra Nemecek}]

Přesně tak, RAID0 v striping režimu (prokládání) zlepší propustnost (sekvenční čtení), nikoli rychlost odezvy (náhodné čtení), zdroj: https://cs.wikipedia.org/wiki/RAID#RAID_0

[LarryL]

Díky, že ses mne zastal, už jsem se bál, že v tom zůstanu sám

[Petr Tomášek]

Že něco stojí napsáno na Wikipedii ještě neznamená, že to není hovadina...

[Petr Tomášek]

To tvrdím stále.

A je to stále nepravda. Podívej se na ty výstupy z Crystaldisk / AS Benchmark, které dokazují, že nemáš pravdu, tj. že existují případy, kdy to neplatí.

[LarryL]

Takže chceš, abych svoji větu z prvního příspěvku, která zní: "Zrychlíš jen sekvenční čtení a zápis. Náhodné tím nenavýšíš." změnil na větu: "Zrychlíš jen sekvenční čtení a zápis. Náhodné tím podle některých bechtestů nepatrně stoupne a jindy nepatrně klesne."? Budeš pak exaktně spokojen s takovou definicí?

[Petr Tomášek]

Naprosto ne.

Korektně by ta věta zněla např. takto: „V testech, které jsem viděl, RAID0 náhodné čtení nenavýšil.“

Ale tvoje generalizace jsou holý nesmysl, už proto, že jsem tady odkázal na testy, co přínost pro náhodné čtení ukázaly. (Mimochdem, měl by sis to fórum přečíst celé, jeden z těch testů je od člověka, který tvrdil stejné nesmysly jako ty a pak si to změřil a napsal: „OK, beru zpět, nějaký přínos RAID0 NVME pro náhodné čtení mít může...“)

[LarryL]

Korektně by ta věta zněla např. takto: „V testech, které jsem viděl, RAID0 náhodné čtení nenavýšil.“

Ty nevidíš, že v komentáři na který reaguješ je napsáno "Náhodné tím podle některých bechtestů nepatrně stoupne..."???

Vážně by mě zajímalo, čeho takovou přiblbou diskuzí chceš dosáhnout. Snad každému je z těch grafů i článků i videa jasné, že i nepatrný nárůst v grafech u čtení 4KB souborů QD1 (což nás u destopu zajímá) nemůže mít na reálný život žádný vliv.

U tvého grafu (z německého fóra) z ATTO_Disk je u 4KB QD4 zvýšené čtení z 534 MB/s na 563 MB/s. To je 5%. Ve videu je u 4K Q1T1 nárůst z 61 MB/s na 62 MB/s (a to jen u RAID0 - CPU) což je zaokrouhleně 2%. A z toho očekáváš, že budeš o 5% rychleji bootovat nebo že ti o 5% bude rychleji fungovat Firefox jak jsi psal výše?

[Petr Tomášek]

Koho by zajimalo jedine vlakno?

[LarryL]

Nevím kolik vláken má tvůj graf. To musíš vědět ty když jsi ho sem postnul. Jen vím jakou má hloubku fronty. Ať má vláken kolik chce, tak je tam 5% rozdíl oproti RAID0. Prozradíš nám konečně nějaký Use Case u kterého tazatel na desktopu pozná 5% nárůst náhodného čtení 4K souborů?

[Petr Tomášek]

při extrahování archivu taky žádný rozdíl

Při extrahování archivu čteš sekvenčně a zapisuješ sekvenčně. Renderování na tom bude podobně.

Daleko lepší test by byl např. na rychlost bootu.

[LarryL]

Daleko lepší test by byl např. na rychlost bootu.

Pokud myslíš, že by to bylo daleko lepší, tak to změř a napiš článek/blog.

[Petr Tomášek]

Počkej, ty tady tvrdíš snadno vyvrátitelnou blbost, proč bych měl já něco měřit?

[LarryL]

Blbost tvrdíš ty, protože já jsem doložil články a video, kde to měřili a jejichž závěrem je, že RAID0 nemá pro reálný nárust náhodného čtení na desktopu žádný význám. Ty zde operuješ s teoretickou myšlenkou, že možná na nějaké konfiguraci s nějakým jiným NVMe, s jiným FW by nárůst náhodného čtení mohl být, že by to možná mělo vliv na rychlejší bootování. Zanech teoretizování a ukaž nám ty naměřené výsledky.

[Petr Tomášek]

U RAID0 si nejsem jist zda lze vůbec z pohledu FS docílit operace nezahrnujici oba cleny (možná pokud je alokační blok mensi/roven stripe).

Ale to vůbec není nutné, aby to mělo nějaký efekt... Stačí, aby oba přístupy proběhly paralelně...

[PetebLazar]

Měl jsem na mysli případ, kdy při 64KB stripe RAID0 bude velikost alokačního bloku FS 128kB (minimální velikost IO operace), proti single storage s alokačním blokem 64KB. Pokud nás bude zajímat náhodně pouze 64kB dat zatím nenacachovaných dat, oba případy budou v nejlepším případě stejně výkonné (i když čtení z obou členů RAID0 proběhne paralelně, přínosem bude pouze načtení nepotřebných dat navíc).

Pokud by v případu RAID0 byl alokační blok 64KB, díky tím získané nezávislosti to bude moci poskytnout vyšší výkon (paralelní obsluhou nezávislých požadavků).

[Petr Tomášek]

Když odhlédnu od toho, že „načtení nepotřebných dat navíc“ se nazývá readahead, protože v reálu není přístup na disk nikdy jenom zcela náhodný, pak ano, na velikosti stripe vzhledem k velikosti alokačního bloku FS záleží (a rovněž i vzhledem k velikosti alokačního bloku NVMe). Stejně tak jako vůbez záleží na tom, jak dobře je napsaný ovladač raidu v jádře.

To ale nic nevypovídá o tom, jestli z obecného hlediska může být RAID0 z NVMe disků přínosný pro náhodné čtení.

[Peter Golis]

Pri NVMe je skôr iný problém, zbytočne žerie CPU na rozdiel od starších technológií typu SATA alebo SAS. Takže na desktope má obvykle strop v rýchlosti CPU alebo v rýchlosti zbernice. Odchýlky typu QLC Flash môžeme zatiaľ zanedbať, aj keď tento typ spomalenia sa už začal prejavovať u niektorých spomenutých modelov.

PS: Diskové polia s NVMe používajú ASIC na integrovaných radičoch aby prestrelili tento typ úzkeho hrdla.

[PetebLazar]

Proč nevyužívají NVMe DMA? Jako PCIe zařízení by toho snad měly být schopny. https://www.phoronix.com/scan.php?page=news_item&px=Linux-RFC-P2PDMA-NVMe-Drives

[Peter Golis]

Diskové polia s NVMe diskami boli na trhu už pred viacerými rokmi, a už vtedy potrebovali nejako zabezpečiť trojitú paritu ako ochranu pred znehodnotením dát chybou HW. A to bez dodatočných výpočtov nedáš.

Ale to je mimo záber Stripe, kde P2PDMA by malo byť v Linuxovom jadre od nejakej verzie 5.10. Ubuntu to má vypnuté aj v prerelease 21.10, RHEL-8 klony (alma a Rocky) to majú vypnuté tiež (aj keď majú staršie jadro), a ani Debian 11 to nezapínal.

Takže ak to urýchlenie NON RAID Stripe na NVMe chceš na desktope skúsiť, tak si asi musíš zapnúť podporu v jadre a preložiť ho zo zdrojákov. Ja mám len jeden NVMe slot, a robiť na ňom test rýchlosti Stripe s 2T Notebookovým SATA diskom (šindelovým) nebudem.

$ ssh debian-11 'grep -i -e p2pdma /boot/config*'
# CONFIG_PCI_P2PDMA is not set

[Jardík]

Na x570 chipsety pozor, některé desky, hlavně starší, mají problémy s USB s některými HW konfiguracemi, které NEŘEŠÍ ani aktualní AGESA. Já tu mám ASUS ROG Strix X570-F Gaming, měl jsem NV GF 2080 super od MSI a trpěl jsem náhodnými několika milisekundovými záseky kurzoru myši v nepravidelných intervalech, jakoby myš přestala posílat chvíli data a pak se zase vzpamatovala. Nepomáhaly ani rady typu vypnout C state, apod. Problémy se projevovali pod Linuxem i Windows. Občas se náhodně odpojovaly i USB flashky. Nedávno jsem grafiku vyměnil za radeon 6900xt a všechny problémy s USB jsou pryč. Zřejmě nějaká interakce mezi PCI-E grafikou a deskou způsobovala problémy s USB, nechápu. V jiném PC původní grafika funguje bezproblémově. Prostě záhada nad všechno. Problémy s USB na těch chipsetech má sposta lidí. Některým pomohl update agesy, která to měla řešit, ale mě to nepomohlo.

[PetebLazar]

Neměl by tyto problémy řešit nový chipset X570S (kromě pasivního chlazení). Jedna z prvních MB s ním Asrock Riptide PG na sebe dává docela čekat.

[Jardík]

Vůbec netuším, když jsem něco s těmito chipsety hledal, tak u nás v ČR nic s tímto chipsetem nebylo.

[Petr Tomášek]

X570S není žádný nový chipset.