Příspěvky

106

Odkladiště / Re:realisticky pohled na IoT pro dum

« kdy: 11. 07. 2021, 11:34:14 »

Co ma clovek z toho, ze si da niekam nejaky teplomer? Sleduje tam teplotu? A co dalej?

Jeden teploměr není nic moc. Pokud je venku, máš zahrádku a data ukládáš, může ti dát cennou informaci o tom, jaká byla třeba za poslední týden nejnižší teplota. To se pro zahrádkáře hodí.

Větší hitparáda je ale mít teploměr v každé místnosti. Dá ti to dost slušnou představu o tom, jak je na tom barák s izolací, kde jsou slabá místa, na co má smysl se zaměřit a co by byla naopak zbytečná snaha. A to se cení (i vzhledem k tomu, že teploměry jsou nejlevnější čidla, takže poměr cena informace/pořizovací cena je skvělý).

107

Odkladiště / Re:realisticky pohled na IoT pro dum

« kdy: 11. 07. 2021, 11:29:13 »

PS: Je ironií osudu, že uvedené spojení není vidět firem věnujících se IOT a chytrým domácnostem. Najdeme to spíš v oblasti přírodního stavitelství, ekologických staveb, permakultury. Tak aspoň jako inspirace k tématu je to snad dobré.

Je dobře, že to tady zaznělo. Možnosti pasivních řešení, která kombinují zkušenosti mnoha generací s rozumně použitými možnostmi moderních technologií (třeba i jenom materiály...), jsou často fakt dechberoucí.

Ale mají jednu zásadní nevýhodu: funkcionalita je obvykle "zabudovaná do designu", čili "funguje to tak, jak to funguje". Často superspolehlivě, ale zároveň totálně neflexibilně. Nic nenastavíš, nic nemůžeš ovládat. A to prostě někteří lidi chtějí (ať už z jakýhokoli důvodu). Takže pro někoho skvělý řešení, pro někoho úplně na prd.

108

Odkladiště / Re:realisticky pohled na IoT pro dum

« kdy: 11. 07. 2021, 11:24:55 »

Průzkume, nevím, jestli jsem z tvých příspěvků úplně pochopil, o co ti přesně jde, ale snad jo Chtěl bys nějaké opravdu spolehlivé sensory a aktuátory (až skoro na "průmyslové" úrovni), hw nechceš vůbec bastlit, chceš ho jenom zapojit, ale zároveň mít možnost si ho sám nastavit a zintegrovat. A to nastavení očekáváš dostatečně flexibilní, žádné hardwired defaults, které by tě omezovaly. Je to tak? ​

Když se ptáš "proč to neexistuje za nějakou normální cenu", tak  já  bych tipoval, že je to prostě proto, že 1. přesně tohle je dost úzkej segment (v rámci už tak relativně úzkýho segmentu) 2. škála možností, jak něco takovýho realizovat, je fakt široká (čili opět x ještě užších segmentů) 3. celej ten trh se momentálně mění a usazuje, takže některá řešení prostě ještě nikdo nezačal dělat

K tomu úzkýmu segment: tradičně byla automatizace záležitost pro lidi, kterým se ve třicetimilionovým rozpočtu na barák jeden milion ztratil. A poršáky už mají v garáži dva, další by jenom překážel, tak proč to nevrazit do automatizace?! No a během posledních cca deseti let se začaly objevovat zařízení na přesně opačným pólu spektra: levný hračky pro trochu odrostlejší kluky, s diskutabilní využitelností, spolehlivostí a tím i "dependability" (včetně třeba garance dostupnosti náhradních dílů nebo nutných služeb v budoucnosti). Střed mezi těmahle dvěma světy je podle mě víceméně pořád ještě prakticky neobsazený. Takže každopádně pokud přesně tam míříš, tak 1. budeš si to muset poskládat dost sám 2. budeš se muset rozhodnout, jestli budeš komponenty brát z toho "vyššího" nebo "nižšího" světa.

Pokud z toho vyššího, tak to asi bude něco kolem toho KNX, jak radili kolegové (osobně zkušenost nemám, tak se nebudu vyjadřovat).

Pokud z toho nižšího, budeš to mít složitější, protože musíš velice pečlivě vybírat, abys v té záplavě (z velké části) sraček vybral něco, co pragmaticky dává smysl, má to dobrej poměr cena/výkon a zapadá ti to do tvé představy.

Já třeba mám se zigbee jinou zkušenost než ty. Kvality a interoperability jsem se předem obávál, takže jsem nakonec nakoupil jenom věci z IKEA (v současnosti imho nejlepší poměr cena/výkon) a zintegroval pomocí zigbee2mqtt a NodeRED. Vypínače jsou sice bateriový, ale i na nejfrekventovanějších místech mi začínají docházet baterky po roce a půl. Což je pro mě osobně úplně OK vzhledem k ceně a kvalitě. Mesh funguje bezproblémově. Po výpadku proudu sice mívám občas měnší problémy, ale příčina může být kdekoli a nestojí mi za to ji identifikovat, protože prostě stačí restartovat virtuál, vypnout a zapnout jistič nebo tak něco... Pro mě je to akceptovatelný, pro tebe nemusí být.

Takže já jsem s tím "nižším světem" dost spokojený a nemám důvod nadávat jako ty. Ale na druhou stranu, mě to bastlení kolem toho baví, takže mám pravděpodobně laťku tolerance k problémům dost jinde než ty

109

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

« kdy: 01. 06. 2021, 17:49:43 »

Vadi me ze to nejde zatavit (resp. zrestartovat) v jakekoliv mezi-bucketove pozici, aby to pokracovalo po rebootu.

Jasný, ja ti rozumím. Tohle by teoreticky pomocí toho freezeru mělo jít taky, ale nebude to triviální a nechce se mi s tím babrat, protože ďábel bude určitě v detailu...

The cgroup freezer will also be useful for checkpointing running groups
of tasks. The freezer allows the checkpoint code to obtain a consistent
image of the tasks by attempting to force the tasks in a cgroup into a
quiescent state. Once the tasks are quiescent another task can
walk /proc or invoke a kernel interface to gather information about the
quiesced tasks. Checkpointed tasks can be restarted later should a
recoverable error occur. This also allows the checkpointed tasks to be
migrated between nodes in a cluster by copying the gathered information
to another node and restarting the tasks there.

https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt

Taky jsem ještě nezkoumal detaily toho, jak ten hpool-plotter pracuje s tou ProofOfSpace binárkou - jestli ji spouští jenom jednou a ta běží až do konce, nebo jestli ji třeba nestartuje víckrát s různými parametry. Pokud by to bylo to druhý, tak aspoň mezi těmi execy by to mělo jít pořešit. Ale z mýho pohledu je to zbytečná námaha. Navíc HPool plotter bude s příchodem oficiálních poolů obsolete...

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.

Já to mám udělaný tak, že co worker, to samostatný proces. Takže reload nové verze by nebyl problém (po skončení plotu). Ale taky jsem tuhle potřebu nijak zvlášť nepocítil

110

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

« kdy: 01. 06. 2021, 14:31:44 »

Podle me pauzovani procesu nema smysl - jen to snizuje vykon.[...] Klasicky pipelining.

No pokud pipelina neni ve vsech castech stejne tlusta (coz u chia plottingu neni), tak se musi cekat na zamek. A jedinej robustni zpusob je freezer. Je to relativne pomaly, ale o nekolik radu pod sekundou, takze to v celkove dobe plottingu absolutne nehraje roli.

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

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.

CPU se da prave pomoci cgroups zastropovat (to nemam, protoze jsem to zatim akutne nepotreboval).

Bordel v tempu resit umim - ze stdout se vyparsuje ID plotu a pokud worker skonci neuspesne, muzou se tempy automaticky smazat.

111

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

« kdy: 01. 06. 2021, 12:51:50 »

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

112

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

« kdy: 27. 05. 2021, 12:17:49 »

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

113

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

« kdy: 22. 05. 2021, 19:26:39 »

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.

114

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

« kdy: 22. 05. 2021, 10:11:16 »

plot na SSD bude 6 hodin, vs HDD 12 hodin

Pokus na 3-diskovém ZFS RAIDZ-1 s SSD read cachí[1]:

time="2021-05-21T17:16:04Z" level=info msg="Use 8h17m28.74576069s"

Bez paralelizace, jenom jeden plot.

[1] ta na to nejspíš nebude mít větší vliv, protože podle iostatu se v ní zaplnilo jenom 85G a to tam byl i jiný provoz než plotting

Pro začátek ...nejspíš i pro konec... do toho přijde 400 GB RAM (to je jediné zajímavé)

Jdeš do toho teda hodně velkoryse ) Ale bacha, jestli ty RAMky plánuješ na ramdisk, tak asi stačí, když zvýší parametr k (to nedávno udělali) a bude ti to nejspíš na prd. Na paralelní plotting super, ale to zas bude asi overkill na těch 12 disků...

115

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

« kdy: 21. 05. 2021, 19:46:37 »

no ještě hpool se asi nějak může zmocnit fráze a teda mít kontrolu nad peněženkou, asi bych teda potom vygeneroval raději novou frázi a ze staré všechno převedl do nové

Jo, to jsem nezmínil, protože to je jasný - jakmile někam napíšu frázi, je ta peněženka dead

a jaký používá klíče nevím, bych řekl, že bude mít klíče hpoolu, bylo by to vidět, když dáš jeden plot do ofiko klienta a uděláš chia plots check, pak to vypisuje Pool public key a Farmer public key. Ty se dají srovnat s tvýma klíčema, který uvidíš při chia keys show. Ale tipuju, že to bude jiné a teda nepůjde je používat na slolo s oficiálním klientem.

Zkusím. Oficiálního klienta jsem zatím nezkoumal, protože solo mining jsem zhodnotil jako absolutně nezajímavej hned ze startu

no a teda musíš věřit hpoolu, že tě odměňuje spravedlivě. Nic je k tomu zatím nenutí.

Já to spíš beru tak, že mě odměňuje tak, jak mě odměňuje, a jestli je to spravedlivý neřeším, protože alternativa stejně není A hlavně beru to jako edukaci, je to zajímavá technologie, živit se tím nehodlám

116

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

« kdy: 21. 05. 2021, 17:58:38 »

jak budou pooly, tak se musí plotovat znova
starý ploty jdou pořád použít pro solo
hpool se nemá používat

Klient bez zdrojáků je hodně podezřelej, ale tak pokud se plottuje bez připojení k netu, farmaří v oddělené VLANě a kontroluje, že na té VLANě není žádný extrémní provoz, tak nehrozí celkem nic. Teda kromě toho, že si Číňani výdělek nechají a udělají na mě jenom dlouhý nos

Spíš mi ale šlo o to, jestli někdo neví, jak ty HPool ploty vlastně fungují. Asi se vyrábí na základě klíče, který vznikne kombinací mého klíče a nějakého jejich vygenerovaného, ne? Takže kdybych vzal HPool plot a farmařil na něm solo s oficiálním klientem, tak v případě výhry by odměnu získal HPool a já bych neměl vůbec nic, protože jsem v průběhu HPoolu neprokazoval, že farmařím. Je to tak, ne?

Pokud jo, tak asi dává smysl, jakmile začnou oficiální pooly, pořád farmařit na těch HPoolových s jejich klientem a HPool ploty postupně nahrazovat těmi novými "přenositelnými", ne?

117

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

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

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

Vubec nerozumim tomu, co pocitas a proc TCO je prece (fixni nakupni cena HW + náklady na energii)/zivotnost a navic ji asi budes chtit vztahnout ke kapacite. Co to ma co delat s rychlosti plottingu a proc to pocitas tak divne?

Jestli ti slo o vypocet ceny toho, ze HW je pripraven, ale nefarmi, protoze plotting je pomalejsi, no tak naklady jsou uplne stejne jako by farmil - tj. staci ti spocitat cenu toho, co jsi nenafarmil.

jestli na to nespechas a mas malo TB k promalovani, tak klidne HDD.

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?

118

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

« kdy: 21. 05. 2021, 09:39:16 »

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

119

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

« kdy: 19. 05. 2021, 21:21:32 »

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

120

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

« kdy: 14. 05. 2021, 13:58:54 »

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.