Test de synchro dans un TGV

Je suis actuellement dans un TGV à destination de Toulouse, j’ai démarré une synchro tout juste sorti de la gare à l’aide d’une connexion mobile.

Je pense être aux alentours de 200 km/h, je passe dans des tunnels, je vois des vaches et des éoliennes, et pour l’instant même si c’est très lent, ça synchronise (16%).

Malheureusement après 10 minutes d’essais infructueux, la synchro semble décrocher. Autant pendant 6-7 minutes je pouvais voir de multiples essais, autant là le logiciel n’essaie plus rien.

Voilà donc un test qui prouve que la synchro peut être améliorée !

edit : ceci dit, apparemment le réseau est dans les choux, ce qui n’arrange rien à la situation.

1 Like

Je confirme ! Depuis ce matin mon nœud essaie de rattraper les wagons, en vain…

le miens est complétement perdu ^^
il échoue pour passer sur une side chaine au bloc: 55426

warn: SWITCH: error Error: Wrong proof-of-work level: given 4 zeros and '1', required was 5 zeros and an hexa char between [0-9A-F]
   at Error (native)
   at /opt/duniter/sources/app/lib/rules/global_rules.js:83:13
   at next (native)
   at onFulfilled (/opt/duniter/sources/node_modules/co/index.js:65:19)

sakia me dit que mon noeud est sychro au block 55525
alors que si je fait un /blockchain/current sur mon noeud je suis au block : 55427

EDIT: apres restart de sakia, il me dit bien 55427

J’ai exactement le même soucis, cela tourne en boucle !

warn Blockchain changed!
info SWITCH: get side chain #55525-00000AC76B04732AF03D313B
SWITCH: revert main chain to block #55425
SWITCH: apply side chain #55525-00000AC76B04732AF03D313B
warn SWITCH: error Error: Wrong proof-of-work level: given 4 zeros and ‘1’, required was 5 zeros and an hexa char between [0-9A-F]
at Error (native)
at C:\Program Files\Duniter\sources\app\lib\rules\global_rules.js:83:13
at next ()
at onFulfilled (C:\Program Files\Duniter\sources\node_modules\co\index.js:65:19)
Block #55426 added to the blockchain in 34 ms

Je suis en train de produire un correctif : le code source présent en 0.5.1 aurait effectivement dû faire l’objet d’une 0.6.0, car il ne respecte pas le protocole 0.5.

Ajouter à cela un mauvais algo de résolution de fork, et vous obtenez un beau bazard :slight_smile: