Syncho non finie

Support
1

Je ne comprends pas pourquoi, mon noeud a une difficulté personnalisée de 1936 alors qu’il ne calcule pas.
Que se passe-t-il?
Pour info, je suis revenue à la 1.6.21 parce que la 1.6.22 avait des problèmes.

Ceci est sous debian mais j’ai abandonné mon noeud GTest sous win (8.1) car, même avec la 1.6.22, je ne peux plus rien faire…

Voici l’extrait de log concerné:

2018-03-19T13:16:34+01:00 info Matched 3 zeros 000E251B3EE9FA36A80EBFA2CD727043CA5D11E192760D0F16E9D3B0BD923263 with Nonce = 10100000033372 for block#103917 by FVUFRr

2018-03-19T13:16:38+01:00 info Matched 3 zeros 0001210B72521C0BB99D544793B6A1AA58782251F5597D2E3BDB85E214C4C875 with Nonce = 10200000034501 for block#103917 by FVUFRr

2018-03-19T13:16:47+01:00 info Matched 3 zeros 0001D4C5486644EEEFA33BEED6300A66179ABE3C3F0082335602D15DEA9F7B4D with Nonce = 10300000035835 for block#103917 by FVUFRr

2018-03-19T13:16:47+01:00 info Matched 3 zeros 00038F4A1ADD103B74A31D6D38BDB6515D616686C449977F98B616D80CFDC97D with Nonce = 10400000035345 for block#103917 by FVUFRr

2018-03-19T13:16:48+01:00 info ENGINE c#0#0 HAS FOUND A PROOF #00000091C17783A03DEA2899D92015585795156B21EA247795C3C219E68A72FF

2018-03-19T13:16:48+01:00 info [done] worker c#0#w#0

2018-03-19T13:16:48+01:00 info [done] worker c#0#w#1

2018-03-19T13:16:48+01:00 info [done] worker c#0#w#2

2018-03-19T13:16:49+01:00 info [done] worker c#0#w#3

2018-03-19T13:16:49+01:00 info ENGINE c#0#0 HAS FOUND A PROOF #00000091C17783A03DEA2899D92015585795156B21EA247795C3C219E68A72FF

2018-03-19T13:16:49+01:00 info Matched 6 zeros 00000091C17783A03DEA2899D92015585795156B21EA247795C3C219E68A72FF with Nonce = 10100000035670 for block#103917 by FVUFRr

2018-03-19T13:16:49+01:00 info Done: #103917, 00000091C17783A03DEA2899D92015585795156B21EA247795C3C219E68A72FF in 230.57s (~142676 tests, ~618.80 tests/s, using 4 cores, CPU 60%)

2018-03-19T13:16:49+01:00 info FOUND proof-of-work with 5 leading zeros followed by [0-7]!

2018-03-19T13:16:49+01:00 info SIDE Block #103917-00000091 added to the blockchain in 305 ms

2018-03-19T13:16:49+01:00 info Block resolution: 1 potential blocks after current#103916...

2018-03-19T13:16:49+01:00 info Block #103917 added to the blockchain in 483 ms

2018-03-19T13:16:49+01:00 trace PoW loops = 2

2018-03-19T13:16:50+01:00 info Block resolution: 0 potential blocks after current#103917...

2018-03-19T13:16:50+01:00 debug Trial = 1936, powMin = 88, pubkey = FVUFRr

2018-03-19T13:16:50+01:00 warn Too high difficulty: waiting for other members to write next block

2018-03-19T13:17:58+01:00 trace WS2P: mapping external port 20900 to local 192.168.0.31:20900 using UPnP...

2018-03-19T13:17:58+01:00 warn 

2018-03-19T13:22:58+01:00 info Sibling endpoints:

2018-03-19T13:22:58+01:00 debug Generating server's peering entry based on block#103887...

2018-03-19T13:22:58+01:00 error Peer with zero endpoints that is not already known

2018-03-19T13:22:58+01:00 info Next peering signal in 10 min

2018-03-19T13:22:58+01:00 trace WS2P: mapping external port 20900 to local 192.168.0.31:20900 using UPnP...

2018-03-19T13:22:58+01:00 warn 

2018-03-19T13:22:58+01:00 info Block resolution: 0 potential blocks after current#103917...

2018-03-19T13:22:58+01:00 info Block resolution: 0 potential blocks after current#103917...

2018-03-19T13:26:50+01:00 warn Security trigger: proof-of-work process seems stuck

2018-03-19T13:26:50+01:00 trace PoW loops = 3

2018-03-19T13:26:50+01:00 debug Trial = 1936, powMin = 88, pubkey = FVUFRr

2018-03-19T13:26:50+01:00 warn Too high difficulty: waiting for other members to write next block

2018-03-19T13:27:58+01:00 trace WS2P: mapping external port 20900 to local 192.168.0.31:20900 using UPnP...

2018-03-19T13:27:58+01:00 warn 

2018-03-19T13:32:58+01:00 info Sibling endpoints:

2018-03-19T13:32:58+01:00 debug Generating server's peering entry based on block#103887...

2018-03-19T13:32:58+01:00 error Peer with zero endpoints that is not already known

2018-03-19T13:32:58+01:00 info Next peering signal in 10 min

2018-03-19T13:32:58+01:00 trace WS2P: mapping external port 20900 to local 192.168.0.31:20900 using UPnP...

2018-03-19T13:32:58+01:00 warn 

2018-03-19T13:32:58+01:00 info Block resolution: 0 potential blocks after current#103917...

2018-03-19T13:32:58+01:00 info Block resolution: 0 potential blocks after current#103917...

2018-03-19T13:36:50+01:00 warn Security trigger: proof-of-work process seems stuck

2018-03-19T13:36:50+01:00 trace PoW loops = 4

2018-03-19T13:36:50+01:00 debug Trial = 1936, powMin = 88, pubkey = FVUFRr

2018-03-19T13:36:50+01:00 warn Too high difficulty: waiting for other members to write next block

2018-03-19T13:37:58+01:00 trace WS2P: mapping external port 20900 to local 192.168.0.31:20900 using UPnP...
2

@mamygeek ce n’est pas la pow qui est en faute mais ton noeud qui est désynchronisé, il est au 103917 alors qu’on en est au 104100…

Et du coup de son point de vue tu viens de calculer un bloc donc tu est dans le fenetre d’exclusion , ce qui est tout a fait juste, il faut que tu reset data et que tu resync :wink:

3

merci @elois. Cependant, avec quel noeud je synchronise? Je l’ai fait avec celui par défaut sans succès.

4

ben celui que tu veut regarde dans la vue réseau cesium les noeuds qui sont bien synchronisés et choisi en un :slight_smile:

5

C’est au tour de WotWizard d’avoir été désynchronisé, tout comme @MickaelLarose il y a quelques jours.

Or WotWizard est très bien loti en termes de connexions et reçoit systématiquement tous les blocs. Cela me met donc la puce à l’oreille, et un simple redémarrage lui a permis de rejoindre la branche principale.

Il y a bug sous résolution de fork comme dirait l’autre. Ticket #1299 créé.

2 Likes
6

Tu veut dire qu’il y a baleine sous gravillons ? :laughing:

2 Likes
7

Mes nœuds allumés temporairement ne voulaient pas redémarrer.
J’ai tenté à plusieurs reprises pour qu’ils démarrent.

8

Après la nouvelle synchro, j’ai fermer et relancer et voici mes logs. il semblerait qu’il y ait une anomalie… à vous de voir…

https://framadrop.org/r/Iwogmio9jh#NPlXI4z6a6rqQAr2KFCgm04IEBQN+IUNKtio5n+m2tM=

9

@mamygeek stp pour le partage de log passe plutot par framabin.org plus adapté aux textes, merci :slight_smile:

10

OK. Voila: https://framabin.org/?1981a8d37379ff1c#zkdhsdVI42FeNI0SbSmZgKKP/rSMVLxrCcFOUdFD1XQ=

11

heu… quelle anomalie ? A vu d’œil la je ne vois rien d’anormal !

12

Merci Elois. C’est bon, c’est reparti :slight_smile:

13

J’ai un début d’explication : en cas de fork peu avant un bloc à DU, la résolution de fork peut devenir particulièrement longue car il faut alors dépiler le bloc à DU qui contient actuellement plus de 830 sources de monnaie à mettre à jour. Or l’algorithme qui mémorise la valeur courante du compte (pour le nettoyage des comptes inférieurs à 1Ğ1) dans ce cas n’est vraiment pas terrible.

Je suis en train de l’optimiser, mais voilà un bon coupable à la désynchronisation régulière subie par quelques-uns.

edit : Ce qui nous donne déjà une idée de limite à Duniter dans sa version actuelle : à 832 variations de comptes par bloc, ça commence à coincer pour les plus petites configurations.

2 Likes