Pourrais-tu fournir la suite de logs de la PoW qui te fait dire cela ? Voici la mienne par exemple, une fois retirés les logs non pertinents :
18:41:33+02:00 - info: Matched 3 zeros 000FA7FFD71252EF8D7D961B8AAFF55E5911D81BD46A43DDAD3FB009E400E87B with Nonce = 100000054260 for block#54922 by 2ny7YA
18:41:37+02:00 - info: Matched 3 zeros 0008623EBD683CC3A97C6FC730ED96AD2A79AC78052288AF9430E8A5F30569D0 with Nonce = 300000055131 for block#54922 by 2ny7YA
18:41:42+02:00 - info: Matched 3 zeros 000586E45836BA83B0AEDCF9497286D61B082863AB630299BE43D3C1BA257DA4 with Nonce = 300000056466 for block#54922 by 2ny7YA
18:41:46+02:00 - info: Matched 3 zeros 000EAD1899712FBE8F4B34A7A369E7D9CFD3491F43CDD4A408EA8E119D354C10 with Nonce = 100000057627 for block#54922 by 2ny7YA
18:41:48+02:00 - info: Matched 3 zeros 0007967031DAE178CB8EF9941EB52C0FE08897B14BD6165D2C9417D0938E2C55 with Nonce = 200000058229 for block#54922 by 2ny7YA
18:41:50+02:00 - info: SIDE Block #54922-000008A2 added to the blockchain in 12 ms
18:41:50+02:00 - info: Block resolution: 1 potential blocks after current#54921...
18:41:50+02:00 - info: POST Block block#54922
18:41:50+02:00 - info: Block #54922 added to the blockchain in 96 ms
18:41:50+02:00 - info: Cancelling the work on PoW cluster
18:41:50+02:00 - info: GIVEN proof-of-work for block#54922 with 5 leading zeros followed by [0-9A-E]! stop PoW for 2ny7YA
18:41:50+02:00 - info: Cancelling the work on PoW cluster
18:41:50+02:00 - warn: The proof-of-work generation was canceled: Proof-of-work computation canceled because block received
18:41:50+02:00 - info: Block resolution: 0 potential blocks after current#54922...
18:41:54+02:00 - info: Generating proof-of-work with 5 leading zeros followed by [0-9A-E]... (CPU usage set to 55%) for block#54923 2ny7YA
18:41:57+02:00 - info: Matched 3 zeros 0004F5C36EC923BA6DD1C3B736122472F135FE707F3B15FACC4E38687F54BD74 with Nonce = 10200000000770 for block#54923 by 2ny7YA
18:42:06+02:00 - info: Matched 3 zeros 0009DC0A695567A74C72A0492EF6822FF739833351AD65B5F3FEF689C47BF8CA with Nonce = 10300000003218 for block#54923 by 2ny7YA
18:42:08+02:00 - info: Matched 3 zeros 000A9D25B9FAC3DA2551BFE6F2EEB9A1E82F01F55B54E6BDC41159647B4FB2B5 with Nonce = 10300000003745 for block#54923 by 2ny7YA
On peut voir que le nœud calculait la PoW pour le bloc 54922, puis que le bloc a été reçu de façon externe et ajouté à la blockchain ce qui a déclenché l’annulation de la preuve courante (“GIVEN proof-of-work[…]”, puis “Cancelling[…]”). Enfin le nœud est parti sur la preuve du bloc 54923, le bloc suivant donc.
2017-09-22T14:24:55+02:00 - ESC[32minfoESC[39m: Block #54595 added to the blockchain in 746 ms
2017-09-22T14:24:55+02:00 - ESC[32minfoESC[39m: Cancelling the work on PoW cluster
2017-09-22T14:24:55+02:00 - ESC[33mwarnESC[39m: WS2P >> Streamer >> WS2P connection timeout
2017-09-22T14:24:55+02:00 - ESC[32minfoESC[39m: GIVEN proof-of-work for block#54595 with 5 leading zeros followed by [0-9A-B]! stop PoW for 48SLtT
2017-09-22T14:24:55+02:00 - ESC[32minfoESC[39m: Cancelling the work on PoW cluster
2017-09-22T14:24:55+02:00 - ESC[33mwarnESC[39m: The proof-of-work generation was canceled: Proof-of-work computation canceled because block received
2017-09-22T14:24:55+02:00 - ESC[32minfoESC[39m: Block resolution: 1 potential blocks after current#54595…
2017-09-22T14:25:03+02:00 - ESC[32minfoESC[39m: Matched 3 zeros 000E3F32D8314C21040BA7B539BBC2F8C630A7F216B9E66DC7690A678F169112 with Nonce = 200000000323 for block#54595 by 48SLtT
Plus bas je vois encore des histoires de « Matched 3 zeros » pour ce même bloc, alors que d’autres sont trouvés depuis.
J’essaye de relancer duniter mais il n’arrive pas à se connecter donc il cherche un vieux bloc
2017-09-25T14:16:39+02:00 - info: >> Server starting…
2017-09-25T14:16:39+02:00 - info: Node version: 1.6.4
2017-09-25T14:16:39+02:00 - info: Node pubkey: 48SLtTLL3CxAXUcmbKwp2PUg1hUvEh2s5EwEpRh8RaoR
2017-09-25T14:16:40+02:00 - info: Sibling endpoints:
2017-09-25T14:16:40+02:00 - info: PEER 48SLtTLL
2017-09-25T14:16:40+02:00 - info: ✘ PEER 48SLtTLL
2017-09-25T14:16:40+02:00 - error: Peer with zero endpoints that is not already known
2017-09-25T14:16:40+02:00 - info: Next peering signal in 9 min
2017-09-25T14:16:50+02:00 - info: WS2P: Could not connect to peer -------- using WS2P g1.duniter.org 20903: WS2P connection timeout
2017-09-25T14:17:00+02:00 - info: WS2P: Could not connect to peer -------- using WS2P 88.174.120.187 20901: WS2P connection timeout
2017-09-25T14:17:10+02:00 - info: WS2P: Could not connect to peer -------- using WS2P 163.172.178.252 8999: WS2P connection timeout
2017-09-25T14:17:15+02:00 - info: Generating proof-of-work with 5 leading zeros followed by [0-9A]… (CPU usage set to 60%) for block#54609 48SLtT
J’ai redémarré le serveur (ce qui fait que cela remarche), et je revois la même chose
2017-09-22T14:37:35+02:00 - ESC[32minfoESC[39m: Block resolution: 1 potential blocks after current#54604…
2017-09-22T14:37:37+02:00 - ESC[32minfoESC[39m: Block #54605 added to the blockchain in 748 ms
2017-09-22T14:37:37+02:00 - ESC[32minfoESC[39m: Cancelling the work on PoW cluster
2017-09-22T14:37:37+02:00 - ESC[33mwarnESC[39m: WS2P >> Streamer >> WS2P connection timeout
2017-09-22T14:37:37+02:00 - ESC[33mwarnESC[39m: WS2P >> Streamer >> WS2P connection timeout
2017-09-22T14:37:37+02:00 - ESC[33mwarnESC[39m: WS2P >> Streamer >> WS2P connection timeout
2017-09-22T14:37:37+02:00 - ESC[32minfoESC[39m: GIVEN proof-of-work for block#54605 with 5 leading zeros followed by [0-9A]! stop PoW for 48SLtT
2017-09-22T14:37:37+02:00 - ESC[32minfoESC[39m: Cancelling the work on PoW cluster
2017-09-22T14:37:37+02:00 - ESC[33mwarnESC[39m: The proof-of-work generation was canceled: Proof-of-work computation canceled because block received
2017-09-22T14:37:37+02:00 - ESC[32minfoESC[39m: Block resolution: 0 potential blocks after current#54605…
2017-09-22T14:37:38+02:00 - ESC[33mwarnESC[39m: Block already known
2017-09-22T14:37:38+02:00 - ESC[32minfoESC[39m: Matched 3 zeros 000BBFA728C87EE2BB926CA2B216EA1BE1FFF8872CAC6BF4471BFA67D4555280 with Nonce = 200000003652 for block#54605 by 48SLtT
2017-09-22T14:37:54+02:00 - ESC[32minfoESC[39m: PEER t5RR5eVe
2017-09-22T14:38:23+02:00 - ESC[33mwarnESC[39m: httpCode=400, ucode=1015, message=Document already under treatment
2017-09-22T14:38:35+02:00 - ESC[32minfoESC[39m: Matched 3 zeros 000646487975746D4423766905FF8216AA57F878D17B5B0882021FB34FA10478 with Nonce = 200000004609 for block#54605 by 48SLtT
et même quelques minutes après
2017-09-22T14:41:16+02:00 - ESC[32minfoESC[39m: Matched 3 zeros 00098C50EEA4BA47BD01FC9646B05C6E5B950BC71EA9CEB2F994FD3547DFE26B with Nonce = 400000007396 for block#54605 by 48SLtT
Je n’ai pas trouvé une seule occurrence de chercher un bloc plus tard.
Le problème se réduit peut-être à la connexion IPC dans ton cas.
Voici un exemple simple, je t’invite à créer le fichier cluster-test.js dont le contenu est :
const cluster = require('cluster')
// The number of workers to spawn
const nbWorkers = 4
if (cluster.isMaster) {
console.log(`This is master process, spawning ${nbWorkers}`)
for (let i = 0; i < nbWorkers; i++) {
cluster.fork()
}
} else {
console.log(`This is worker ${process.pid}`)
process.on("SIGINT", () => {
console.log(`SIGINT received, closing worker ${process.pid}`)
process.exit(0)
})
require('./cluster-test')
}
Puis de l’exécuter et en fermant le programme à l’aide de Ctrl+C, voici ma sortie console :
cgeek@machine:~/dev/duniter$ node test/cluster-test.js
This is master process, spawning 4 workers
This is worker 27723
This is worker 27717
This is worker 27730
This is worker 27724
^CSIGINT received, closing worker 27717
SIGINT received, closing worker 27730
cgeek@machine:~/dev/duniter$ SIGINT received, closing worker 27724
SIGINT received, closing worker 27723
edit : tu peux essayer plusieurs choses dessus, en tuant par exemple un processus fils, ou bien le processus maître, puis en vérifiant si les processus existent toujours.
est-e que le retour de cette fonction /network/ws2p/heads est exhaustive, ou bien indique t’elle seulement les noeuds connectés au noeud interrogés ? Je n’ai pas bien compris.
Cela fonctionne comme tu me l’indiques, pas de processus ne reste. Je vois une différence avec ce qui se passe avec duniter. Quand je fais un kill sur un fils, il disparaît, alors que les processus lancés par duniter doivent être tués par un kill -9.
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.
PEER 48SLtTLL
PEER t5RR5eVe
