Reprise du message précédent :

 
solution retenue

Un souhait plus qu'une requête: le support (sans --any) du Arqma (ARQ):
 
https://arqma.com/
https://bitcointalk.org/index.php?topic=4474605.0

c'est du cryptolight v7 comme turtle ?
ok, pour la version gpu

Oui, Cryptolight v7 soit --variation 4.
 
Même si SRB fonctionne bien, je trépigne dans l'attente ta version GPU

On est vraiment rendu à miner des trucs avec 15% de premine ?

Je teste fréquemment de nouvelles (shit)coins en les minant pendant 24 à 48h et constatant le gain ainsi réalisé au cours actuel, plutôt que d'extrapoler à partir des informations publiées ici et là dont je ne connais pas forcément l'impact exact sur la rentabilité.
Ca revient certes à perdre potentiellement deux jours de minage mais ça permet d'être fixé avec certitude sur ce que cette shitcoin peut rapporter.

J'espère ne pas décevoir tes trépignements.
Je suis en train de sur-booster mon code, je monte ma rx560 à 530 h/s en v7. Ça ne veut rien dire (bien que ce soit un gros score dans l'absolu) mais avec stak je ne la pousse pas au delà de ~915
 

 
972... sur ces deux cartes (une rx560 avec de la bonne ram, et une avec de la très mauvaise) stak ne m'amenait pas au delà de 935

Version GPU dispo.
Pas encore de ARQMA désolé pas eu le temps
 
https://github.com/jceminer/cn_gpu_miner

Je suis en train de tester la 0.30, ou tout du moins d'essayer parce que je butte sur la config des GPU.
 
La ligne de commande qui lance le programme commence par "jce_cn_gpu_miner64.exe -c configCN_87C.txt"
 
Le fichier configCN_87C.txt contient, au-delà de la config du CPU!
 
"gpu_threads_conf" :  
[  
     { "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 8, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash" : 462 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 8, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash" : 462 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 8, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 1, "multi_hash" : 462 },
     { "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 8, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 1, "multi_hash" : 462 },
]
 
Je n'ai pas la moindre idée de la signification des paramètres baptisés de lettres grecques, comme de multi_hash.
 
Mais j'obtiens surtout l'erreur suivante:
"Invalid configuration for GPU thread 0: 'multi_hash':464 in gpu_threads_conf must be a multiple of 7"
 
Le fait est que 464 n'est pas un multiple de 7 mais le 462 que j'ai défini en est bien un.
 
J'ai du coup essayé avec 466, qui n'est pas un multiple de 7, et ça passe... à une autre erreur:
"Invalid configuration for GPU thread 0: 'worksize' in gpu_threads_conf for GPU 0 must be a multiple of 16"
 
La valeur qu'on retrouve dans ton fichier confgpu.txt d'exemple est pourtant bien 8.
 
Je teste donc 16 mais ça donne la même erreur comme quoi ce ne serait pas un multiple de 16.
18, 10, 7, 9, 15, 17, 19, 20: même combat, et j'ai la flemme de tester toutes les valeurs par incrément de 1, de 1 à what-mille.
 
Quelques améliorations et/ou corrections semblent donc à prévoir pour que cette 0.30 daigne fonctionner chez moi, ne serait-ce qu'une explication des différentes paramètres de gpu_threads_conf et des valeurs possibles.
 
EDIT: J'ai laissé tombé le ARQ car ça m'a tout l'air d'une coin foireuse, ne serait-ce que parce que les montants prétendument reversés par le pool n'arrivent pas sur mon wallet, et la rentabilité est de toute façon aux fraises.

multihash doit être un multiple de 16
cette histoire de 7 c'est bizarre…  
mieux vaut que tu prennes un exemple de la doc de github et garde les valeurs, je vais vérifier ma gestion de config.

Salut. Vais regarder ça

Ça donne quoi sur les vega?

Je suis reparti du fichier de config fourni en exemple, en testant diverses valeurs pour multi_hash dont la valeur idéale pour mes deux RX est à priori 496.
 
Les hashrates obtenus sont encore loin de ceux de SRBMiner.
JCE 0.30 vs SRBMiner, en h/s:
RX 580 4Go: 792 vs 931
RX 570 8Go: 838 vs 967
 
Mais je n'ai pas tenté de jouer avec les lettres grecques, n'ayant aucune idée des valeurs attendues ni de ce à quoi elles correspondent.
 
Sur ce, deux suggestions:
 
Dès lors que la valeur d'un paramètre doit être un multiple de N, il serait préférable de permettre la saisie d'un nombre libre par incrément de 1, et le multiplier par N à l'interprétation, en rebaptisant éventuellement les paramètres du fichier de config pour éviter toute méprise, par exemple multi_hash en intensity.
 
L'on a actuellement le hashrate par thread et le total.
Ca donne par exemple:

 
Mais il est fastidieux de calculer le hashrate par CPU ou GPU puisque ça implique de se taper des additions.
Il serait donc intéressant d'ajouter un niveau de détail intermédiaire, d'une couleur intermédiaire entre le cyan foncé des thread et le clair du total, et peut-être une indentation pour rendre l'ensemble plus lisible:

Bonne idée le total par GPU, et simple à faire
 
Les perfs sont étranges, la config doit être très différente, sur Bitcointalk ils disent que je suis devant tout le monde sur RX550 (ma carte favorite, c'est pas un hasard), toujours devant XMRStak/XMRig, souvent entre Claymore et SRB sur les autres cartes.
Pas 130 h/s en dessous.
 
Et à 2055 sur une Vega 64 d'après eux, ce qui est étonnant vu que je ne vise absolument pas à battre CastXMR. Je ne sais pas si c'est haut en fait.

Pour ce qui est des perfs de mes RX, un autre truc bizarre est que SRBMiner donne toujours de meilleurs hashrates que CastXMR, sans doute parce que SRB est paramétrable et j'ai pris le temps de trouver les valeurs optimales pour chacun de mes CG et chaque algo.
 
Avec ton mineur, je n'ai pour l'instant joué avec multi_hash et la valeur idéale est la même pour mes deux RX alors qu'elles sont habituellement différentes d'une carte à l'autre, la 580 ayant 4Go moisis et la 570 8 Go top moumoute.
Il pourrait donc peut-être enterrer SRBMiner si je savais comment bidouiller les autres paramètres, parce qu'ils sont trop nombreux pour que je puisse raisonnablement tester toutes les combinaisons possibles.
 
Ma config actuelle:

 
Ceci dit, je n'ai pour l'instant testé son mineur que sur du XMR, donc Cryptonight V7.
Je vais voir ce qu'il donne sur du CH Heavy et du Cryptolight...

Chez moi avec SRB, le worksize idéal est de 8 dans tous les cas sauf celui de la R580 en CH Heavy qui tourne mieux avec 7.
 
Mais avec JCE 0.30, "worksize: 7" => "Invalid configuration for GPU thread 0: 'worksize' in gpu_threads_conf for GPU 1 must be a multiple of 16"
Alors que la config fournie comme exemple définit 8 qui est bien accepté alors que ce n'est pas un multiple de 16.
 
J'ai en tout cas peu d'espoir de trouver une valeur donnant de bons résultats et qui soit un multiple à la fois de 7 et de 16.

Quelque chose doit vraiment clocher chez moi.
 
Avec SRBMiner, la valeur idéale pour le paramètre Intensity varie selon la carte et l'algo.
Mais avec JCE 0.30, la valeur idéale pour multi_hash est toujours de 496, indépendamment de la carte comme de l'algo, et les hashrates sont systématiquement bien loin derrière ceux de SRB.

le code est sans doute très different, je ne pense pas que mettre 7 soit pertinent dans jce. je sais pourquoi 7 peut être pertinent, pour le stridding, mais jce le gère nativement, même avec 8
 
par contre mon message d'erreur est buggé, je vais corriger.
 
 
d'après Bitcointalk, la meilleure config pour du Cn v7 sur rx580 8G est
 
 

J'ai tenté de m'en inspirer mais les résultats ne sont pas concluants.
 
Tout le problème réside dans le nombre de paramètres et leur implication obscure.
Quand il n'y en a que trois, l'on peut se permettre de tester au hasard toutes les valeurs et finir par tomber sur la bonne combinaison, mais comment faire avec huit?
 
alpha et beta semblent corrélés, ainsi que multi_hash avec tout ou partie des lettres grecques, mais c'est tout ce que j'ai pu trouver comme interactions pour l'instant, ce qui fait trop léger pour continuer à perdre du temps à tester des valeurs au pif.

C'est un peu documenté sur Github, en gros worsize a une très grosse importance, alpha pas mal, beta un peu, et le reste est généralement négligeable.
Attention aussi au temps de préchauffe : JCE ne pousse pas les GPU à fond tout de suite, mais démarre à 80% et monte progressivement. Ça pourrait expliquer tes résultats décevants.

C'est vraiment dommage ce timing alors que le bitcoin redescend au plus bas et va rester au mieux dans un couloir de consolidation horizontale pendant 6 mois mini... surtout qu'entre temps bitmain et compagnie ont signé chez les fondeurs pour du < 10 nm pour la prochaine gen d'asic.

En espérant que tu sois parvenu à faire un peu de maille depuis quand même vu le taf réalisé.

Edit : avec des compétences pareilles, tu as sans doute un poste de dev très bien rémunéré ?

 
Combien de temps environ pour être à 100% ?

Alors que je bataille avec la config de la 0.30, j'ai noté un détail horripilant:
 
Avec le paramètre --elevate-and-quit, la fenêtre ouverte par le .bat en ouvre une autre pour le miner, puis se ferme elle-même.
Ca fonctionne bien tant que... tout va bien.
 
En effet, lorsqu'on a un message d'erreur, à propos notamment d'une erreur de config, cette première fenêtre se ferme tellement vite qu'il est impossible de noter le message.
Il faut alors éditer le .bat pour ajouter un pause, relever le message d'erreur, corriger le problème puis retirer le pause, ce qui est fastidieux à la longue
 
Le top serait que --elevate-and-quit ne quitte qu'en l'absence d'erreur, et qu'au moindre problème, il maintienne ouverte la fenêtre contenant le message d'erreur comme le ferait un pause.

 
1. Non, c'est misérable, mais le défi est d'être le meilleur en OpenCL... au monde.   C'est motivant.  
2. Oui  
 
Quit: c'est pas trivial, du moins pas trivial de le faire proprement. Simple, mais ça prend pas 5mn. Je pense le faire, mais en moindre priorité
 

Ça dépend des GPU mais 5mn c'est assez sûr. Ca monte plus vite en Heavy/Haven.

Il doit être très rare d'avoir des configs différentes pour les threads d'un même GPU.
Si, comme je l'imagine, ça n'arrive jamais, il serait plus logique et pratique d'avoir une seule ligne de config par GPU avec juste une valeur supplémentaire NbThreads. C'est d'ailleurs ainsi que procède SRB.
 
Et avec ou sans cette optimisation de la config, dès lors que plusieurs threads d'un même GPU ont les mêmes paramètres, il doit être possible de compiler une seule fois le kernel puisque toutes les threads auront de toute façon le même.
Ne pas recompiler inutilement des kernels pourrait faire gagner du temps au démarrage.

Après une lutte infernale(ment longue) pour le paramétrer, JCE 0.30 est parvenu chez moi au niveau de SRB voire le dépasse légèrement.
 
RX 580 4Go avec mémoire à 1950 Mhz: ~930 h/s, pareil dont que SRB

 
RX 570 8Go avec mémoire à 2250 MHz: ~972 h/s, soit mieux que les 965 de SRB.

 
Détail curieux, la 570 avec quatre threads voit son hashrate taquiner les 1200 h/s mais il varie tellement que sa valeur moyenne semble même intérieure à celle obtenue avec deux threads auxquelles je suis donc revenu.
La config en question pour info:

Le hashrate est en fait réparti très inégalement entre les threads, et ce déséquilibre est aussi très variable dans le sens où l'on peut avoir à un moment donné une thread à 500 h/s alors que les autres sont à moins de 200 h/s, et le coup suivant, c'est souvent une autre qui sort son épingle du jeu.
C'est comme si les quatre threads se battaient pour des ressources insuffisantes pour toutes et qu'aucune ne parvenait à prendre durablement le dessus.
 
Ca laisse présager une marge d'optimisation de la config à deux threads mais je commence à manquer d'inspiration après tout le temps que j'ai passé dessus hier.
 
Sur ce, un autre détail qui me turlupine:
 
La touche P met en pause toutes les threads alors que chez moi:
 - les GPU sont dédiés au minage, ne peuvent servir à autre chose je n'ai donc aucun intérêt à les mettre en pause
 - le CPU n'a pas forcément que ça à faire et il n'est pas rare que je veuille mettre son minage en pause selon ce qu'il doit faire par ailleurs.
 
Avec la 0.30, pour mettre en pause seulement le CPU, je dois arrêter le logiciel puis le relancer avec une config ne sollicitant que les GPU, puis pour relancer le minage par CPU, arrêter à nouveau le mineur pour le relancer avec config utilisant aussi le CPU.
C'est nettement plus lourdingue qu'une fonction Pause qui affecterait seulement le CPU. J'apprécierais donc qu'une autre touche ait pour effet de mettre en pause seulement le CPU, ou que la touche P agisse ainsi désormais.

Content que tu aies trouvé un bonne config
 
Quatre threads, ouch... attention ça risque de flooder to cache d'instruction, et donc ça ne m'étonne pas que je hashrate soit alors très instable. Et ça cogne sur les drivers.
 
La pause par CPU/GPU est prévue. Comme le coin par GPU, le monitoring de température etc... J'ai une tonne de chose à implémenter.
 
Pour répondre à propos du code pré-compilé, même sur les mêmes GPU, la raison est surtout de sécurité.
 
Je génère du OpenCL qui est hardcodé pour un GPU particulier, dans une config particulière, afin qu'un assembleur dumpé grâce à de la DDL injection ou du stub (ce qui n'est pas dur à faire) ne soit pas lançable par ailleurs.
 
Autrement dit, à chaque fois, ça compile qlq chose d'un peu différent, une sorte de code jetable. Comme si je faisais un protocole réseau qui ne marchait que sur ta carte et aucune autre. Et par principe, ce code n'est pas pré-compilable.
 
edit : version 0.30a dispo

Je comprends tout à fait l'intérêt de recompiler à chaque lancement plutôt que de conserver chaque kernel sur disque.
Mais ma suggestion n'était pas de mettre un terme à cette compilation en live, mais simplement de l'exécuter qu'une fois par GPU dès lors que ses threads ont exactement le même paramétrage, ce qui à mon avis doit être systématique.
Mais quand bien même une telle amélioration serait envisageable, il va de soi qu'elle reste une fioriture pour ce qui est des optimisations possibles.
 
Mais indépendamment de la compilation de chaque kernel, la simplification du fichier de config serait appréciable, avec par exemple:

au lieu de  

Ca faciliterait en tout cas la recherche du meilleur paramétrage pour chaque carte et algo, déjà assez fastidieuse en elle-même (comme avec n'importe quel autre mineur).

C'est trop complexe pour moi tout cela.
Vous auriez pas la conf pour une vieille GTX 770.
Car il me detecte bien la CG mais pas de hash dessus.
Merci et excusez-moi pour mon faible niveau

je crois que ça ne marche pas sur nvidia, sur Bitcointalk ils m'ont dit pareil.

Ha ok, Merci

Le hashrate total par GPU est accueilli à bras ouvert
Mais il manque le total du CPU  

ok je te le mettrai aussi...

Encore un petite modif à éventuellement envisager: Ajouter l'index du GPU à la ligne: "GPU... finds a share...":
 
GPU Thread 8 Lane 396 finds a Share, value 46166
 -> GPU 0 Thread 8 Lane 396 finds a Share, value 46166
 
Parce qu'on n'a pas forcément en tête la correspondance entre le numéro de thread et son GPU.
 
Et accessoirement, mieux vaudrait s'en tenir à des numérotations commençant à 0 parce que actuellement, l'index des GPU commence à 0 dans le fichier de configuration, mais à 1 dans le log, ce qui peut induire en erreur.

Juste une question, pour une fois
 
J'ai des stale shares mais uniquement provenant des GPU.
Ceux provenant du CPU sont-ils censés apparaître dans le log?

ok pour le numéro du gpu, mais ils sont bien numérotés à partir de zero.
les stale shares sont plus fréquents sur gpu car le cycle gpu est très long.

 
Oups, oui, en effet. Je me suis laissé avoir par l'index de mes RX qui commencent à 1, le 0 désignant une 1050Ti    

la 0.30b est en ligne, avec le numéro du GPU dans le log, et du fix de netcode

Nickel, merci.
 
Concernant la numérotation des versions, ne serait-il pas préférable de remplacer la lettre suffixe par un numéro supplémentaire?
Par exemple: 0.30.2 au lieu de 0.30b
 
Les lettres, notamment a et b, peuvent être respectivement interprétées comme des versions alpha et beta.

disons que comme j'ai commencé ainsi, je préfère ne pas changer.
et je viens de me rendre compte que j'ai oublié de mettre le total Cpu

Quelle catastrophe cette absence du total du CPU. Je ne sais pas si je vais y survivre
 
Concernant le changement de numération, ma suggestion n'était évidemment pas de rebaptiser les versions existantes, ni même d'introduire ce changement dès la 0.30c.
Ce n'est envisageable qu'à partir de la 0.31, qui pourrait alors être nommée 0.31.0, sans que cela perturbe qui que ce soit.
Mais cette question-là n'a évidemment rien de crucial.