PG Turnaj 2020 - testy a nastavení

[RoKro]

Souhlasím.
Hlavně si ale nastavení ověřte výpočtem pár kousků dlouhých LLR tasků, třeba turnajových Woodal.
Moje RAMky s XMP profilem 3600 CL16 šlapaly při 1,5 V i na 4000 CL17, ale u dlouhých Woodal tasků se občas objevilo varování a jednou za čas byla některá jednotka označena jako chybná. Je škoda přijít o hodiny počítání.
Tak jsem se vrátil na 3600 MHz, ale s časováním CL14 (taky při 1,5 V). A to počítá stejně rychle, ale bez chyb.

[Honza]

Jo, a prý taky je GCW nejnáročnější na velikost RAM.
Pokud se v ní honí hodně dat, takže bude stabilita pamětí důležitá. Možná i více důležitá než stabilita CPU, která se pro změnu projeví u PPS nebo třeba 321 - pozná se podle spotřeby a teplot.

[RoKro]

V turnaji ovšem, pokud to dobře chápu, není podprojekt GCW, ale dvojice projektů CUL a WOO.

[Honza]

Ano.

[forest]

Koukal jsem se na poslední soutěžení na obou podprojektech před dvěmi lety a diskusi o nejvhodnějším nastavení. Brutální vliv měly na výsledky paměti, hlavně jejich takt. Pokusím se na to při testování nyní koukat, ale už tenkrát to bylo hodně náročné na čas. S výjimkou šedesátivláknových strojů, jsme nikde nepouštěli vce než 2 jednotky naráz, se zapnutým HT a bylo potřeba nechat nějaké to jadérko volné. Uvidíme, co bude nejvýhodnější nyní, po celých dvou letech.

Ladění se zde extra vyplatí, jelikož za každou odevzdanou jednotku je ranec bodů.

Výsledky jsou stejné, jako přede dvěmi lety. Tedy u CPU do dvacítky jader s HT, nemá smysl pouštět více než jednu jednotku. U 32 vláknových TR, jsou ideální dvě jednotky a na 64 vláknových strojích je optimální pustit čtyři. Vždy bylo lepší, nechat alespoň jedno vlákno pro každou z jednotek volné.

[® Plšák Ráďa ®]

Vyšla nová aktualizace vindejsů 10 verze 20H2, buď pozastavte během turnaje veškeré aktualizace oddálením termínu, nebo aktualizujte. Nebylo by to napoprvé ani naposledy, co neplánovaná aktualizace překvapila kdejakého počtáře

Jen dodám jednu zkušenost s těmito obludami CUL/WOO a podobnými, když už jste se někteří zmínili ohledně stabilitě pamětí. Já mám takovou zkušenost s G.Skill Flare 3.2 GHz cl14 , že když jsem měl dva paměťové moduly, tak vše se nastavilo jak mělo a vše počítalo v pohodě. Mno pak jsem si řekl, že rozšířit paměť o další 2 kousky by nebylo špatné na počítání Atlasu (dnes podprojekt LHC) a jiných náročných projektů na RAM jak ECM2, Amicable. Mno tak jsem ještě zkontroloval zda deska podporuje 4 sloty zaplněné, ve slejdech nebylo nic, že by ne. Ale puntík u 4 banků tam prostě chyběl. Tak jsem to riskl a koupil je. Zapojení bylo v pořádku chytly se a frčel jsem na 32 GB. Časem jsem zjistil v CPU-Z, že časování tRC není na hodnotě 48, ale je nastaveno na 68. Tož zjistil jsem, že s hodnotou manipuluje přímo BIOS na AUTO. Tak jsem mu tam natvrdo nastavil 48 a výpočty byly opět rychlejší. Samozřejmě vytroubil jsem do světa v nějaké místnosti ve fóru, že jsem si všiml nesrovnalostí s paměti, které můžou zpomalovat výpočty. Tak a teď se dostáváme k jádru pudla. Pak přišel PG a jednotlivé podprojekty. Krátké jednotky počítalo v pohodě, nezaznamenal jsem nějaké problémy. Pak mám dojem byl podprojekt SoB, ... a už to začalo generovat nevalidní jednotky. Nějak jsem nemohl přijít proč, kde je chyba. A nejspíš jsem nebyl sám, ten problém s nevalidací jednotek řešil ještě jiný člen CNT a tam se nějak diskutovalo o snížení frekvencí, že to pomáhá. Tak jsem ty paměti z 3,2GHz dal na 3 GHz a ono to začalo validovat práci. Ale zapomněl jsem na tu položku tRC, kterou jsem změnil a pak jsem se k tomu nedostal k dalším testům se stabilitou pamětí při výpočtů těchto oblud. Po aktualizace BIOSu jsem prostě položku tRC už nějak neřešil a nechávám na AUTO a paměti od té doby jedou na těch 68 tRC. Ale od té doby, co jsem paměť podtaktoval na 3GHz, už nechávám hodnotu frekvence při každé aktualizace BIOSu na hodnotě 3 GHz nějak pro jistotu . Jelikož pojedu Woodall LLR, abych si dokončil gold frčku nějak nebudu riskovat výpočty při rychlosti 3,2GHz a radši pojedu na stabilitu. Takže kdoví, jak vám ty paměti jedou na určitých hodnotách, zda nejsou už od výrobce nastavený v jakémsi přetaktu a pro stabilitu ještě kromě snížení frekvence pamětí mírně zvětšit tRC hodnotu přímo v BIOSu, pokud by nepomáhalo snížení frekvence.

[RoKro]

Ano, to byla moje zkušenost. Se čtyřmi RAMkami G.Skill to jelo znatelně rychleji, než jen se dvěma, ale tu druhou dvojici jsem dokupoval dodatečně a při továrních 3200 CL14 to pak dělalo u dlouhých jednotek občas nevalidní výsledky. 3000 CL14 bez chyb.
Ovšem dohromady koupená sada 4 kusů G.Skill 3600 CL16 mi dává trvale validní výsledky i při časování CL14.

[Honza1616]

Ano, to byla moje zkušenost. Se čtyřmi RAMkami G.Skill to jelo znatelně rychleji, než jen se dvěma, ale tu druhou dvojici jsem dokupoval dodatečně a při továrních 3200 CL14 to pak dělalo u dlouhých jednotek občas nevalidní výsledky. 3000 CL14 bez chyb.
Ovšem dohromady koupená sada 4 kusů G.Skill 3600 CL16 mi dává trvale validní výsledky i při časování CL14.

po 101 to zde dám
https://pctuning.tyden.cz/hardware/proc ... pc?start=6 ...doporučuji ale přečíst celé
a dodám jen že i když jsou paměti stejné na první pohled, tak nemusí být stejné pod chladičem
nikdy bych do PC nedal paměti různých frekvencí, časování, SS/DS, kapacit GB, nedej bože různých výrobců modulu nebo snad i různých paměťových čipů,
proto když upgreaduji RAM třeba z 16 na 32, nikdy nedokupuji dalších 16
ale těch 16 co mám radši prodám a koupím bulk 32GB nebo naklikám v eshopu několik modulu ze stejné série
problémy se mohou objevit větší nebo menší, někdy můžete fungovat aniž by jste zaznamenali problém, jindy PC ani nenabootuje

POINTA, to že si v obchodu po roce fungování vyberete totožné moduly neznamená že opravdu totožné jsou
pak se nediv že ti to hází chyby

[RoKro]

Ale já se ničemu nedivil, já to prostě risknul a nevyšlo to.

BTW je dobrým zvykem na fórech, že když reaguješ na poslední příspěvek, tak ho necituješ. Důvody jsou snad jasné.

[Albert]

Ad tRC. Součet tRP + tRAS musí být menší, nebo maximálně roven tRC. Když je roven, dostáváme se na hranici a ta je tenká. Stačí, když se paměti více zahřejí a už může být problém.

Co se rychlosti přístupu do pamětí, čtení, zápisu a celkového výkonu procesoru týká, tak je to bohužel složitější s nástupem nových cpu od AMD. Ty se uvnitř skládají z CCX a ty mezi sebou a okolím komunikují prostřednictvím sběrnice Infinity Fabric (IF). Ač je to k nevíře, tak frekvence IF je svázána s frekvencí pamětí. Takže jakou frekvenci pamětí nastavíte, tak na ní "pojede" i IF. Jenže od cca 4000MHz nahoru (nevím přesně, ani nevím, jestli to AMD již zveřejnilo) by IF už nestíhala, tak se ta frekvence dělí směrem dolů ... Jak přesně nevím.
Takže celkový výkon výpočtů je na rychlosti pamětí u AMD závislý více, než by se čekalo.

[Honza]

Tak...zase u stroje.

Jednotky trvají v průměru asi 87 hodin pro CUL a 125 hodin pro WOO.

Z tohoto pohledu je myslím lepší jet CUL, je menší šance ji nedokončit. Oba projekty mají +20% za délku jednotky.
To je z pohledu kreditů či turnaje.

Otázkou však je, jak jsou tyto časy vypovídající. Myslím tím i z pohledu na přechod na LLR2.
Navíc Cul a Woo nejsou zrovna populární projekty (třeba narozdíl od SoB, i když má monstrožní jednotky), takže při nasazení výkonných strojů s AVX-512 může průměrný čas klesnout.
No vyzkoušet, FFT 2016k.
EDIT: Kombajn mi stáhl první CUL a po 10 minutách odhaduje čas kolem 9 hodin na jednu (jedu 4x7)

Z pohledu prvočísel, kdyby si někdo troufal...
CUL má na PG pouze dva záseky velikost cca 2M (na dnešek relativně malá) a to z let 2009. Od té doby sucho.
Woo má 3 malé z roku 2007 a pak jedno velké 5M a roku 2018.
Jinde než na PG se jiné CUL nebo WOO nenašlo.
U takto malého výskytu těžko odhadovat, kdy a kde padne další.

Asi půjdu do CUL.
A už teď, do 321LLR "dirty diaper" mi zbývá 9M, takže až po turnaji.
Navíc nevím, jestli budu večer o stroje, abych připadně přenastavoval nebo (fuj) rušil rozpočítané jednotky, aby se mi natáhly turnajové.

Mimochodem, Pavel našel po dlouhém suchu nové TRP.

[RoKro]

Tipuji, že ty rozdíly v dobách výpočtu budou menší, soudím tak z číselné délky testovaných jednotek, Cullen 5 667 405, Woodal 5 819 719. Jsou hodně podobné, to by nemělo udělat 40% rozdíl v časech.

[Honza]

Turnaj jede, první výsledky jsou zpět - pochopitelně krátké DC tasky.

Jo, rozdíly také očekávám meší a pokud věřím, že cloudové instance na Xeon Gold (i když jen 3 thready) mohou stáhnout průměrné časy.

[forest]

Vše všude šlape jak má. Všechny týmové a moje stroje jedou na plný výkon pro PG. I na Oldjerryho novém CPU to chroupá tyto obr jednotky pro turnaj bez problémů. Jsem zvědav na stav tak po třech dnech turnaje. To už se vše srovná a vyprůměruje, dle aktuálního výkonu jednotlivých týmů.

[fobius]

Minulé turnaje jsem měl výkon ryzen 2700x vs xeon v3 podobný (podobný počet jednotek za turnaj).
Aktuálně ale ryzen počítá jednotku za 12 hodin cca a xeon tak za 6 při podobné počtu vláken.
Jaké máte časy vy?

[porab]

Woodall: 3950x 2x8 cca 9,15h a 3700x 1x8 cca 6,30h. Vše bez SMT(HT).

[eLPeCKo]

To same s TRX vs Intel....tyto dlouhe ukoly tomu vubec nesedi

[Honza1616]

i9-9900k, RAM 2400MHz ....8:30
i9-9900k, RAM 3500MHz ....6:40
Ryzen 9 3900X RAM 2400MHz......15:05 (počítám souběžně 2 úkoly, každý na 12vlákench)

nějak jsem to nezkoumal ale očividně to i zde ovlivňuje dvoučipletový design, Ryzen 3900 má dva 8 jádrové čiplety a na každém jsou 2 deaktivovaná jádra, tedy 6 funkčních jader na každém = 12 vláken na každém
vyšší počet vláken na wu by sice poskytl větší výkon, ale za cenu nižší efektivity, další výkon nestoupá rovnoměrně s počtem jader nejspíš kvůli pomalé komunikaci mezi čiplety
a menší počet vláken zase pochopitelně nedá takový výkon

je to podobné jako na jiných podprojektech kde zase pro změnu je výhodnější počítat 4 Wu na 3 jádrech
a na jiných zase počítat 6wu po 2 jádrech,
a na dalších počítat jen 1wu = 1 jádro,
....v závislosti na velikosti FFT
zvláštní, tolik možných kombinací co mi 24 vláknový CPU nabízí, ale vždy mi nabídne jako nejefektivnější jednu ze 4 zmíněných kombinací
z toho plyne že se Windows už asi naučil používat multičipletový design a přiřazuje práci vždy sousedním jádrům a celkově bere ohled na design Ryzenů/Threadripperů aby nepřehazoval práci na přeskáčku mezi čiplety, jupíí

ted jsem zvědav jak na tom bude Intel architektura big.LITTLE v Alder Lake, které mají přijít nejpozději (spíš dříve) za rok (10nm + DDR5)

[RoKro]

Jojo, paměti mají tentokrát obrovský vliv. Asi čím větší FFT, tím mohutnější komunikace s RAMkami.
Mám dvě čtyřjádrové i3-9100F, na tom s RAMkami 3200 MHz CL16 trvá výpočet lehce přes 12 hodin a na tom s RAMkami 2400 MHz CL17 lehce přes 14 hodin.

Cullen vs Woodall
Na i7-8700k se mi Cullen jednotky počítají v průměru za 7,8 hodiny a Woodall za 8,8.
Ty Cullen byly všechny FFT 2016k a za cca 20 tisíc bodů, ty Woodall byly některé FFT 2016k za 20 tisíc bodů a jiné byly FFT 2M (předpokládám, že 2048k, takže větší) a za 22 tisíc bodů.

Vzhledem k trochu rozdílné době výpočtů se před koncem turnaje (jak dlouho před koncem záleží na rychlosti vašich výpočtů) může hodit upřednostnit na konkrétním stroji jeden typ, resp. jednu velikost jednotek. Pokud by se třeba Woodal FFT 2M jednotka už asi o kousek nestihla, mohla by se stihnout dopočítat nějaká s FFT 2016k, ať už Cullen nebo Woodal. A naopak kdyby se nestihly dvě krátké, tak aspoň pustit jednu dlouhou, než jednu krátkou. Ale kdo by se s tím chtěl mazat

[Honza1616]

...Ale kdo by se s tím chtěl mazat

tak ono to není zase tolik práce se podívat jak dlouho ti výpočet trvá a spočítat si 1 den-2 dny před koncem jak by jsi skončil, a podle toho navolit kombinaci úkolů tak aby jsi odevzdal ještě jednu várku

úplně nejjednodušší pak je pár hodin před koncem pustit všechny jadra na 1 úkol,
což platí pro ty s monstr CPU typu 16 a víc jader, kde se počítají jen 2wu po 8 jádrech nebo 4wu po 8 jádrech, nechat tam běžet jen 1 úkol na celém CPU na všech jádrech
a dopočítat tak aspon 1 celý úkol by mohlo trvat odhadem třeba jen 2-3 hodiny
to myslím že těch 5 vteřin co otevřeš config, přepíše ho, uložíš, restartuješ Boinc, myslím za tu práci stojí

vzhledem k tomu že končit budeme v sobotu v podvečer, tak já si k tomu sednu už ve čtvrtek, spočítám si průměrný čas úkolů za posledních 2 dny, který najdu v job_log_www.primegrid.com dopočítám kolik úkolů se mi vejde v rozmezí Čt odpoledne -> So večer, a natáhnu odpovídající počet a směs úkolů

zatím to vypadá na jisté 3. místo
https://statsgr.id/top_team_graph.php?c ... _id=2020_8
na celkové první místo je to dost těsné, na GFN nám pomůže že si tučňáci nebudou moct pronajmout HW snad tou dobou bude ještě nedostatek nových grafik, to by nám jinak mohlo překazit plány