Sur 0.60.0, après avoir fait duniter reset et un duniter sync cgeek.fr 9330 je processus de sync reste bloqué à 12%
2017-01-02T17:35:30+00:00 - info: Try with 88.174.120.187:9330 HnFcSm
2017-01-02T17:35:30+00:00 - info: Sync started.
2017-01-02T17:35:30+00:00 - info: Getting remote blockchain info...
2017-01-02T17:35:32+00:00 - info: Downloading Blockchain...
2017-01-02T17:35:47+00:00 - error: No answer after 15000ms, will retry download later.try download later.
...
en suite, après deux minutes:
2017-01-02T17:37:10+00:00 - error: No answer after 15000ms, will retry download later.
2017-01-02T17:37:10+00:00 - error: No block was downloaded
2017-01-02T17:37:10+00:00 - warn: Chunk #273 DOES NOT CHAIN CORRECTLY from duniter.aquilenet.fr:8999
2017-01-02T17:37:14+00:00 - error: No answer after 15000ms, will retry download later.
2017-01-02T17:37:15+00:00 - error: No answer after 15000ms, will retry download later.
...
et en suite plus de progression pendant deux heures environ.
Faut-il avoir plus de patience ou est-il quelque chose d’autre à faire ?
La phase “Apply” du sync prends vraiment long temps, j’imagine parce que c’est qu’un Raspberry Pi… faut prévoir ajuster l’option CPU avant “duniter start” ?
Ce n’est pas encore très optimisé tout cela, et TestNet a tout de même 9 mois d’existence. On pourra faire beaucoup mieux. Et bien sûr le Raspberry n’excelle pas dans l’écriture disque
Pour le CPU, tu peux le laisser par défaut à 60%. Si tu constates que c’est vraiment trop, tu pourras baisser.
Hmmm… top montre le processus duniter_default à 104% d’usage CPU. Les quatre processus node sont à 8% environ chacun.
J’ai testé plusieurs valeurs cpu dans .config/duniter/duniter_default/conf.json – 0.2, 0.4, 0.6 et 0.8 – mais chaque fois (après duniter stop/start) les pourcentages d’usage CPU montré par top sont pareil.
Et duniter logs montre des entrées comme ceci deux fois par seconde, à l’infini:
2017-01-05T06:54:16+00:00 - info: Generating proof-of-work with 0 leading zeros followed by [0-9A-F]... (CPU usage set to 20%) for block#60000 9Hrc2f
2017-01-05T06:54:16+00:00 - info: Stop proof-of-work worker #1
2017-01-05T06:54:16+00:00 - info: Stop proof-of-work worker #2
2017-01-05T06:54:16+00:00 - info: Stop proof-of-work worker #3
2017-01-05T06:54:16+00:00 - info: Stop proof-of-work worker #4
2017-01-05T06:54:16+00:00 - info: ENGINE #1 HAS FOUND A PROOF
2017-01-05T06:54:16+00:00 - info: Stop proof-of-work worker #1
2017-01-05T06:54:16+00:00 - info: Stop proof-of-work worker #2
2017-01-05T06:54:16+00:00 - info: Stop proof-of-work worker #3
2017-01-05T06:54:16+00:00 - info: Stop proof-of-work worker #4
2017-01-05T06:54:16+00:00 - info: Done: F1D67D20CED7CA25634A805A03C827247605B7B8033252B91ED8CF36FC23CA73 in 0.04s (0 tests, ~0.00 tests/s)
2017-01-05T06:54:16+00:00 - info: FOUND proof-of-work with 0 leading zeros followed by [0-9A-F]!
2017-01-05T06:54:16+00:00 - warn: Proof-of-work self-submission: ruleNumber
Ton nœud ne m’a pas l’air correctement initialisé, le bloc 60000 est de début décembre : c’est assez loin et ça vu le n° multiple de 10, je pense à un problème de synchronisation initiale.
Peux-tu retenter le reset data + resynchro ? Eventuellement, avant de relancer ton nœud, tu pourras nous partager ton fichier de logs afin de voir comment celle-ci s’est déroulée.
OK, fait un reset et sync à nouveau et les logs ont changé complètement. Peering, pulling and PoW computation apparemment … Par contre l’usage CPU est à 99,9% pour tous les 4 cœurs constant même si le paramètre cpu est à 0.2
htop montre 4 processus node, chacun à 99,9% environ
Sauf que là, il y avait un influence du paramètre cpu. Maintenant ça n’as plus l’air de l’avoir…
Qu’une erreur dans le log:
2017-01-05T13:29:16+00:00 - info: Crawling the network...
2017-01-05T13:29:16+00:00 - info: Crawling done.
2017-01-05T13:29:16+00:00 - error: Unhandled rejection: TypeError: done is not a function
Je confirme, il y a bien une régression et le %CPU n’est pas pris en compte. La valeur 60% est sélectionnée par défaut, mais en plus sur Raspberry PI 60% = saturation.
2017-01-05T18:21:54+00:00 - warn: Security trigger: proof-of-work process seems stuck
2017-01-05T18:21:55+00:00 - warn: Too high difficulty: waiting for other members to write next block
et
2017-01-05T18:22:57+00:00 - info: Pulling blocks from the network...
2017-01-05T18:22:58+00:00 - error: Blocks were not applied.
2017-01-05T18:22:59+00:00 - error: Blocks were not applied.
2017-01-05T18:23:00+00:00 - error: Blocks were not applied.
Le security trigger, c’est juste un mécanisme “au cas où”, mais rien de méchant.
Too high difficulty : c’est l’une des spécificités de Duniter, on ne calcule pas en permanence la preuve de travail
Blocks were not applied : mauvais niveau de log, info serait plus juste
Par ailleurs, une 0.80.2 est en cours de build, elle apparaîtra peut-être d’ici 1h pour ARM, et devrait permettre de régler le CPU comme avant et même mieux.
Je viens d’installer v0.80.4 et hop, ça marche nickel. L’usage des cœurs reste bien en dessous du valeur cpu dans conf.json généralement. Même avec un valeur de 1.0 (que pour tester!), l’usage réel reste à 70% environ, le temp CPU ne monte plus à 80°C et tout va bien