Reprise du message précédent :
L'ancienne version c'est équivalant à N=1.
Ensuite c'est tout à fait normal d'avoir des différences significatives de hashrate entre Cryptonight (1 et 3), Cryptolight (2 et 4) et Cryptonight-Heavy (5).
Et il faut sélectionner celui qui va bien en fonction du pool ou de la monnaie que tu vises.
Bref tout ce que tu écris semble cohérent.

Merci pour ton message, il m'a fait percuté que je tentais de miner du v7 sur le stratum de l'original
Vu que j'ai toujours laissé en auto, je me suis fait avoir avec l'arrivée du v7 vu que c'est passé direct dessus alors que j'avais pas mis à jour le stratum.
 
Je vais me renseigner sur le cryptolight car je sais pas si c'est équivalent au cryptonight en terme de profits (je pense que non) mais j'ai des H/s beaucoup plus élevés !

T'es conscient que le hashrate seul n'a strictement rien à voir avec le profit hein ?

Oui, tout à fait  
J'ai peut être mal formulé, mais ce que je voulais dire c'est que c'est peut être plus intéressant pour moi de bosser en cryptolight que cryptonight, il faut que je fasse des tests. Mais j'ai bien compris que c'est pas parce que j'ai un hashrate 4 fois supérieur en basculant de l'un à l'autre que je vais gagner 4 fois plus.

De même pour un même algo, le profit sera différent en fonction de la monnaie minée, sauf pour Nicehash ou là c'est purement lié à l'algo.

merci à tous pour les reponses, donc oui, la variation c'est le fork, et un seul est possible pour un coin donné.
 
les perfs se règlent avec -t et --archi

Ajout du fork IPBC (demande de Bitcointalk)

0.24d
 
Déverouillage de la liste des coins (demande insistante de Bitcointalk)
MD5 dispo sur le github

Je viens de découvrir que mon Ryzen 1700 était comme bridé.
Le bios comporte une option obscure nommée Performance Bias avec pour valeurs possibles Auto, None, CB15, AIDA/Geekbench, CB11.5.
Je pensais que ce paramètre ne servait qu'à tricher sur les scores de benchmark mais force est de constater qu'il affecte les performances globales et pas juste les benchmarks.
Je suis ainsi passé de 630 à 706 h/s    

Ouch !
Autant je suis balaise en OC et hack de 775 (avec option fer à souder et cutter) autant le ryzen est un monde obscure, je n'ai qu'une fois tenté d'OC le miens, et rien qu'avoir un bios UEFI me fait bizarre. Je vais quand même regarder dans mon bios si je vois une telle option.
 
Dans le même genre j'ai voulu activer le mode "Crypto Mining" qui correspond au Allocate Above 4G, et non seulement ça m'a fait un blackscreen au boot, mais en plus aucun moyen de reset le bios, même avec le jumper ou en enlevant la pile. Je n'ai jamais compris où était stocké le bios. Peut-être les condos sont tellement gros qu'ils continuent d'alimenter le CMOS pendant des heures, même sans pile  
 
Solution : booter avec une HD6000 merdique qui ne supporte pas le relocate, et faire ensuite un reset depuis le bios. Comment j'aurais fait si je n'avais pas eu de vieille CG ?
Conclusion : éviter les MSI en Ryzen pour miner, une horreur.

Apparemment le "Performance Bias" joue sur une utilisation plus "agressive" du Turbo. Donc le gain de perf est lié à une fréquence CPU supérieure, et donc une conso supérieure. Certains ont même dû revenir au mode Auto pour des raisons de stabilité.
Bref, il n'y a pas de miracles

Le fonctionnement de ce paramètre n'est pas clair du tout mais ça semble bien plus subtil qu'un simple boost de fréquence et tensions.
 
Ma fréquence est fixée manuellement tout comme les tensions et quelle que soit la valeur choisie pour Performance Bias, elles sont strictement les même, du moins d'après les logiciels de monitoring mais vu que la température du CPU et la consommation globale mesurée par un wattmètre n'ont pas non plus changé, ce paramètre doit agir sur autre chose.
 
A priori, il jouerait sur la manière dont les caches L2 et L3 sont gérés, et s'il y a différentes valeurs possible et que "None "est celle que sélectionne en fait Auto, c'est parce que chaque config peut fonctionner mieux et surtout rester stable avec une valeur différente, un peu comme CLDO_VDDP.
 
Mais hier soir, alors que j'avais opté pour CB11.5, j'ai essuyé un plantage inédit sous GTA V, parce qu'il n'a concerné que le son.
Je tourne depuis avec AIDA/Geekbench qui donne sensiblement les mêmes résultats, sans le moindre signe d'instabilité pour l'instant, ni surconsommation ni température supérieure.
 
Bref, je n'ai toujours pas la moindre idée de ce que fait ce paramètre mais ça m'a l'air tout bénef.
 

 
EDIT: que le minage en Cryptonight soit beaucoup plus affecté par ce paramètre que l'encodage vidéo semble confirmer que c'est au niveau des caches qu'il se passe un truc, vu que le CN y est particulièrement dépendant.
Il semblerait notamment que Performance Bias ait pour effet de réduire la latence du L2 et du L3 mais pas quel procédé, ça, mystère.

ça me fait penser aux hacks de timing de vram, qui n'aident pas trop en jeu mais boost énormément en xmr.
 

Le fait est que le bios donne accès à à peu près tout ce qui concerne le CPU (Cores + SOC) ainsi que la RAM, mais rien sur les caches et c'est sans doute là que Performance Bias va bidouiller.
 
Il est quand même frustrant de ne pas savoir ce qu'il fait exactement, même si l'on ne peut accueillir le gain de performances qu'à bras ouverts.

Ahhh je vois que l'EDL est supporté !

Je tente de tester ça ce soir sur mon 4790k

a la demande de bitcointalk j'ai déverrouillé les coins.
avec le paramètre --any tu peux miner ce que tu veux, mais tu perds la config auto, il faut donc mettre --variation N avec le bon N
 
il faut que je mette la doc a jour.
là je fais les tests  du dualshare, une autre demande de bitcointalk

Version 0.25 en ligne
 
Multi-hash, plein de nouveaux coins, et petites optims

Aurais tu le lien sur bitcointalk à propos de ton soft ? Je n'ai pas trouvé.  Merci

 
Pas réveillé aujourd'hui?
Il est dans le premier post du topic, celui-là même qui le propose en téléchargement.

oups !! Je retourne me coucher !!!  Merci

A propos d'interface, j'aime bien celle de SGMiner.
Elle affiche les informations importantes, globales et par GPU, en haut, dans un cadre fixe.
Le reste de la fenêtre contient le log qui défile sans dégager le cadre supérieur.
Avec un peu de coloriage, elle serait top.
 

c'est aussi le principe de sgminer-gm
je me suis plutôt inspiré de cpumineropt avec les couleurs de claymore. ça permet plus facilement de faire du log aussi.

En minant du LOKI, je teste pour la première fois le cryptonight heavy.
Il semble bien différent du cryptonight classique, du moins au niveau des hashrates.
 
En classique, avec Claymore pour les GPUs, j'ai environ:
RX 580: 812 h/s
RX 570: 940 h/s
Ryzen 1700: 706 h/s
 
En heavy, avec XMRig pour les GPUs, j'ai:
RX 580: 649 h/s
RX 570: 616 h/s
Ryzen 1700: 223 h/s
 
Je constate deux bizarreries:
 - la 580 avec sa mémoire moisie est désormais plus rapide que la 570 avec sa mémoire de compète.
 - le CPU est largué par les GPUs alors qu'il faisait presque jeu égal.
 
Le hashrate de JCE CPU est-il normal ou peut-on s'attendre à une amélioration à la faveur d'une nouvelle version?
 
EDIT: En prenant le temps de bien configurer la dernière version de SRBMiner et ma 570, cette dernière pédale à 845 h/s.
C'est toujours moins qu'en cryptonight standard ou v7, mais c'est déjà nettement mieux que mon premier test avec XMRig.
 
EDIT 2: En prenant là encore le temps de bien tout configurer, la 580 tourne à 770 h/s, ce qui est cohérent par rapport à la 570, mais moins par rapport aux hashrates en CN standard.

Ca peut sans doute aider à comprendre en partie : cryptonight heavy c'est 4Mo par thread.

Mes RX 580 8go sont plus rapide en heavy qu'en v7 ou classique
 
Heavy:
Micron : 930 h/s
Samsung : 990 h/s
 
classic et v7:
Micron : 880 h/s
Samsung : 1050 h/s

 
Merci pour l'info et honte à moi de l'avoir raté dans le log.
 
J'ai donc testé de 3 à 8 threads, sachant que j'ai 16 Mo de L3, 8 coeurs physiques et 16 coeurs logiques.
 
Mais les résultats me laissent encore plus perplexe:
 

ma référence c'est 252 h/s sur mon Ryzen 1600 stock sur du Sumo.
Je vais faire un test sur JCE 0.25 avec du Loki
 
edit: je confirme:
 

Assez étrange. Par contre faut pas oublier le L3 "inhabituel" des Ryzen : il y a en fait 2*8Mo (2 CCX) et chaque core a une "affinité" pour le bloc de 2Mo proche de lui. Bref, intuitivement, avec 4 thread j'dirais qu'il faudrait en mettre 2 par CCX : 0, 4, 8, 12 par ex

J'ai testé pas mal de réglages en CN Heavy mais les résultats que j'obtiens ne me paraissent pas cohérents.
 
Avec quatre thread, utilisant toutes le cache:

 
Pourquoi la première thread produit plus de 90 h/s alors que les trois autres rament à 41 h/s?
 
Plus space: en ajoutant une cinquième thread privée de cache:

 
Le hashrate de la thread sans cache est minable, ce qui est normal, mais en quoi sa présence peut-elle équilibrer les hashrates des quatre autres, et donner en plus un hashrate global à ce point plus élevé, même 'il n'atteint toujours pas la moitié de celui obtenu en CN?
 
Je ne suis pas assez calé en CNH pour affirmer que son implémentation dans JCE CPU est buggée mais...

Dans le premier cas (7 9 11 13), t'as le 1er thread tout seul dans son CCX et 3 thread qui se battent dans le 2ème CCX (avec seulement 8Mo).
Dans le 2ème cas, tu as bien 2 thread (4 et 6) dans le 1er CCX et 3 thread (8, 10 et 12) dans le 2ème CCX dont 1 privé de cache et qui fait pas grand chose.
T'as moyen de tester 0, 4, 8, 12 par ex ? Curieux du résultat

 
Ca explique en effet la première des bizarreries que j'ai postées juste après ton message, parce que répartir les threads par rapport aux CCX équilibre bel et bien leurs hashrate.
 

 
Mais ajouter une cinquième thread sans cache augmente toujours le hashrate global, de peu mais d'une valeur supérieure à celle de cette cinquième thread.
 

 
J'ai par contre tenté d'ajouter une deuxième thread sans cache, sur le coeur logique 7, mais ça n'a rien changé au hashrate global.

En tout cas, t'es passé de 223 h/s à maintenant un peu plus de 300 (+40%) rien qu'en optimisant le nombre de thread et leur répartition en fonction d'info purement théoriques, c'est pas mal
Reste à comprendre cette histoire de 5ème thread sans cache qui permet de gratter 3%. C'est bien reproductible ce truc ?

 
Ca l'est chez moi du moins

Sur CPU, le hashrate en CNH fait pâle figure face à celui en CN mais la consommation n'est pas du tout la même:
 
CN: 57W pour 706 h/s soit 12,4 h/s/W
CNH: 35W pour 316 h/s soit 9 h/s/W

et en laissant le réglage --auto ?
avec 8 cœurs physiques 16 logiques il devrait se mettre sur 4 threads : 0 4 8 12
 
sinon, je pense que ton score de 315 c'est le max pour ton ryzen, et en effet ton test du thread sans cache c'est interressant !

Avec --auto, les coeurs logiques assignés sont les 0 2 8 10, mais ça revient au même en terme de performances que 0 4 8 12 ou mes 1 5 9 13[/quotemsg]
 

Voila une manière optimiste d'appréhender le problème

Vu que t'as plus de coeurs que de cache pour miner du CNH, t'as essayé avec plus que 1 ou 2 thread sans cache ? Bref une petite comparaison des résultats avec 0, 1... et 8 thread sans cache (donc tous les cores utilisés), histoire de voire si ça créé une tendance ou autre.

je veux dire le max avec JCE.
Il n'y a pas 50 config valables, donc une fois que t'as la meilleure, bon ben voilà t'as la meilleure.
 
En CN-V7 sur mon R5 1600 je sais que le top c'est 8x simple thread AES-64, ce qui me donne 506, et pas moyen d'aller plus haut, j'ai tout essayé en terme de combinaisons.
 
Par contre en IPBC j'ai découvert récemment que faire 3+1+1+1+1+1+3+1+1+1+1+1 en multi-hash c'était un peu mieux que juste douze threads simple.
 
La piste interressante c'est cette histoire de no-cache, qui n'est pas prévue pour augmenter les perfs (ma doc dit même de ne pas tenter ça) mais si ça a un impact positif sur CN-Heavy c'est à creuser
 
edit: j'ai essayé et j'ai aussi un gain avec un thread additionnel No-cache, de +1%
faut que je fasse plus de tests...
 
re-edit: et avec deux, encore +1%, je m'envole à 256 h/s.
C'est vraiment un piste à creuser !!

Et moi qui pensais en avoir fini avec ces tests    
 
1 thread avec cache:

 
2 threads avec cache

 
3 threads avec cache

 
3 threads avec cache
1 sans cache

 
8 threads sans cache

 
4 threads avec cache
4 threads sans cache

 
4 threads avec cache
12 threads sans cache

Ce test-ci m'a valu un écran bleu après quelques minutes, mais je ne puis affirmer avec certitude qu'il a été causé par JCE CPU.

Pour ce qui est de la consommation, je n'ai pas pris la peine de la relever lors de chacun de ces tests mais elle semble plus ou moins proportionnelle au hashrate global.

Le test 4+4 est le plus interressant, car j'observe la même chose chez moi, le top c'est:
 
* Remplir son cache avec des threads normaux (4*4M)
* Finir avec les coeurs physiques sur du no-cache.
 
Pour mon R5 1600 (6 threads physiques, 12 logiques, 16M cache)
ça fait les threads
2, 4, 8, 10 en mode cache normal, plus
0, 6 en no-cache
 
(que des nombres pairs, toi tu utilises les cpu impairs, c'est pareil)
 
Je suis en train d'optimiser mon assembleur pour le mode no-cache, que j'avais ignoré jusqu'ici

Mon choix des coeurs logiques impairs est principalement psychologique.
 
Le minage devant garder une priorité plus faible que les autres applications, pour ne pas entraver l'utilisation du PC, et compte tenu que nombre d'applications doivent avoir tendance à squatter les premiers coeurs logiques qu'elles trouvent, et préférentiellement le premier coeur logique de chaque coeur physique, j'aime autant laisser celui-ci libre en assignant le mineur sur l'autre.
Mais j'admets qu'en pratique, ça ne doit strictement rien changer.
 
A noter que pour tous mes tests, sans exception, j'avais SRBMiner qui tournait en même temps mais vu qu'il n'est censé solliciter que mes deux RX, il ne devrait guère interférer avec JCE CPU.
Ce dernier n'a de toute façon pas vocation à tourner seul parce que même si le minage par CPU est assez performant en CN, il n'égale pas celui d'un GPU, et à fortiori celui de plusieurs GPUs, dès lors qu'ils sont correctement configurés.
Enfin, je ne parle évidemment pas des CPU à 12 coeurs physiques ou plus, comme le 1950X.