d88fPFbDdJXJANHH7hedFMaRyGcnVZj9c5cDaE76LRN
(grmblbl faut que j’ouvre des ports en local) c’est bon, vous pouvez spammer. J’éteindrai le noeud ce soir.
5.51(POINT)176.238:10900
edit - Vous arrivez à changer la puissance du CPU ? Je fais :
duniter stop ; duniter --cpu 10 start
# ou
duniter stop ; duniter start --cpu 10
et j’ai dans mes logs (confirmé par htop) :
info: Generating proof-of-work [...] (CPU usage set to 100%) for block#545200 d88fPF
Quelle productivité, j’ai du mal à suivre (faut aussi que je jette un œil à celle sur le protocole v13).
J’essaye sur
ts.gt.elo.tf 443
Failed… J’essaierai de nouveau demain
Avec image Docker de test :
http://80.67.176.219:10901/node/summary
Par contre le WS2P public sur 20901… a pas l’air de fonctionner…
[Edit]
Ce matin, en plus des timeout sur les connexions, j’ai un timeout sur l’interface web… blanche !
close [app.js:3993:19](http://127.0.0.1:9330/app.js)
close { target: WebSocket, isTrusted: true, wasClean: true, code: 1001, reason: "", srcElement: WebSocket, currentTarget: WebSocket, eventPhase: 2, bubbles: false, cancelable: false, … }
[app.js:3994:19](http://127.0.0.1:9330/app.js)
Erreur dans les liens source : Error: request failed with status 404 URL de la ressource : http://127.0.0.1:9330/app.js URL du lien source : app.js.map
Cette page utilise la propriété non standard « zoom ». Envisagez d’utiliser calc() dans les valeurs des propriétés pertinentes ou utilisez « transform » avec « transform-origin: 0 0 ». [127.0.0.1:9330](http://127.0.0.1:9330/#/)
Configuring Angular app... [app.js:2452:13](http://127.0.0.1:9330/app.js)
App initialized. [app.js:2456:13](http://127.0.0.1:9330/app.js)
Erreur dans les liens source : Error: request failed with status 404 URL de la ressource : http://127.0.0.1:9330/app.js URL du lien source : app.js.map
null [app.js:3951:21](http://127.0.0.1:9330/app.js)
null [app.js:3190:15](http://127.0.0.1:9330/app.js)
Error: error is null module.exports/</<@http://127.0.0.1:9330/app.js:3191:28 $broadcast@http://127.0.0.1:9330/libraries.js:18420:28 transitionTo/$state.transition<@http://127.0.0.1:9330/libraries.js:34823:26 wrappedErrback@http://127.0.0.1:9330/libraries.js:17153:78 then/<@http://127.0.0.1:9330/libraries.js:17279:76 $eval@http://127.0.0.1:9330/libraries.js:18145:28 $digest@http://127.0.0.1:9330/libraries.js:17973:31 $evalAsync/<@http://127.0.0.1:9330/libraries.js:18184:26 completeOutstandingRequest@http://127.0.0.1:9330/libraries.js:10476:10 Browser/self.defer/timeoutId<@http://127.0.0.1:9330/libraries.js:10782:33 [libraries.js:15647:24](http://127.0.0.1:9330/libraries.js)
Erreur dans les liens source : Error: request failed with status 404 URL de la ressource : http://127.0.0.1:9330/libraries.js URL du lien source : libraries.js.map
J’ai alors installé htop et là, la révélation :
C’est normal tous ces process ?
Tu as 8 cœurs sur cette machine donc la PoW crée au moins autant de processus (ceux nommés powCluster.js) afin de paralléliser.
Ce serait intéressant que tu stoppes Duniter et voies si certains processus restent.
Ok, merci c’est bon, les processus s’arrêtent bien.
Je le relance car il calcule sagement des blocs !
Reste à résoudre les timeouts des connexions.
2020-04-07T17:30:18+00:00 - info: WS2P HAy1hLpHfqrG3xsZRoBVkNigGQZnDfJK2az5MeRYtyNb: new incoming connection from 91.121.137.30:33576!
2020-04-07T17:30:33+00:00 - warn: WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout
On dirait que je suis joignable de l’extérieur, mais que je ne peux pas répondre (le container docker ?).
Pour les connexions avec l’extérieur, y a un truc qui coince. J’ai forwardé les ports sur la box, mais mon noeud est vu comme privé alors que je suis bon en local (accès ws2p par duniterpy et BMA par le navigateur…).
Bon, j’ai basculé sur le paquet debian, pas assez calé sur Docker.
J’ai enfin des connections entrantes qui fonctionnent.
Par contre, en webstart, l’interface admin reste blanche avec un timeout (je suis en tunnel ssh sur le port 9330, mais c’est pareil sur le serveur lui même en 9220…) :
Cette page utilise la propriété non standard « zoom ». Envisagez d’utiliser calc() dans les valeurs des propriétés pertinentes ou utilisez « transform » avec « transform-origin: 0 0 ». [127.0.0.1:9330](http://127.0.0.1:9330/#/)
Configuring Angular app... [app.js:2452:13](http://127.0.0.1:9330/app.js)
App initialized. [app.js:2456:13](http://127.0.0.1:9330/app.js)
Erreur dans les liens source : Error: request failed with status 404 URL de la ressource : http://127.0.0.1:9330/app.js URL du lien source : app.js.map
null [app.js:3951:21](http://127.0.0.1:9330/app.js)
null [app.js:3190:15](http://127.0.0.1:9330/app.js)
Error: error is null module.exports/</<@http://127.0.0.1:9330/app.js:3191:28 $broadcast@http://127.0.0.1:9330/libraries.js:18420:28 transitionTo/$state.transition<@http://127.0.0.1:9330/libraries.js:34823:26 wrappedErrback@http://127.0.0.1:9330/libraries.js:17153:78 then/<@http://127.0.0.1:9330/libraries.js:17279:76 $eval@http://127.0.0.1:9330/libraries.js:18145:28 $digest@http://127.0.0.1:9330/libraries.js:17973:31 $evalAsync/<@http://127.0.0.1:9330/libraries.js:18184:26 completeOutstandingRequest@http://127.0.0.1:9330/libraries.js:10476:10 Browser/self.defer/timeoutId<@http://127.0.0.1:9330/libraries.js:10782:33 [libraries.js:15647:24](http://127.0.0.1:9330/libraries.js)
Erreur dans les liens source : Error: request failed with status 404 URL de la ressource : http://127.0.0.1:9330/libraries.js URL du lien source : libraries.js.mapHa c’est bizarre perso j’ai toutes les api réseau qui marchent dans docker, mais j’ai eu besoin de faire écouter Duniter sur 0.0.0.0, c’est peut être ça qu’il te manque 
Oui j’ai le même problème assez souvent (mais pas systématiquement), y compris en 1.7.21. C’est un problème avec duniter-ui, pas avec duniter en lui-même, donc ce n’est pas lié a l’oxydation.
@cgeek j’aimerais bien merger la branche feature/oxyde-crypto pour pouvoir avancer, a tu eu le temps de jeter un œil ?
Je regarde demain, j’ai pris du temps sur g1-monit mais c’est presque terminé.
Aussi j’avais déjà jeté un rapide coup d’œil donc ça devrait aller.
C’est tout bon, et agréable à relire.
J’essaierai de creuser le code Rust quand même d’ici la prochaine fois.
Une question aussi : tu comptes conserver la fonction scrypt de NodeJS ou bien tu la remplaceras aussi ?
Enfin : tu pars sur quoi ensuite que je me prépare un peu ? 
On peut se faire un atelier “Duniteroxyde” lors des rml15 pour que j’explique aux intéressés comment c’est structuré et comment ça marche
Pour l’instant je la conserve car c’est du code en NodeJs qui gère la génération du trousseau. Selon jusqu’où on ira dans l’oxydation, si a un moment c’est du code Rust qui gère la génération du trousseau alors la fonction scrypt sera en Rust.
La je suis en train de réécrire la gestion de la PoW en Rust. Ça va permettre d’éviter le problème des processus PowCluster qui se multiplient a l’infini quand on ne reboot pas, et puis ce sera plus efficient, Rust est fait pour le calcul concurrent.
Si un jour on est attaqué, l’attaquant choisira une implémentation la plus efficiente pour la Pow, donc faire de même nous permet de mieux sécuriser la monnaie.
Aussi ça me permettra d’introduire des changements dans la formule du handicap ainsi que le fameux bonus aléatoire dont on parle depuis longtemps, bon selon mon avancement ce sera peut-être que pour DUBPv14, on verra
Ça fait plaisir de voir les énergies se rejoindre autour d’un cyborg TypeScript/Rust !
Ça me motive cette synergie
Malheureusement, finaliser Dunitrust allait durer encore un bon moment.
Cette approche a l’avantage d’y aller par étapes progressives.
Élois, peux-tu apposer une licence libre au dépôt Duniteroxyde. Sinon, c’est insérer du code propriétaire dans Duniter.
J’ai review vite fait les commits dans Duniter et me suis mis à tester. Eh bien, je suis bleuffé !!!
Ça s’installe très simplement sous Fedora. Installation de nodejs v10 avec dnf module qui permet d’avoir la version majeure de Node.js de son choix. Puis, installation des paquets Rust en dernière version, puis yarn et c’est parti.
Concernant la signature des blocs, c’est vachement plus rapide ! Sur la Ğ1, mon nœud trouve quasiment immédiatement un bloc après être libéré de l’exclusion. J’ai pas encore bien compris le comportement vis-à-vis de la configuration CPU. Ça semble être inférieur à la valeur de configuration, puis ça augmente progressivement ? Mais je ne le vois pas étant donné que mon nœud trouve assez rapidement. Sur la Ğ1-test, ça explose, j’ai réduit par deux la puissance (un cœur, 5 %).
J’imagine qu’une fois ces changements en production sur tous les nœuds Ğ1, powMin va augmenter.
Concernant l’utilisation de module WoT en rust, ça fonctionnait immédiatement. J’ai quand même fais une nouvelle synchronisation, car j’avais quelques erreurs (je dirais mineures) dans les logs. Comment se fait-il que ça fonctionne de passer de wotb à wot-rs ? Ça lit le même fichier de bdd ? Y a-t-il une migration ?
100 % d’accord ! Bravo @elois pour ce choix plein de bon sens.
Et que penses tu te travailler sur la BDD aussi ? Niveau perf (en tous cas via BMA : /wot/requirements /tx/sources) ce serait très agréable !
Je sais que GVA remplacera BMA, mais ca permettrait de tenir un peu, et éviterai aussi que les clients soient obligé de rusé (et perdre du temps en dev) pour se concentrer sur GVA eux aussi.
En plus, si la couche de persistance est efficiente, elle pourrait à la fois servir BMA et GVA sans avoir 2 BDD distinctes. Bon la je sais pas.
Autre piste: travailler sur GVA, justement ? Pourquoi pas après tout avoir un module GVA dans Duniter. Ca motiverai aussi les clients à basculer dessus plus vite. non ?
Bon, te connaissant @elois tu va vouloir etre sur le coeur… mais s’il vous plait de délaissé pas les API clients : c’est pas elle que les utilisateurs peuvent avoir une bonne/mauvaise première impression de la G1.
Bon courage à tous !
Oups je pensais l’avoir fait, c’est un oubli merci @Moul
Oui j’ai lu le code C++ de wotb pour connaître le format du fichier wot.bin et j’ai écrit un code de migration ici : Sign in · GitLab
La BDD c’est un gros morceaux, j’y est déjà pensé et probablement que je finirai par le faire oui car ça accélérerai plain de choses: la sync, les APIs, etc
Concernant les APIs justement, et notamment GVA, il me faudrait d’abord oxyder la BDD justement, donc ce ne sera pas pour tout de suite.
J’ai testé la synchro locale dans Duniter (donc sans activité réseau) et ça reste beaucoup trop lent a mon goût même sur SSD pci-express.
C’est peut-être un problème de configuration de LevelDB alors, un manque du tunning quoi. Notamment, il faudrait voir si LevelDB possède un mode NO_SYNC ou équivalent permettant de ne pas écrire les changements sur le disque avant la fin de la sync, cela consomme plus de RAM pendant la sync mais la rend infiniment plus rapide, c’est grâce a ce tunning dans LMDB que j’arrivais a sync en moins d’une minute dans Dunitrust.
Je viens de relever une différence entre Duniter 1.7.21 et la version oxydée sur la G1 (je fais tourner mon noeud dans cette version pour tester, une alerte m’a indiqué que le noeud était bloqué).
Pour reproduire :
duniter sync g1.duniter.org --nointeractive 317505
Résultat :
Je ne sais pas encore quelle version a raison, ni l’origine précise de ce delta.
Tu arrive après la bataille, @Moul et moi avons repéré le problème ce matin, je viens de passer la journée dessus et j’ai trouvé, c’est un delta dans la façon de faire les arrondis, la faute a pas de chance, d’après ma sync cautious c’est le seul cas de toute l’histoire de la G1, détails ici : Duniter wotb : problème d'arrondi
Oui désolé je bosse encore malgré le Covid, donc je donne les infos quand je peux !
L’architecture sur laquelle je suis parti est trop complexe et pas pratique du tout pour développer efficacement, il faut manipuler 3 dépôts en même temps, si même moi je galère ça va être encore plus difficile d’intégrer d’autres contributeurs.
Sachant que je projette d’intégrer d’autres contributeurs à l’oxydation de Duniter le moment venu, il faut que je simplifie l’architecture.
C’est pourquoi j’ai décidé de supprimer le dépôt Duniteroxyde et d’intégrer son contenu directement dans le dépôt de Duniter sous le dossier neon. Ce dépôt ne contenait que le code de binding permettant a Duniter d’utiliser du code Rust, ce binding étant spécifique pour Duniter (il reprend l’API des composants C++/NodeJS remplacés) cela fait sens d’intégrer ce code directement dans Duniter.
J’ai dans ma todo list de faire de la doc qui présente l’architecture de Duniter « oxydé » d’ici les rml15, mais j’attends que l’architecture se stabilise avant de rédiger ça.
Je pense même qu’il serait pertinent de faire carrément une conf pendant les rml15 pour présenter la nouvelle architecture de Duniter et comment fonctionne l’oxydation, je pourrais remplacer cette conf par celle de Dunitrust (ou les fusionner) car je me concentre désormais exclusivement sur Duniter et que le but est que le code existant dans Dunitrust rentre dans Duniter.
Patience donc, d’ici les rml15 vous y verrez plus clair (et moi aussi 
).
J’ai testé la branche feature/oxyde-pow et j’observe des lenteurs de réponse de la part de BMA. Je vois pas en quoi c’est lié aux changements sur la PoW. Tu reproduis ?