Oui. Pour l’instant BMA réponds normalement. Je vais voir sur plus long terme.
Ce choix me convient.
Port ouvert et configuration WS2P mise en place :
"WS2P 2bbc5904 gt.moul.re 10903"
J’ai pas testé avec un client WS, mais je sens que mon nœud est plus connecté au réseau en regardant à l’intérieur du câble.
C’est une bonne idée pour les distinguer dans un htop.
Ne répond pas non plus mais sur ta fiche de peer c’est : WS2P 2bbc5904 gt.moul.re 443
Je n’ai pas du tout creusé ce sujet, mais tu sais peut-être : peut-on déboguer à la fois le TypeScript et le Rust en même temps ? Je veux dire, au sein de la même exécution.
Déboguer le TypeScript je le fais déjà, mais dès qu’on bind sur du C/C++ il y a une cloison que je n’ai jamais franchi. Est-ce possible pour le Rust ?
Autrement dit : peux-tu déboguer du code oxydé ?
Tu ne dois surtout pas hésiter, à aucun moment. Les tests sont là pour ça.
Et de toute façon ce code a vocation à être réécrit en Rust. Donc autant que tu le maîtrises.
Hélas non, en cas de besoin, voici comment je procède :
Avec le déboguer Typescript, je note les données envoyées a la partie Rust en entrée.
Je lance la partie Rust avec ces données manuellement (dans un TU Rust) pour tenter de reproduire l’anomalie.
Mais dans la pratique c’est vraiment très très très rare que j’ai besoin de déboguer du Rust, ça ne m’arrivait presque jamais dans Dunitrust, et je n’ai encore jamais ressenti le besoin de le faire dans l’oxydation de Duniter jusqu’à présent.
Grâce au typage fort, a l’explicitation des effets de bords et aux très nombreux contrôles a la compilation, Rust est un langage que l’on a beaucoup moins besoin de déboguer que les autres, on pourrait même s’en passer. Ce qui est clairement impensable en NodeJS, j’ai abusé du débogueur pour mon refactoring, et sans lui j’y serais encore, donc je comprends que quand on vient du NodeJS on considère le débogueur comme indispensable 
Oui le typage fort présente cet avantage, j’ai remarqué aussi que je déboguais beaucoup moins souvent avec TypeScript que JavaScript.
Le débogueur n’est jamais indispensable. C’est juste que, d’expérience, j’ai remarqué que c’était la méthode la plus efficace quand un problème non trivial se présentait.
Concernant Duniter oxydé, plus l’oxydation sera poussée et plus tu ressentiras le besoin de l’avoir à disposition à mon avis. Et ce mon venu – s’il advient – le fait que TypeScript soit le point d’entrée deviendra gênant. Ce qui pourrait être intéressant alors ce serait de pouvoir faire l’inverse : avoir des modules Rust en TypeScript (le temps de leur oxydation). Je ne sais pas si c’est possible !
@Moul après vérification plus poussée je pense que tu t’es trompé, ça ne cherche pas avec une difficulté plus élevée qu’avant, le comportement est toujours le même et est conforme à l’attendu :
Un pattern de 7 zéros suivi par [0-5] correspond à une difficulté de 122, or 64 + 64 >= 122 donc il est normal que ton nœud essaye de calculer le bloc. La formule n’a pas changé elle est ici, le nœud s’exclura du calcul si et seulement si :
selfDifficulty > current.powMin + this.conf.powMaxHandicap
J’ai vérifié en debug et en rajoutant des logs, et je suis formel, il est totalement normal que ton nœud G1-test tente de calculer avec une difficulté de 122 
Je viens de mettre à jour mon nœud.
J’ai baissé le cpu à 30%, on verra si c’est assez bas.
En effet, j’ai rapidement mis le calcul sur la table sans approfondir.
Tu as raison, j’étais étonné de voir que nos nœuds Ğ1-test cherchaient des blocs à six et sept zéros.
Ça se produisait bien avant l’oxydation. Juste que j’avais pas le nez dans les logs.
Pour preuve, je trouve beaucoup d’occurrences avec :
grep -rn "Generating proof-of-work with 7 leading" ~/.config/duniter/duniter_default/duniter{,1,2}.log
En tout cas, ça n’a pas lieu sur la Ğ1 étant donné que la difficulté commune est plus élevée.
Qu’est-ce que devient le projet Dunitrust depuis que tu as switché sur le projet Duniter ?
Tu mets le projet Dunitrust sur pause ? Et quid des autres contributeurs à Dunitrust ?
Alors je l’ai déjà sous-entendu sur d’autres fils de ce forum mais il n’y a en effet pas eu d’annonce “officielle”, en revanche les contributeurs actifs de Dunitrust sont déjà au courant :
Du fait que je reprends la main sur Duniter et que je le migre en Rust, Dunitrust n’a plus de raison d’être. La majeure partie de code de Dunitrust va être intégré dans Duniter, c’est un peu comme si les 2 projets fusionnaient.
Là ma priorité c’est de préparer le terrain pour que les contributeurs de Dunitrust puissent me rejoindre sur l’oxydation de Duniter, la plupart m’ont déjà confirmé être ok pour ça, en attendant que je sois prêt a les embarquer dans l’oxydation de Duniter ils profitent d’une pause bien méritée
Ç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.
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.
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
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
Je suppose que le test consiste à positionner mon noeud comme celui à faire interroger par Cesium. Mais je ne vois pas trop de différence 
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
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 ?