G1-test dans les choux ? État monnaie

En fait pour l’instant tout est normal ta branche a 2 blocs d’avance sur nous, il faut qu’une branche est plus de 3 blocs et plus de 15 min d’avance pour être sélectionner, une des deux branche finira par l’emportée :wink:

EDIT : d’ailleurs @nanocryk c’est fait, ton noeud s’est recalé sur notre branche :wink:

Non j’ai fait un reset data et sync.

:laughing:

Oui; esprit fonctionne sur win…

2 Likes

Je viens de relancer mon noeud Ğ1-test en version 1.6.25 et je n’arrive pas à calculer de bloc.

J’ai ce message à répétition :

2018-07-07T10:57:18+02:00 - error:  Error: ruleIssuerIsMember
    at Function.checkBlock (/mnt/data/Logiciels/duniter-desktop-v1.6.25-linux-x64/app/lib/blockchain/DuniterBlockchain.js:65:19)
    at <anonymous>

J’ai relancé Duniter et maintenant il squatte tout mon cpu (malgré un réglage à 25%) avec ces messages :

 trace: PoW loops = 10443
2018-07-07T11:13:14+02:00 - debug: Key 9WyhF5Er9YzuZ1Vj6UuPFa5dch2wXq7dYPWbZpLbXcqu does not have enough links (0/5)
2018-07-07T11:13:14+02:00 - debug: Key 4GEWgeH52BQKBuYV4h9CXjYDtY46qnTjcanqxr4CJDHT does not have enough links (0/5)
2018-07-07T11:13:14+02:00 - info: Generating proof-of-work with 0 leading zeros followed by [0-9A-F]... (CPU usage set to 26%) for block#204943 DpJse2
2018-07-07T11:13:14+02:00 - info: ENGINE c#0#0 HAS FOUND A PROOF #7775F6DBE9D877CEB867BEBFAD933C926D75CCDC5A68ECE3FC72EA6BBC0F9137
2018-07-07T11:13:14+02:00 - info: [done] worker c#0#w#0
2018-07-07T11:13:14+02:00 - info: [done] worker c#0#w#3
2018-07-07T11:13:14+02:00 - info: [done] worker c#0#w#2
2018-07-07T11:13:14+02:00 - info: [done] worker c#0#w#1
2018-07-07T11:13:14+02:00 - info: ENGINE c#0#0 HAS FOUND A PROOF #7775F6DBE9D877CEB867BEBFAD933C926D75CCDC5A68ECE3FC72EA6BBC0F9137
2018-07-07T11:13:14+02:00 - info: Done: #204943, 7775F6DBE9D877CEB867BEBFAD933C926D75CCDC5A68ECE3FC72EA6BBC0F9137 in 0.01s (~0 tests, ~0.00 tests/s, using 4 cores, CPU 26%)
2018-07-07T11:13:14+02:00 - info: FOUND proof-of-work with 0 leading zeros followed by [0-9A-F]!
^C2018-07-07T11:13:14+02:00 - warn: Proof-of-work self-submission: Block already known
2018-07-07T11:13:14+02:00 - trace: PoW loops = 10444

Seul @jytou calcule des blocs on dirait !

Bon, un “reset data et start sync” et c’est reparti comme en 40 !

1 Like

Cette fois, la situation est la suivante :

  • Le réseau est bloqué au bloc 210409 depuis le 11/07/2018.
  • Les piscines sont saturées de transactions. C’est le cas sur mon nœud et celui de duniter.org :
    https://g1-test.duniter.org/node/sandboxes
  • Je suis celui qui a calculé le dernier bloc consensuel 210409, mon nœud essai de calculer le suivant 210410… mais il signale des erreurs dans la piscine (double dépense, trop de transactions pour un bloc,…)
  • MeluaTest (ws2p privé) est seul avec une branche plus longue (211 965).

Problème de fiche de pair qui m’empêche d’être accessible en ws2p publique :

  • Mon IP a changé, mais ma fiche de pair ne change pas. Je suis donc inaccessible…

  • Les logs signalent que l’ancienne IP est inaccessible. Normal.

    2018-07-14T00:26:05+02:00 - warn: Wrong endpoint 'BASIC_MERKLED_API 90.62.24.107 61492'
    2018-07-14T00:26:05+02:00 - warn: Wrong endpoint 'WS2P 04e6a83f 90.62.24.107 20900'
    

Pour relancer le réseau, je pense qu’il faudrait pouvoir repartir sur la branche de @Melua (noeud MeluaTest). Mais il n’est pas accessible non plus :

2018-07-14T00:34:28+02:00 - info: WS2P: Could not connect to peer droYn565 using `WS2P gtest.melua.fr 20900: WS2P connection timeout`

@Melua : peux-tu vérifier ta configuration et rendre ton nœud accessible ?

Comme nous sommes très peu de nœuds calculant, il est important que nous soyons le plus possible accessibles en ws2p publique (même en période de vacances :wink: ).

1 Like

Pourtant mon noeud test est bien en WS2P public et privé… j’ai simplement BMA de désactivé. Il y a actuellement 5 noeuds connectés à moi (INCOMING) sur les 25 autorisés.

Dans ma fiche de pairs, je ne vois qu’un endpoint. Inaccessible pour un re-sync…

“WS2P 3d706f93 gtest.melua.fr 20900 /ws2p”

Peux-tu te connecter sur le tchat si tu as un peu de temps pour que tu puisses me donner ce que tu as dans ta fiche de pair.

Oui c’est normal, seul les endpoint BMA permettent de resync actuellement, cela changera pour Duniter 1.7.

Mon noeud essaie de rattraper la branche de @Melua, mais ne trouve pas de bloc racine commun (je crois que Duniter cherche un bloc commun sur une fenêtre de N blocs, là nous avons dépassé N).

Donc la situation est bloquée puisque le réseau ne peut pas de lui même se repiquer sur la branche de Melua.

Il faut faire un “reset data and sync” sur le noeud de Melua dès qu’il aura activé son endpoint BMA !

A toi de jouer @Melua !

Si je suis en forme, ce sera possible ce week-end sur ĞTest.

Je viens d’activer BMA sur mon noeud GT.

1 Like

Peux-tu me donner les infos du endpoint BMA, ip port (BMAS ou BMA).

Parce que les pairs ne se propagent plus aux noeuds j’ai l’impression…

http://gtest.melua.fr:10900/

1 Like

Merci ! Synchronisation réussie !

@cgeek, @elois, @aguy, @jytou et tous les noeuds calculant peuvent se synchroniser sur mon noeud :

BASIC_MERKLED_API 90.62.13.161 61492 (attention IP dynamique dont dépêchez-vous :wink:)

ou celui de @Melua :

http://gtest.melua.fr:10900/

D’avance, merci à tous !

1 Like

J’aurais donc peut-être pété Ğ1Test ? J’ai arrêté mon générateur de transactions en attendant que tout cela se stabilise un peu.

Je ne sais pas…

D’après Cesium, nous étions 4 (elois, jytou, aguy et moi) à calculer tranquillement des blocs jusqu’au 11/07 vers 16h…

Mon noeud est intermittent…

La, blocage sur la génération du bloc 210410… Melua a pris de l’avance seul jusqu’à 212xxx…

Faudra analyser ça tranquillement…

Je suis de nouveau synchro avec @Melua, le serveur g1-test.duniter.org également.

edit : par contre ça fait bien 10 minutes et pas le moindre nouveau bloc en vue :confused:

J’ai rien dit !

1 Like

Le réseau est reparti. Mais il a fallut une intervention humaine manuelle.

@jytou, je pense qu’il faut peut-être s’organiser un peu pour les stress tests.

Propositions :

  • Un contributeur lance un stress test à une date et une heure précise et prévient les autres contributeurs sur le forum. Le but étant d’observer ensemble le réseau et d’analyser les problèmes qui apparaissent.
  • Un contributeur lance un stress test pour ses propres analyses. Sans prévenir personne. En ce cas, il a la responsabilité d’observer le réseau et de stopper son stress test au moindre problème. Si le problème persiste, il avertit les autres contributeurs immédiatement sur le tchat ou sur le forum.

Ainsi, cela évitera un effondrement et un blocage de 2 jours du réseau, sans que personne ne s’en rende compte.

Bon maintenant vous pouvez retourner barboter dans l’eau avec votre bouée canard. :grin: