Ve stažené databázi je v názvu i datum. Před kopírováním název db přepíšu na takový, jaký byl před kopírováním, nahradím db a už to nejde...
Přechod z Win 10 na RPI s Ubuntu
Ahoj, tak už konečně běžím na RPI. Od přidání dalších plotů mě ale jedna maličkost odrazuje. Když to běželo na PC , vše bylo naprosto bez problémů. Na RPI se mi tak jednou za tři dny staney že se přetrhne synchronizace... Stačí restartovat GUI, dosychronizuje se to a zase to na chvíli jede.
A druhá věc, co mě trápí, jsou menší výhry oproti PC. Jak je v GUI ta statistika, teď nevím z hlavy přesně, ale něco jako "úspěšnost bodů za posledních 24 hodin", tak oproti PC, kde bylo stabilně téměř 100 procent, není jsem kolikrát viděl i něco okolo 80 procent.
Dokázali byste poradit co s tím?
Mám tam RPI OS na ssd disku, HDD připojený přes USB hub. Připojení přes kabel z routeru. Myslel jsem, jestli to nebrzdí třeba Wi-Fi, ale ani kabel nepomohl.
Chtěl jsem přidat další disky, kfyztmi teď konečně běží RPI, ale nejdřív bych potřeboval vyřešit tenhle zádrhel...
RPI má 8 Gb RAM
KubiM Ak ti tam bezi fullnode tak si myslim ze ti to RPi aktualne nezvlada kvoli stalemu Duststormu.
Klasicke PC ma urcite vykonnejsie jadra ako RPi. Ak ti tam teda bezi fullnode tak si pozri ci ti proces fullnode vacsinou nebezi na 100%. Potom moze skusit v config.yaml nastavit hodnoty target_outbound_peer_count: 2 a target_peer_count: 2
aby si znizil pocet spojeni na fullnode. Ale nemusi pomoct ani to. Ja to mam na i3 3220 (3,3Ghz) a myslim si ze to teraz uz mam hranici stabilneho fungovania.
eSTe Díky za odpověď
Teď koukám do toho configu a fuulvnod mám nastavený takto:
target_outbound_peer_count: 8
target_peer_count: 80
Překvapilo mě, že to je docela o dost procent, pokud snížím obě hodnoty na 2
A ještě pod wallet je target_peer_count: 3 S tím tedy nic?
Jinak koukám, že full node proces vytěžuje procesor někam k 25 procentům a celkové využití procesoru se dostává přes 50 procent.
Co paměti týče, ukazuje mi využito 6100 ze 7810. Je to v pohodě?
target_outbound_peer_count je pocet spojeni ktore vytvori fullnode na ine fullnode
target_peer_count je pocet spojeni ktore mozu vytvorit ine fullnode na tvoj fullnode. Ak nemas otvorene porty z vonku je v podstate jedno co tam mas nastavene lebo sa na teba nikto nepripoji.
Ci viac spojeni mas vytvorenych tym viac ti to zatazuje tvoj fullnode lebo musi komunikovat naraz z viac fullnodmi.
Bez problemov sa da fungovat aj s takymto malym poctom spojeni
Problem je ze hlavny proces fullnode bezi len na jednom jadre tak ze treba sledovat na kolko percet je vytazeny samotny proces fullnode nie jednotlive jadra v systeme. Ak nemas nainstalovanu utilitku htop tak nainstaluj a pozri cez to.
Pamat vyzera OK. Pokial ju nemas uplne plnu a system nezacne kvoli tomu swapovat na disk, tak je to v pohode.
Ako pod walletkou mas tiez target_peer_count to je nastavenie na pocet spojeni na walletku. To mozes nechat tak.
Richi Ahoj, díky za zpětnou vazbu Právě jsem dokončil aktualizaci na poslední verzi (bylo hotovo za pár minut
) a už to zase běží. Zaujalo mě, že teď mám jen 2000 Mb využité paměti.
Ještě před aktualizací jsemcale viděl úspěšnost jen 85 procent...
Jakou ty máš úspěšnost? Drží Ti to tedy bez větších výkyvů?
Ta nova verzia 2.1.4 ma na fullnode cca 30-40% mensie zatazenie na CPU tak ze urcite odporucam nainstalovat.
To je docela velká změna Jsem moc zvědavý, jestli po nějaké době bude vidět rozdíl. Zatím mám úspěšnost 100%, ale je ještě brzo soudit.
- Edited
Rád přidal další disky/ploty, ale potřebuju, aby nehaprovala ta úspěšnost. Díky té nestabilitě mám zatím na RPI oproti PC tak o čtvrtinu až třetinu menší odměny.
Ahoj, historie se opakuje...
Byl jsem donucen přeinstalovat RPI. Po preinstalaci Chia GUI běžel, začala synchronizase. Stahl jsem celou databazi, rozbalil na PC. Na RPI jsem zastavil GUI a vzniklou db nahradil staženou rozbalenou. A mám znovu problem s tím, že po nakopirovani databaze se GUI nespusti. Premysli a premysli a bez posunu. Po smazsni db zase GUI bezi. Vubec nerozumim tomu, kde je problem....
Taky jste se s tim nekdo setkal?