Příspěvky

991

Odkladiště / Re:Těžíte XCH (Chia) ?

« kdy: 01. 06. 2021, 15:56:24 »

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).

To jo. Ja na to mam castecnou odpoved v tech FS semaforech - tim, ze je semafor na disku, se da procesu rucne ukrast. Tj. worker bezi, ja mu ukradnu zamek, kterej vlastni, a jakmile skonci, nema ho, takze ho nemuze vratit. Timhle postupem je mozny nechat postupne vsechny workery skoncit a restartovat potom. Neni to idealni, protoze se postupne snizuje vytizeni, ale je to asi lepsi nez zahodit rozdelanou praci...

Tak jako zastavit to mezi plotama taky umim, protoze tam mam cyklus ve kterem se tvori jen 1 plot a pak to kontroluje STOP flag (test existence souboru v dev/shm). Vadi me ze to nejde zatavit (resp. zrestartovat) v jakekoliv mezi-bucketove pozici, aby to pokracovalo po rebootu.

Druha vec co me jeste stve - na bash skriptovani - je, ze to nacitava soubor od posledni byte-pozice snad mezi prikazama? To je celkem opruz protoze nejde editovat skripty za behu a nenasel jsem na to slusne reseni.. prepisovat to do meho oblibeneho PHP uz ale nebudu.

992

Odkladiště / Re:Těžíte XCH (Chia) ?

« kdy: 01. 06. 2021, 14:15:39 »

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.

993

Software / Re:Zaseklý proces

« kdy: 01. 06. 2021, 11:43:26 »

Ten proces nebezi, ma stav Z - zombie:

Zombie (Z): we briefly talked about zombie processes when we discussed system calls. When a process finishes with exit() system call, its state needs to be "reaped" by its parent (calling wait()); in the meantime, the child process remains in zombie state (not alive nor dead).

https://cloudchef.medium.com/linux-process-states-and-signals-a967d18fab64

994

Odkladiště / Re:Těžíte XCH (Chia) ?

« kdy: 01. 06. 2021, 11:09:54 »

.... 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.

995

Vývoj / Re:Zlepšení čitelnosti vlastního kódu

« kdy: 31. 05. 2021, 01:00:01 »

Staci par pravidel:
 - veci komentovat
 - promenne ci funkce pojmenovat vystizne, i kdyz to bude delsi
 - veci neflakat:
   - - kamarad rad resi veci copy-paste zpusobem, ja preferuji deduplikaci kodu do funkci/trid/metod
   - - slozitejsi hierarchie/struktura zdrojaku neni na skodu (tridy tam, kde by to slo udelat naprasaka rovnou)
 - nepouzivat cizi kod (stackoverflow copy/paste), v pripade fakt nutnosti prevzeti uvest zdroj/url

Nemam problem se svym starym kodem - vzdy jsem ho psal abych vzdy vedel ktera bije, ne proto, ze me tlaci prace/deadline/sef atd..  samozrejme pod komercnim tlakem je situace jina.

996

Software / Re:EXT4: ls, file, ldd súbor pozná, ale "./a.out" vyhlási file not found

« kdy: 27. 05. 2021, 20:44:31 »

Tak to, ze nesel bin/sh ani /init, nesouvisi s tim, zda mas usr ci nikoliv. Jsem nedavno delal jedno harakiri (nfsboot a prenastaveni site za behu, ze ktereho to bezi) a stacilo zkopirovat   /bin /lib64 /sbin do tmpfs (ramdisku) a slo do toho udelat chroot.

Tvuj problem bych videl na to, ze nejde namountovat rootfs = nemas pak /bin/sh ani /sbin/init.

Tj. pouzivas nevhodny jadro, pro spousteni sveho OS.

BFU reseni: v bootloaderu vybrat nejakou starsi polozku, protoze vetsinou se novej kernel pridava, neprepisuje starej, a pri pregenerovani grub.conf se tam ty starsi veci objevi.

997

Software / Re:EXT4: ls, file, ldd súbor pozná, ale "./a.out" vyhlási file not found

« kdy: 27. 05. 2021, 18:02:17 »

A proc se vlastne snazis neco poustet ze sveho disku nebo tam delat chroot, kdyz vis ze tam neni /usr ?
Prvni pravidlo zachrany je - nesahat do poskozeneho. A druhy je zalohovat.. nejspis to mas hodne roz*****e takze bootni live distro / live cd (gentoo admincd ?), a odzalohuj si /etc, /root a /home, pripadne /opt a jine.. a udelej reinstall.

Protoze i kdyby jsi s e2fsck /dev/susedisk pochodil, to neni nastroj ktery by ti navratil /usr, ale vytvori zmet anonymnich souboru v lost+found.

998

Software / Re:EXT4: ls, file, ldd súbor pozná, ale "./a.out" vyhlási file not found

« kdy: 27. 05. 2021, 16:36:46 »

Pokud me pamet neklame, tak *file not found* byva i problem kdyz chces pustit 64bit exac z 32bit kernelu.

999

Hardware / Re:Disk s heliem: co se stane po nahrazení vzduchem?

« kdy: 26. 05. 2021, 18:30:30 »

A taky nevím, jestli by případně helium s nižším odporem při proudění (tj. asi nižší viskozitou?) než vzduch nezpůsobilo havárii kvůli nedostatečně silnému polštáři plynu, na kterém by hlavička měla "plavat".

Bingo, a o to me slo, ze to neni mozny z duvodu dvojiho vyladeni:
 - ploten vs. plynu
 - plynu vs. hlavicek
na dany druh plynu pod urcitym tlakem.

To mate jako zakon nabidky a poptavky - protne se to v jednom bode - a tento operacni bod nelze nijak zlepsit posunem vlevo ci vpravo.

1000

Hardware / Re:Disk s heliem: co se stane po nahrazení vzduchem?

« kdy: 26. 05. 2021, 16:06:21 »

Dokonce jsem nasel video :-)
Skoda, ze nemam vakuovou komoru, zkusil bych nahradit plyn v normálním disku, jestli bude chladnější nebo tišší. Vakuum nemusí být dokonalé, v disku nebude přetlak, ale atmosférický tlak při 40°C protože tak...

Doporucuji se podivat na specifikaci disku - byva ta uvedena maximalni operacni nadmorska vyska.
A pak zopakovat prepocet atmosferickeho tlaku podle nadmorske vysky.

Porad si myslis, ze menit neco na desetileti ladenem operacnim bodu tak slozite veci jako je moderni pevny disk prinese nejakou citelnou zmenu, krome urychlene desktrukce?

Ale pokud disk nema senzor tlaku.. je vakuova komora zrejme lepsi zpusob zajisteni vady v zarucni dobe, nez elektricke soky, ktere precejen zanechaj viditelnejsi dukazy.

1001

Odkladiště / Re:Těžíte XCH (Chia) ?

« kdy: 23. 05. 2021, 00:00:11 »

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.

1002

Odkladiště / Re:Těžíte XCH (Chia) ?

« kdy: 21. 05. 2021, 13:40:07 »

No to jsem presne psal - pokud chci na farmeni venovat jeden 4TB disk, tak me nemusi az tak trapit, jestli se ploty vytvori za 240 nebo 480 hodin. O nejaky vydelek sice prijdu, ale opravdu tak velky, aby to zaplatilo snizenou zivotnost draheho SSD?

Jenomze na SSD tech plotu udelate treba 4 nebo 8 (pokud mate 1T/2T kapacitu a prislusna cpu jadra), takze zrychleni je 8x az 16x. Alterntivne potrebujete 8-16 disku paralelne - pro stejny vykon.

A pro 4TB vas snizena zivotnost v podobe 4T x15 = 60TBW zkonzumovanych trapit nebude (je to jen zlomek beznych SSD a pulka tech nejhorsich a nejmensich). Takze nedava smysl premyslet o HDD, kdyz mate *jakekoliv* SSD po ruce.

Nicmene, se 4T bude pravdepodobnost vyhry v loterii blizici se k nule, takze jo.. uz na tom nesejde zda to mate za 10 nebo 20 dnu hotovy :-)

1003

Odkladiště / Re:Těžíte XCH (Chia) ?

« kdy: 21. 05. 2021, 12:19:40 »

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í?

Uchazi ti to, ze plot na SSD bude 6 hodin, vs HDD 12 hodin. Ale to mas 1 plot na 1 HDD (8x15W), a klidne 8 plotu na 1 SSD (1x25W). Tudiz TCO na hdd bude 12h x (2*8) x 15w = 2880 Wh, vs ssd za (2*6h)x1x25w = 300 Wh. plus u obojiho cca 150W cpu vykonu, takze mame pro stejny plotovaci vykon naklady 390 vs 175 W.

Pak zalezi jen na zplotovanem objemu, kdy se ti krivka efektivity protne - jestli na to nespechas a mas malo TB k promalovani, tak klidne HDD. V pripade ze na to ( spechas nebo mas malo TB) nebo (mas hodne TB), tak SSD je jasna volba.

1004

Odkladiště / Re:Těžíte XCH (Chia) ?

« kdy: 21. 05. 2021, 01:43:37 »

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.

1005

Odkladiště / Re:Těžíte XCH (Chia) ?

« kdy: 19. 05. 2021, 21:06:26 »

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 :-)