Duniteroxyde (oxydation de Duniter)

Ça s’est mis à jour depuis sur le réseau :

 curl -s https://g1-test.duniter.org/network/peers | grep -B5 moul
      "last_try": null,
      "pubkey": "5B8iMAzq1dNmFe3ZxFTBQkqhq4fsztg1gZvxHXCk1XYH",
      "block": "561699-0002B2647C8269E91C3AF3214199AFF1C0C55D4C39CB44D943CFA695716D92DD",
      "signature": "KMX1H6rP9VkiIcQaPXcFAmLza0L3voy+r21VL/JAoBDp/XxXWmGP6GSlzykw9t8T9BPTCE22R4AWlqFenODFDg==",
      "endpoints": [
        "BASIC_MERKLED_API gt.moul.re 85.127.21.74 10902",
        "WS2P 2bbc5904 gt.moul.re 10903"

Mon nœud sur la branche feature/oxyde-pow reste difficilement synchronisé à cause de problème de point d’accès.
Je l’ai repassé sur la branche dev et ça reste bien synchronisé.
Je vois pas ce qui pourrait expliquer que ça se désynchronise, bien que le point d’accès WS2P ne soit pas atteignable. Peut-être que mon nœud trouve beaucoup plus vite les blocs, ne les partagent pas et reste isolé dans sur sa branche, puis théoriquement les autres nœuds ne communiquent plus avec lui.
Je vais voir ce qu’il faut faire pour avoir ce point d’accès atteignable, sinon je testerais feature/oxyde-pow sur mon nœud Ğ1.


Je n’ai pas réussi à m’y connecter avec un exemple DuniterPy. Surement qu’il faut que j’ouvre un port sur mon serveur. En fait c’est ça. J’ai plus l’habitude d’ouvrir les ports à cause de la couche d’abstraction de YunoHost (duniter_ynh qui ouvre le port dans un script). Mon port est ouvert, si tu veux tester. Bon, je vais retester du coup sur la branche feature/oxyde-pow.

1 Like

Même avec un endpoint WS2P valide j’observe moi aussi quelques désynchro plus fréquentes qu’avant, même si ça reste léger, je vois que @vit aussi s’est désynchro depuis qu’il a maj sur oxyde-pow.

peut-être, mais j’ai l’impression que ce n’est pas ça.

J’observe aussi un ralentissement de BMA qui persiste, mais hélas je ne sais pas du tout pourquoi, je n’ai pas touché au code de BMA, @cgeek une idée peut-être ?

J’ai pensé que cela venait du fuzzer de @matograine, mais j’ai reswitcher sur la branche dev et le ralentissement de BMA est bien plus faible, même après plusieurs heures. Et j’observe également un ralentissement de BMA sur mon nœud G1, plus léger que sur mon nœud gtest, donc il est certain que le fuzzer de @matograine à une part de responsabilité mais il n’explique pas tout.


Ok je pense que je vais changer de stratégie, la pow dépend d’autres process (code de génération du bloc donc mempool donc DAL et aussi code de validation d’un bloc utilisé en partie dans la génération) qui eux ne sont pas oxydés, ce qui semble causer des effets de bords bizarres (dé-synchros, ralentissements de BMA).

Je crois qu’il faut que j’oxyde en partant des briques les plus “basses” (celles qui ne dépendant pas des autres), puis que je remonte petit à petit en me basant à chaque fois sur les briques déjà précédemment oxydées.
L’oxydation de wotb et de la crypto est conforme à cette approche, ces briques ne dépendent pas de briques en nodejs.

Je vais laisser la pow de côté, le code Rust que j’ai écris pour n’est pas perdu, mais je l’intégrerai bien plus tard, quand il pourra être intégré en ne se basant que sur du code Rust, ce qui implique d’abord l’oxydation de la couche DAL, et du code de génération d’un bloc (qui dépend lui-même de nombreuses autres briques).
Je me rends compte en y réfléchissant que la pow est assez haute dans “l’arbre des dépendances entre les différentes briques”.
J’emploie ici le terme “brique” pour désigner un morceau de code, ce terme ne me convient pas trop, mais je n’ai pas trouvé mieux.

2 Likes

Vous avez des exemples d’URL précise ? Mon noeud g1.cgeek.fr est aussi avec PoW oxydée, et je ne ne vois pas de problèmes ces deux derniers jours. Après, c’est une bonne machine.

C’est comme tu le sens :slight_smile:

Je viens de tester l’endpoint BMA g1.cgeek.fr et perso j’observe bien un ralentissement. Un bon test est un test qui sollicite beaucoup BMA, par exemple la vue réseau de Cesium en mode expert :slight_smile:

Je suppose que le test consiste à positionner mon noeud comme celui à faire interroger par Cesium. Mais je ne vois pas trop de différence :roll_eyes:

Concernant le ralentissement de BMA observé, je fais juste des silkaj diffi ou des curl et je vois tout de suite qui c’est habituellement lent.

Peut-être que ces problèmes de BMA lent et de désynchronisation WS2P ont un dénominateur commun. Peut-être qu’une investigation du côté d’un composant réseau devrait en dire plus. Je dis ça je sais pas, c’est peut-être une piste à suivre.

Je ne sais pas quelle investigation ni comment, le commit d’oxydation de la pow ne modifie pas une virgule, ni du module bma, ni du module ws2p.
J’ai beau retourner la question, je n’ai aucune idée d’où peut bien venir l’impact. Peut-être que l’impact que l’on croit observer est dû a une cause externe, mais dans ce cas pourquoi ça semble se régler quand moul et moi rebuildons sur la branche dev ?
@cgeek tu ferais comment toi pour y voir clair dans tout ça ?

De toute façon là je vais être totalement indisponible pendant 2 à 3 jours, donc ça ne va pas bouger, ça vous laisse le temps d’investiguer si vous le souhaitez :slight_smile:

1 Like

Je ne sais pas quoi dire. Je ne ressens pas cette lenteur alors à moins d’avoir une méthode de mesure reproductible me permettant de dire « ah oui, effectivement c’est plus lent », je ne pourrais pas aider.

J’ai rapidement testé feature/oxyde sur la Ğ1 pour pouvoir tester à pleine puissance sans gêner la Ğ1-test et ainsi faire augmenter la difficulté, il se trouve que la PoW est mono-cœur.
J’ai tenté d’augmenter de quatre à huit cœurs, j’ai toujours un cœur qui bosse.
J’ai tenté d’augmenter de 80 à 320 % mais ça spawn plein de process de PoW avec un seul process à 100% avec des logs bizarres.
Avez-vous de la PoW multi-cœur sur cette branche ? Ai-je manqué quelque chose ?

Rien a voir avec le mode ECO ?

1 Like

Merci vincentux :+1: La preuve que tu suis. En effet, j’ai vu passer cette information.
J’avais directement enlevé cette configuration introduite par défaut sur mon nœud Ğ1-test. Il se trouve que j’ai oublié de changer cette valeur par défaut lors de son introduction sur mon nœud Ğ1.

C’est plutôt radical de passer tout le monde en mode économique sur un cœur tant qu’il a un bloc dans la fenêtre courante. Non ?
Je suis pour ne pas forcer ce changement d’habitude, je préfère que ça soit un choix volontaire de l’administrateur du nœud.
Si on se rend compte que beaucoup de monde passe en mode économique, alors, passons-le par défaut.

Ça risque d’introduire des changements importants sur la difficulté commune de la Ğ1.
Je comprends pourquoi ça a été introduit. La PoW Rust est plus efficace est fait augmentée la difficulté. La baisser avec un mode économique, contrecarre la chose. Mais, j’ai peur que ça chute pas mal.

De plus, ce paramètre entre en contradiction avec le paramètre sur le nombre de cœurs. Si je configure nbCores sur quatre, je m’attends à en avoir quatre, pas un. Sinon, il faut le renommer en max_nbCores.

Testé sur la Ğ1. Nœud désynchronisé avec quelques blocs de retards et un BMA devenu lent. Je switch sur dev.

1 Like
  1. Ouvrir la vue réseau de Cesium sur un noeud oxyde-pow lancé depuis plusieurs heures, constater le temps que ça prend.
  2. Ouvrir la même vue (sur la même monnaie) sur un noeud sans l’oxydation de la pow, constater le temps que ça prend.

Pour moi c’est sans équivoque, plus de 30s dans le cas 1 et moins de 5s dans le cas 2.

Je vais livrer la 1.8 sans l’oxydation de la pow, ce n’est pas mergeable en l’état.

1 Like

J’ai des erreurs qui peuvent peut-être aider sur la dernière release oxydée duniter-server-oxyde-pow-linux-x64.deb :

2020-05-18T11:09:09+02:00 - error: TypeError: Cannot read property 'issuersFrame' of null
    at Function.preparePersonalizedPoW (/opt/duniter/app/lib/indexer.js:970:50)
    at BlockchainContext.getIssuerPersonalizedDifficulty (/opt/duniter/app/lib/computation/BlockchainContext.js:83:23)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2020-05-18T11:09:09+02:00 - warn: Cannot read property 'issuersFrame' of null

2020-05-18T11:09:16+02:00 - error: TypeError: Cannot read property 'issuersFrame' of null
    at Function.preparePersonalizedPoW (/opt/duniter/app/lib/indexer.js:970:50)
    at BlockchainContext.getIssuerPersonalizedDifficulty (/opt/duniter/app/lib/computation/BlockchainContext.js:83:23)
    at process._tickCallback (internal/process/next_tick.js:68:7)
2020-05-18T11:09:16+02:00 - warn: Cannot read property 'issuersFrame' of null
2020-05-18T11:09:33+02:00 - info: Block #565265 added to the blockchain in 22723 ms
2020-05-18T11:09:35+02:00 - info: Block resolution: 0 potential blocks after current#565265...
2020-05-18T11:09:43+02:00 - info: Block resolution: 0 potential blocks after current#565265...
2020-05-18T11:09:48+02:00 - error: Unknown reference block of peer
2020-05-18T11:09:48+02:00 - error: Unknown reference block of peer
2020-05-18T11:09:52+02:00 - info: SIDE Block #565266-0007B450 added to the blockchain in 1101 ms

Elle me font décrocher depuis ce matin…

Bon la 1.8.0-beta est livrée, mais je n’ai pas trouvé le temps de rédiger le post d’annonce, et ce jeudi je suis pris par ailleurs, je créerai un sujet avec toutes les infos (et le cahier des tests) dès que je peux, vendredi j’espère.

Pour ceux qui veulent déjà tester, utilisez la version 1.8.0-beta2, elle contourne le fait que Cesium ne supporte pas les versions de Duniter avec un trait d’union.

Ceci-dit, je vous recommande d’attendre la rédaction du post dédié :slight_smile:

1 Like

@elois, je ne trouve pas le projet duniteroxyde sur le GitLab. Y a-t-il des restrictions d’accès ? Dans le groupe typescript je n’ai que module et duniter

Je pense que ce dépôt a été supprimé, car le code Rust relatif est à présent dans le dépôt du logiciel Duniter.

2 Likes
2 Likes

Merci !