Ici on peut voir qu’aux dernières nouvelles, on a 6 nœuds dont le bloc courant est 58767-0000D592A. Et qu’on a aussi un nœud dont le dernier signal était d’avoir comme bloc courant 58177-00005A2C1.
Tous les nœuds WS2P propagent cette info, en broadcast avec rebond. Donc un nœud miroir est censé avoir ces infos aussi.
Tu peux modifier le fichier proof.js de Duniter pour afficher des messages dans le processus principal préalablement lancé avec duniter direct_start. Ça te permettra de déboguer un peu et savoir ce que fait le processus.
Par exemple entre la ligne 1 et 2, tu insères un messages :
console.warn(`Le fils est lancé (PID ${process.pid})`)
Puis ligne 18-19, tu insères une autre ligne :
console.warn(`Le chargement des modules s'est bien passé (PID ${process.pid})`)
Et ainsi de suite jusqu’à trouver un truc intéressant.
Alors je n’ai pas trouvé de truc intéressant comme cela, mais les processus fils sont bien quittés. Donc le problème se passe quand j’utilise duniter stop.
Comme je n’arrive pas à me connecter au réseau en WS2P privé, il faudra attendre que je sois chez moi pour ouvrir des ports et tester en WS2P public. Je ne peux donc pas voir si duniter continue calculer de vieux blocs.
Si tu laisses ton nœud tourner suffisamment longtemps, ça te permettra d’en savoir pas mal sur le cycle de vie effectif de les processus de preuve. Et moi de comparer avec ce qui est attendu
Oui alors ce problème vient du fait que le réseau Ğ1 est encore peu déployé en WS2P, alors au démarrage ton nœud ne trouve pas de quoi se connecter (je viens de vérifier). Le réseau Ğ1-Test est plus adapté pour l’instant.
Je vois aussi des info: Cancelling the work on PoW cluster mais non suivis d’un Commande IPC: cancel qui pourtant devrait apparaître. D’ailleurs je ne vois pas plus de Commande IPC : newPoW normalement consécutive à une annulation qui se poursuit avec une nouvelle preuve, ce qui me fait dire que c’est toute la communication IPC qui est coupée.
la communication IPC “coupée”, à cause du CPU 100% (en réalité elle n’est pas coupée, mais n’a plus de temps processeur pour répondre)
Cela vient d’une cadence trop haute de calcul, le fait d’avoir un tour de preuve en 100ms est trop élevé pour des cartes aussi faibles en puissance, relativement au travail cryptographique demandé et aux traitements annexes qui sont faits (traitement normal des identités, transactions, etc).
J’ai testé avec des tours à 500ms (presque 100ms par cœur en fait), et j’ai à peu près la calibration demandée du %CPU utilisable. Bon c’est vraiment pas terrible car c’est du doigt mouillé, mais expérimentalement je constate à peu près la bonne valeur. En tout cas même si la correspondance n’est pas parfaite entre %CPU demandé et réel, on peut ajuster la valeur %CPU pour atteindre la valeur réelle désirée.
Il se passait que mon nœud était l’un des seuls à fournir la connexion WS2P publique, or mon YunoHost a fait des siennes et fermé les ports utilisés pour Duniter, notamment WS2P.
Donc ça fait un gros point central d’échec, et ça a fichu un peu le boxon. Néanmoins, c’est revenu
Oui mais voilà … l’idée c’est plutôt de faire comme @Pafzedog, et de mettre à disposition son nœud pour du WS2P public. Plus on est nombreux à le faire, plus résilient sera le réseau car décentralisé.
Pour cela : « WebUI > Settings > Network > Enable WS2P access ». Puis sauvegarder et appliquer.
Vous pouvez vérifier que ça fonctionne bien en ayant des entrées « INCOMING » dans votre vue réseau. Vous pouvez également tester votre adresse avec un outil comme Simple WebSocket Client (extension Chrome/Firefox), par exemple avec la mienne :
S’il y a une ligne « CONNECT », c’est que votre configuration fonctionne.