Těžíte XCH (Chia) ?

[xyz]

Tak tezba bitcoinu je jako 8 Temelinu (bezici na plny vykon). To jsem myslel, ze se spotrebova jeste vic. A pry 75% je z obnovitelnych zdroju.... 

[Reklama]

[PanVP]

Bez znalosti konkretniho access patternu se to optimalizovat neda. Takze pokud nezname co to dela, plati ze to cte vsechno a zapisuje vsechno, tudiz cache je zbytecna. A cachovat cely dataset je nesmysl, bys potreboval 250 GB pameti na 1 cpu jadro... ale jo.. jsou i stroje s 4 TB ram, nicmene tam to bude brzdit zas cpu.

Zkusím to monitorovat, poskládám to úložiště z bloků 64 GB a uvidím, jestli je nějaké místo, kde by mohlo mít použití té paměti jako Cache nějaký smysl. Pokud vůbec takové místo je. Celkově se prý zapíše >1 TB dat, pokud bych se trefil do správného místa, jednak se to (asi?) zrychlí a jednak dostane SSD menší čoud.

Cloveka ale hreje u srdce, kdyz ma "disky" od nejmenovaneho vyrobce procesoru, co mu pry ujel vlak
Endurance Rating (Lifetime Writes): 41.0 PBW (30DWPD), 82.0 PBW (60DWPD)

Congratz, procesory od Intelu nemám rád, ale SSDčka umí no...

Jinak pro bezneho smrtelnika i profi plottera je TBW byt jedineho economy sata disku (120TBW) neomezujici faktor - srovnejte si ceny toho SSD a pole o dane kapacite, budete cca na 1% overheadu :-)

Taky pravda, proč se tím trápit že? No tak jedno odkouřím...

[PanVP]

BTW - dost podražují disky

[Mirek Prýmek]

Zkusím to monitorovat, poskládám to úložiště z bloků 64 GB a uvidím, jestli je nějaké místo, kde by mohlo mít použití té paměti jako Cache nějaký smysl. Pokud vůbec takové místo je. Celkově se prý zapíše >1 TB dat, pokud bych se trefil do správného místa, jednak se to (asi?) zrychlí a jednak dostane SSD menší čoud.

IMHO to bude zbytečná snaha. Lepší by bylo optimalizovat poměr SSD/RAM/CPU - v různých fázích plottingu se úložiště používá různě intenzivně, takže nejvíc pravděpodobně získáš tím, že si dobře rozvrhneš paralelní plotting tak, abys přesně využil HW na max.

[RDa]

Zkusím to monitorovat, poskládám to úložiště z bloků 64 GB a uvidím, jestli je nějaké místo, kde by mohlo mít použití té paměti jako Cache nějaký smysl. Pokud vůbec takové místo je. Celkově se prý zapíše >1 TB dat, pokud bych se trefil do správného místa, jednak se to (asi?) zrychlí a jednak dostane SSD menší čoud.

IMHO to bude zbytečná snaha. Lepší by bylo optimalizovat poměr SSD/RAM/CPU - v různých fázích plottingu se úložiště používá různě intenzivně, takže nejvíc pravděpodobně získáš tím, že si dobře rozvrhneš paralelní plotting tak, abys přesně využil HW na max.

Tak v linuxu existuji diskove buffery - a lze to ridit pres /proc/sys/vm/dirty_bytes .... pokud si tam clovek nastavi 100GB, tak veske zapisy, ktere nastanou pred bodem flushnuti (fclose?) jdou do ramky.. a az pak na disk. Kdyz si to clovek zvedne, tak vidi jak z R/W operaci se stanou reads only... a az dojde na lamani chleba, tak proces je uspan a flushuji se dirty pages na disk :-)

[Reklama]

[Mirek Prýmek]

Tak v linuxu existuji diskove buffery - a lze to ridit pres /proc/sys/vm/dirty_bytes .... pokud si tam clovek nastavi 100GB, tak veske zapisy, ktere nastanou pred bodem flushnuti (fclose?) jdou do ramky.. a az pak na disk. Kdyz si to clovek zvedne, tak vidi jak z R/W operaci se stanou reads only... a az dojde na lamani chleba, tak proces je uspan a flushuji se dirty pages na disk :-)

To je docela zajímavej tip. Ale obávám se, že kdyby to bylo tak jednoduchý, tak by téhle rady byl plnej net

Obávám se, že ten algoritmus bude z principu docela "odolnej proti cachování", protože je to nějaká obrovská tabulka, která se postupně uspořádává, takže dopředu se podle mě neví, kam se v rámci celýho toho jednoho plotu bude šahat... (Vařím z vody, ještě jsem nenašel čas si to pořádně nastudovat. Kdyby někdo měl chuť: https://www.chia.net/assets/ChiaGreenPaper.pdf EDIT: nebo možná spíš tohle: https://www.chia.net/assets/proof_of_space.pdf ).

[PanVP]

Je to velmi zajímavý tip a vyzkouším ho.
Problém je, jak to změřit, aby to mělo skutečnou vypovídací hodnotu.

[_Jenda]

V tom návodu někde psali že vygenerovat to dočasně vyžaduje 230 GB, 100 to má až když je to hotové.

Navíc chcete generovat víc současně protože to nejde paralelizovat. A terabajt paměti asi nemáte.

[k3dAR]

V tom návodu někde psali že vygenerovat to dočasně vyžaduje 230 GB, 100 to má až když je to hotové.

Navíc chcete generovat víc současně protože to nejde paralelizovat. A terabajt paměti asi nemáte.

BTW: docasne vyzaduje 239GiB per plot a pri tom generovani to zapise 1.3-1.8TiB na disk, takze normalni NVMe odejdnou za par tydnu az mesicu ;-)

[Jan Fikar]

Problém je, jak to změřit, aby to mělo skutečnou vypovídací hodnotu.

nejlepší asi je nechat to běžet týden nebo dýl a zapisovat si výstup do >> ~/chia/log{1..x} a pak pustit jednoduchý skript, který spočítá průměr, jeho standardní odchylku, medián, max a min, třeba takto https://github.com/jfikar/chia_scripts

[kotelgg]

Na těžbu je stejně lepší nacpat víc disků do raid 0. Dle tabulky cena/výkon vyšel nejlíp dokonce server s SAS plotnovýma diskama.
Cache jsem zkoušel, hit rate po 24 hodinách 0.01%.
Neplánuju do toho investovat, ale pár vyřazených ssd tu mám, tak to je dodělám.

[PanVP]

Na těžbu je stejně lepší nacpat víc disků do raid 0

Myslíš, že RAID 0?

Tedy, zásadně se pracuje třeba na 8mi plotech naráz. (To tvrdí různě na netu. Netvrdím to já a mohl jsem to blbě pochopit.)
Protože jeden plot potřebuješ ~2 vlákna + ~4 GB RAM.

Nebylo by lepší - z hlediska seeku - každému plotu nechat jeho vlastní vrtichvost (čti HDD)?

Mimochodem, jak se tím prokousávám, tak doporučují pouštět jednotlivé ploty s určitým časovým odstupem.
Takže pustíš 8 plotů naráz, ale druhý se spustí až hodinu po prvním. Mělo by tak jít zaplácnout 2TB disk za jeden den.
Má to asi 6 fází a nejnáročnější na disk jsou snad jen ty první fáze.

...až s tím skončím, zůstane mi 60 TB vánoční stromeček, protože to skládám z nových i starých disků

[PanVP]

  ...hmmm...  ...ono to jde i jednoduše?  dobře ty! 

[RDa]

Na těžbu je stejně lepší nacpat víc disků do raid 0

Myslíš, že RAID 0?
...
Nebylo by lepší - z hlediska seeku - každému plotu nechat jeho vlastní vrtichvost (čti HDD)?

Samozrejme ze bylo, protoze vykon R0 je vykon nejpomalejsiho * pocet disku, plus penalizace za asynchronni seek (rpm nejsou zcela stejne na discich, takze se sem tam holt necela otacka musi pockat).

Oddelene disky vyuziji vykon disku na max + zaruci spolehlivost, ze az se disk odporouci, tak to nevezme sebou celou rozdelanou praci na 10+ vlaknech.

[Mirek Prýmek]

Mě by spíš zajímalo, jestli jste si někdo nastudoval, jak to teda vypadá s těmi pooly (po organizační i technické stránce). Zkouším farmit na HPool a jenom zjistit, jak to rozchodit, byl trochu porod, technicky to bude asi docela hack a úplně nemám radost z používání nějakého čínského serveru...

Nevíte někdo, co bude s těmi ploty, vytvořenými pro HPool, až bude k dispozici oficiální pooling? Budou k odepsání, nebo půjdou přenést jinam?

BTW: docasne vyzaduje 239GiB per plot a pri tom generovani to zapise 1.3-1.8TiB na disk, takze normalni NVMe odejdnou za par tydnu az mesicu ;-)

Tak ono není úplně nutný likvidovat SSDčko, zvlášť pokud nemám připravenou obrovskou volnou kapacitu, kterou chci na farming využít, ne?

Pokud vytvoření plotu s SSDčkem trvá třeba šest hodin a s HDD bude trvat deset, no tak se ten plot dostane na farmu o 4 hodiny později. Network space se za tu dobu sice zvýší, ale opravdu těch pár hodin náskoku zaplatí amortizaci toho SSD? Zvlášť pokud to 1. rozpočítám na celou dobu existence toho plotu ve farmě 2. plottuju na stroji, který by stejně jel (takže elektřinu neřeším), tak použití SSD snad ani nemůže vycházet do plusu, ne? Nebo mi něco uchází?