Těžíte XCH (Chia) ?

[Mirek Prýmek]

ZFS a BTRFS jsou super, ale ten plotting zpomalují. Spíš xfs (mkfs.xfs -m crc=0) nebo ext4 (mke2fs -T largefile4 -m 0)

Jo, to byl jenom pokus nad existujícím filesystémem, protože to je novej stroj, kterej jsem beztak potřeboval otestovat.

[Reklama]

[RDa]

Pro me je zahada, proc se zasekava plotovani - proces zere 100% cpu, ale nema zadny progress, takze htop ukazuje hodiny behu ktere nejsou obvykle pro ostatni ploty na stejnem cpu a disku. A neni to ojedinely pripad - stava se to dost casto (bezi me paralelne cca 48 plotu na ruznych PC a 8 jich bylo po dvou dnech takto zaseklych - na ruznych PC, jsem to nehlidal a nasbiralo se to). Zda jsou tam ECC pameti nebo nikoliv na to nema vliv - bude to softem.

[k3dAR]

Pro me je zahada, proc se zasekava plotovani - proces zere 100% cpu, ale nema zadny progress [...]

to se mi stalo (behem par dni pokusu) 2x, ale chyba byla na moji strane ;-) i kdyz to asi nebude tvuj pripad, tak pro ostatni:
1. kdyz dojde misto v home, nema to kam ukladat logy o progresu a dojede to do 100% a zastavi se, nezkopiruje hotovej plot do final uloziste, staci prejmenovat z *.plot.tmp na *.plot a zkopirovat rucne (a samozrejme uvolnit misto)
2. kdyz do finalniho uloziste nemuze zapisovat user, v logu je videt ze se snazi o zapis opakovane, staci napravit opravneni a bud to pak zkopiruje pri dalsim try, nebo killnout procesy co plotovaly a rucne

[PanVP]

Mně se to zastavuje na 31% na řádově dlouhé desítky minut a pak na 100%, než se povede data dostat pryč.
Jinde to má cca pravidelný progres....

[manasovo]

Brí den, kdyby někoho zajímalo farmení v poolu (hned co bude vydaná referenční podpora v kódu), tak připravujeme backend viz https://czech.farm. Díky a farmení 3x ZDAR !

[Reklama]

[Mirek Prýmek]

Brí den, kdyby někoho zajímalo farmení v poolu (hned co bude vydaná referenční podpora v kódu), tak připravujeme backend viz https://czech.farm. Díky a farmení 3x ZDAR !

Super! Držím palce a možná se přidám.

Jenom taková dobře míněná rada: zkuste najít nějakého copy writera, nebo alespoň někoho se slušným citem pro jazyk a sloh. Viz např:

"své políčka", "Krypto měny", "krypto[ ]měny nezdáli", "zejména vzhledem k formě tzv.", "Změna formy ... je významně energeticky úspornější" (ne, změna formy není úsporná, maximálně může třeba "vést k úspoře" ),  "libovolně jiná data", "vzhledem k osobě Brama Cohena, tedy člověkem", "top je fakt", "nemusí být dostupné disky všech", "teď si přijdou k lizu" (ehm, krávy jsme spolu nepásli, ne? )

Neber to prosím jako otravné šťourání. Když máte v jedenácti řádcích textu asi osm gramatických chyb a asi deset stylistických, zbytečně to kazí dojem z projektu, který jinak může být super (a já tomu chci věřít a držím vám palce).

A poslední poznámka: víc než vaše "toliko k historii BTC" by asi návštěvníka stránek zajímalo, jaký máte k dispozici hw, jaké budou poplatky a jaké máte s provozováním těžebního poolu zkušenosti (tj. proč bych měl těžit zrovna u vás a ne jinde).

[Karlosek]

Proč ne? Jsem taky zvědavý. Nevíte, jak je to s existujícími ploty a přechodem pod pool?

[nocturne.op.15]

Pokud jsou moje informace správné, bude se replotovat, přenést nepůjdou. Předpokládám, že v tomhle směru se nic nezměnilo...

[Martin Mlynář]

Bude se určitě muset replotovat: https://github.com/Chia-Network/chia-blockchain/wiki/Pooling-FAQ#will-i-need-to-replot-to-use-the-official-pooling-protocol

[Chia-farma]

Zdravím,

protože jsem kdysi v počátcích tak dlouho váhal s těžbou Bitcoinu, až přestala pro jednotlivce dávat smysl, pustil jsem se nyní jako spousta jiných do Chia.  Mám ale problém s plotováním. Mám 12 jádro Xenon (24 vláken ), desky x 99, 8x4 GB
 ( 32 ) ECC DDR3 RAM Hynnyx, syst. Sata SSD 500 GB Patriot, 1 TB NVMe  zápis 3000MB, několik RAID0 polí z běžných disků v řadiči Marwell v PCIE. Disky pro farming jsou připojeny přímo k desce přes SATA3. Můj problém je ten, že když spustím plotting 3x paralelně, s rozestupem cca 1 hodiny, každý proces na 4 vláknech a po 5 GB RAM, každý plot trvá necelých 8 hodin. Celkové vytížení procesoru je minimální, dlouhodobě pod 10 %, zatíženo je 12 vláken, zbytek je v podstatě na nule. Blokovaných RAM je 15 GB, reálně ale méně.  Když postupně přidám 2-3 plottingy na RAIDU ( každý plot má vlastní RAID)  z běžných HDD, opět s rozestupem (nad 11%, kdy je největší zatížení ),  Dojde k výraznému zpomalení plotování na NVMe disku - místo 8 hodin trvá klidně 16.  Na obyčejných discích dávám pouze 4 GB RAM a 2 vlákna na proces. Při tomto rozložení dochází k zatížení RAM do 20 GB, procesor není zatížený ani na 25%. Všechny komponenty jsou do 50 stupňů.  6 vláken procesoru je v podstatě na nule. Přitom počítač začíná zamrzat, je problém otevřít prohlížeč... Netuší někdo, co to brzdí, kde je systém "ucpaný" , když se všechny komponenty "nudí" ? Děkuji za odpovědi a nápady.

[RDa]

.... Mám 12 jádro Xenon (24 vláken ) .... 1 TB NVMe  zápis 3000MB, .... Můj problém je ten, že když spustím plotting 3x paralelně, s rozestupem cca 1 hodiny, každý proces na 4 vláknech a po 5 GB RAM, každý plot trvá necelých 8 hodin. Celkové vytížení procesoru je minimální, dlouhodobě pod 10 %, zatíženo je 12 vláken, zbytek je v podstatě na nule. Blokovaných RAM je 15 GB, reálně ale méně.

3 ploty budou zrat "dlouhodobe" (mimo prvni fazi) mene nez 3 vlakna z 24 moznych, coz odpovida cca 12.5% (pokud by se necekalo na disk, kdyz se ceka, je z toho mene nez 12.5, tj tvych 10%).

Tvuj setup imho vyhnije na male kapacite docasneho mista + uzkem hrdlu k R0 polim + seek time na R0. Pokud uz mas temp na rotacnim disku, nesdilej ten disk s nicim jinym, a R0 vykon disku jenom zhorsi.

[Chia-farma]

.... Mám 12 jádro Xenon (24 vláken ) .... 1 TB NVMe  zápis 3000MB, .... Můj problém je ten, že když spustím plotting 3x paralelně, s rozestupem cca 1 hodiny, každý proces na 4 vláknech a po 5 GB RAM, každý plot trvá necelých 8 hodin. Celkové vytížení procesoru je minimální, dlouhodobě pod 10 %, zatíženo je 12 vláken, zbytek je v podstatě na nule. Blokovaných RAM je 15 GB, reálně ale méně.

3 ploty budou zrat "dlouhodobe" (mimo prvni fazi) mene nez 3 vlakna z 24 moznych, coz odpovida cca 12.5% (pokud by se necekalo na disk, kdyz se ceka, je z toho mene nez 12.5, tj tvych 10%).

Tvuj setup imho vyhnije na male kapacite docasneho mista + uzkem hrdlu k R0 polim + seek time na R0. Pokud uz mas temp na rotacnim disku, nesdilej ten disk s nicim jinym, a R0 vykon disku jenom zhorsi.

Díky za rychlou reakci. Asi tvé odpovědi zcela nerozumím.  Tři paralelní ploty mají svůj TEMP na NVMe.  Nic jiného na něm neběží. Stejně tak 3 Raidy0 jsou každý POUZE pro jeden plot. Nic jiného na nich není. Zkoušel jsem plotovat na SATA 3 disku samotném bez RAIDu0, ale rychlost je znatelně pomalejší.  Mně nepřekvapuje, že je plotting na klasických discích, včetně RAIDu pomalejší. S tím jsem počítal a pustil jsem to jen pro využití dalších vláken a RAM. Mně zaráží to, že připojení  dalšího plotovacího disku výrazně zpomalí plotování na NVMe SSD disku! A to přestože RAM i procesor je studený... Hledám ten špunt  , důvod, proč i jeden dva další ploty na jiných samostatných discích zpomalí při dostatečné kapacitě RAM i CPU plotování na NVMe SSD. To zpomalení je steiné i bez RAIDu0, zkoušel jsem to na SATA3 1GB discích, na kterých jsem pustil pouze 1 plot. NVMe taky výrazně zpomalilo.

[Mirek Prýmek]

Když jsme u toho hlídání rychlosti plottingu, napsal jsem (částečně ze studijních důvodů) v Gočku jednoduchý supervisor workerů, který hlídá proces pomocí cgroups, parsuje std{out,err}, volitelně odesílá vyparsované hodnoty na MQTT, umí workera a všechny jeho děti pauznout, znovu spustit a bezpečně killnout (freezer cgroup) a umí víc tasků synchronizovat pomocí semaforů na souborovém systému (takže se pomocí něj dá třeba říct, že chci mít čtyři paralelní plottery, ale jenom dva můžou být v jednu chvíli ve fázi 1 - případné další se při čekání na semafor pauznou pomocí freezeru). Worker se může volitelně izolovat pod jiným uid, gid, sebrat mu síť a/nebo spustit v chrootu (btw, hpool plotter je staticky linkovaná binárka, takže celej chroot pro něj má asi šest souborů ).

Tohle je teda ta část "worker", ta je hotová, stačí jenom finálně projít, napsat README a můžu zvěřejňovat. Dál by měla následovat ještě část "master", která by dělala nějakou orchestraci workerů, ale to ještě nemám úplně promyšlený, jak by vlastně mělo fungovat, takže to asi hned tak nebude (nicméně pro menší plotting to není potřeba, workery stačí spustit ručně, ony už se dostatečně dohodnou pomocí zámků ).

Kdybyste někdo měli zájem to otestovat ještě před zveřejněním, dejte vědět, pošlu zdrojáky a nějaký stručný instrukce. Teď mám implementovanou verzi pro HPool plotter, ale je to záměrně udělaný tak, aby se ta parsovací část dala snadno vyměnit, takže se s tím dá supervidovat cokoli.

Konkrétně k tomu dotazu výš: stačila by malá úprava a v jakékoli fázi se dá přidat další semafor, odeslat po MQTT nějaké informace o spotřebě paměti, swapu, ... Jednoduchou úpravou by se i pomocí cgroups dala omezit spotřeba prostředků.

[Chia-farma]

Když jsme u toho hlídání rychlosti plottingu, napsal jsem (částečně ze studijních důvodů) v Gočku jednoduchý supervisor workerů, který hlídá proces pomocí cgroups, parsuje std{out,err}, volitelně odesílá vyparsované hodnoty na MQTT .....


Konkrétně k tomu dotazu výš: stačila by malá úprava a v jakékoli fázi se dá přidat další semafor, odeslat po MQTT nějaké informace o spotřebě paměti, swapu, ... Jednoduchou úpravou by se i pomocí cgroups dala omezit spotřeba prostředků.

Tohle je už pro mě vyšší dívčí    Na podobném principu možná funguje Plotmann. Bohužel zatím jen pod Linuxem.  Určitě bych to vyzkoušel, ale pokud to nebude uživatelsky přívětivé, nejspíš to nedám. Snad jedině s podrobným návodem krok co krok.  Jinak plotování Má 4 fáze. Každá má několik podfází.  V první fázi jsou kritické první dvě podfáze , do cca 11 % . Tam je vhodné, aby byl vždy jen jeden plot, jinak se vše výrazně zpomalí. Mezi 11 - 31 %  více paralelních plottingů není takový problém.  Na 31 % skončí fáze 1, proces se na relativně dlouhou dobu zastaví (podle %  vykreslování ) , ale jinak samozřejmě běží neustále.  Tady je vhodné, když se spolu další plottingy nepotkají. Jakmile se to rozběhne dále, není souběh nijak zvláště kritický. Teprve na 100 %, kdy dochází k finálnímu kopírování na koncový disk. Pokud se tady sejdou dva plottingy současně a každý valí na jiný disk, není to takový problém. Smozřejmě pokud se kopírůjí dva 100 GB soubory z různých zdrojů na jeden disk, chvíli to trvá..

[RDa]

Podle me pauzovani procesu nema smysl - jen to snizuje vykon. Zaklad je mit dostatek /temp prostoru s dostatecnym pasmem - v paralelizaci kterou CPU umoznuje. Zadny raidy zde nepomuzou, kdyz lze jednoduse pustit vicero veci - a zvedne se jen latence tvorby, ale zaroven s tim i kadence, kdyz je tam rozdelanych vicero naraz. Klasicky pipelining.

Jednou instrumentaci kterou jsem pouzil je staggered startup (ale procesy maj snahu se sebe-synchronizovat - tj. napr. v prvni fazi - namisto toho aby jeden cetl a druhej psal, tak oba ctou 2x pomalejct a pak zapisuji 2x pomalejc) - zde je to ale problem aplikacni - kdyby create umelo delat vicero veci naraz, mohl by si to sjednat poradek.

Druha instrumentace, ktera prispiva dost na celkovy vykon je - nenechavat zapis plotu na cilovej disk tomu softu co je tvori. Temp i Destination mam stejny, tj. plot po upeceni zustane tam kde se uvaril.. a hned se tvori dalsi. A pak kooperativnim manazerstvim - uzamykanim zdrojovych / cilovych disku, jsem schopen udelat paralelni a asynchronni prenosy v ramci sveho "cloudu" (mam jak pull z centralniho prekladiste, tak push rovnou do storage).

Ta prvni a druha vec spolu souvisi - ploty se musi dovarit postupne, protoze se odklizi seriove, neni zadouci aby najednou jich pristalo 12 ve fronte

Co me nejvic stve na tom reseni je, ze to neumi zastavit a pokracovat (napr. udelat reboot v te staggered pipeline, znacne snizi vykon, nebo promrha prostredky jestli se to utne). A pak, ze to je treba hlidat na dva chybove stavy: bud to zustane viset v nekonecny smycce (a nic se nedeje, jen zere cpu), nebo to spadne a tim se omezi prostor v tempu nevyuzitelnym bordelem.