Reprise du message précédent :
0.27d en ligne.
Ajout du fork MKT (demande de l'équipe MKT, JCE sera le 2e mineur supporté, après le mineur officiel)

Je viens de tester par curiosité mais ça ne marche pas fort, sans doute à cause d'une config foireuse de ma part.
J'ai d'abord essayé sans le --variation puis avec --variation 9 donnant le log ci-dessous mais je n'ai chaque fois que des shares rejetés "low difficulty":
 
 

Normal, le mec de MKT m'a dit qu'ils allaient fork ce vendredi. JCE 0.27d a 5 jours d'avance.
Je vais le spécifier dans la doc Github
ajouter --variation 1 en attendant le fork

Bon, j'ai testé avec la 0.27d, mais je confirme que ça roule maintenant. Merci
 
Entre l'ajout du paramètre --forever (j'ai des machines avec une connexion très instable) et le no-cache, ça me fait de gros changements !
 
Sur les CPU pas trop vieux, le no-cache augmente de 5 à 10% les perfs, l'écart se creuse vraiment avec xmr-stak-cpu ! Par exemple, sur un 6700k @stock je passe de 305 à 333H/s.

Peut-on espérer un jour un mineur unifié CPU + OpenCL + CUDA, même si pas optimisé sur ces deux derniers?

C'est 3 architecture totalement différente

 
Je suis bien conscient du boulot que ça peut représenter mais comme XMR-Stak y est parvenu, même si c'est sans doute en s'appuyant sur voire en pompant le travail d'autrui, peut-être est-ce aussi possible pour le mineur de JCE à terme.
 
La rémunération via les dev fees serait en tout cas autrement plus conséquente que l'actuelle, parce que le minage par CPU restera anecdotique par rapport à celui par GPU.

Je suis en train de préparer une version CPU Linux et GPU OpenCL. Autant la Linux c'est assez simple vu que mon assembleur est portable (c'est du GNU Assembly) autant le GPU ça sera balaise. Et je ne veux pas pomper les kernel Wolf0 de xmrstak.
 
Par contre CUDA, je n'y connais rien et je n'ai pas de carte nVidia

de toutes façons les nvidia sont merdiques sur cryptonight donc t'embetes pas avec ça. Eventuellement quand tu passeras sur d'autres algo pour dominer le monde de la cryptos.

exactement, je ne battrai pas Claymore dual sur les nVidia de toute façon. stak sur rx560 ou sur hd7000 c'est faisable.

Je sais que les Nvidia sont relativement larguées sur le Cryptonight mais si ma petite 1050Ti se débrouille assez bien sur l'Ethash, cet algo la fait chauffer plus que de raison. En hiver, c'est gérable mais d'ici peu, il lui faudra un algo moins violent pour qu'elle puisse continuer à miner sans surchauffer.
 
Le cryptonight me paraissait un bon candidat, même s'il entrave davantage la disponibilité de la carte pour l'affichage.
 
Mais puisqu'à vous lire, ça ne vaudrait pas le coût, je vais devoir tester d'autres algos en espérant en trouver un qui ne fasse pas trop chauffer, qui laisse la carte relativement disponible et qui soit assez rentable, autrement dit la perle rare.
 
Sur ce, une fonctionnalité qui pourrait être pratique pour JCE CN CPU: la possibilité de mettre le minage en pause sans arrêter le logiciel, via la touche P par exemple, et le relancer sur un nouvel appui sur cette même touche.
Elle n'est pas essentielle tant que le mineur ne gère que le CPU mais lorsqu'il gérera aussi des GPUs, pouvoir activer/désactiver à la volée chaque GPU sera appréciable.

ce n'est pas dur à faire, bonne idée !
la 0.27e est sortie, ça corrige des bugs, aucun autre changement

 
   
 
Super cool de te lancer la dedans, et déjà bravo pour la version actuelle que je teste un peu à la va vite sur différentes architectures. (pas trop de temps pour faire des report, sorry)
 
J'ai encore un peu de mal à optimiser, j'ai souvent de meilleures perfs en auto qu'en configurant le config.txt (que ça soit sur Ryzen 1600x, i5 ou i7)

N'hésite pas à utiliser la dernière version et à venir poster tes résultats et ton fichier de config ici.

 
ya un probleme avec ta carte
1/ une 1050ti ne devrait jamais chauffer
2/ l'eth ne fait vraiment aps chauffer les cartes, certes plus que cryptonight mais celui ci doit etre le moins violent sur le GPU. Si on peut faire du dualmining c'est justement aprce que l'ETH est tres leger sur le GPU lui aussi donc aucune raison que ça chauffe.

 
Ma carte a peut-être un souci mais son plus gros défaut set de n'avoir qu'un ventilo qui se retrouve rapidement dépassé par les évènements.
A noter que j'ai récemment remplacé la pâte thermique d'origine par de la Kryonaut histoire qu'elle puisse miner plus sereinement, mais elle chauffe quand même toujours pas mal.
 
C'est à priori celle-ci: https://shop.hardware.fr/fiche/AR201610200197.html
 
Pour l'instant, elle pédale sur de l'Equihash (ZEC) dans les contexte suivant:
 
Température ambiante: 21°
Température du GPU juste en-dessous: 57° (sachant que la ventilation du boîtier, assurée par 5 Noctua PPC, est du genre violente)
Température de la 1050Ti: 69°
Ventilateur de la 1050Ti: 96%
 
Sur de l'ETH, elle tourne à ~71° avec le ventilo à 100%, ce qui me faisait craindre les prochaines chaleurs estivales.
 
Enfin, il est vrai que 70°, ce n'est pas encore dramatique pour un GPU mais qu'en est-il des 85° auquel je m'attends en pleine canicule?

 
Ok, par exemple:  
 
Pour le Ryzen 1600x (12core) configuré sur 6 thread (0.27e en admin) :
 
 
"cpu_threads_conf" :  
[  
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 1, "use_cache" : true },  
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 3, "use_cache" : false },  
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 5, "use_cache" : true },  
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 7, "use_cache" : false },  
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 9, "use_cache" : true },  
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 11, "use_cache" : false },  
]  
 
j'obtiens environs 200h/s avec ce fichier config, contre 215h/s en auto (sur du Heavy !)

 
Pour moi, une CG qui reste en dessous de 80°C par grosse chaleur en forte charge, y'a pas de soucis.

Ryzen 1600X, un 6C/12T avec 16Mo de L3 (merci AMD pour n'avoir pas désactivé une partie du cache )
Et avec cette config-là ?

"cpu_threads_conf" :  
[  
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 3, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 5, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 7, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 9, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 11, "use_cache" : false },
]

Explications :
Heavy = 4Mo/thread, 16Mo de L3 => 4 thread avec cache.
6 cores, donc 2 inutilisés => on complète avec 2 thread sans cache.
CPU composé de 2 CCX ayant chacun 3 cores et 8Mo de L3 => 2 thread avec cache + 1 thread sans cache dans chaque CCX
CCX N°1 = cpu 0 à 5
CCX N°2 = cpu 6 à 11
Pour éviter de mettre 2 thread sur le même coeur, utilisation de tous les cpu dont l'index est impair (ou pair, ça revient au même, j'ai conservé ton affinité car elle était correcte).

Celle-ci ne donnerait-elle pas de meilleurs résultats?
 
"cpu_threads_conf" :  
[  
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 2, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 3, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 5, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 6, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 7, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 9, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 10, "use_cache" : false },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 11, "use_cache" : false },
]

C'est aussi ce que tu fais sur ton 1700 ? A tester aussi.

 
Oui, à ceci près que mon 1700 a 16 coeurs logiques soit quatre de plus que le 1600X, ce qui donne:
 
"cpu_threads_conf" :  
[  
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 1, "use_cache" : true },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 2, "use_cache" : false },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 3, "use_cache" : false },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 5, "use_cache" : true },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 6, "use_cache" : false },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 7, "use_cache" : false },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 9, "use_cache" : true },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 10, "use_cache" : false },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 11, "use_cache" : false },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 13, "use_cache" : true },
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 14, "use_cache" : false },    
   { "cpu_architecture" : "ryzen", "affine_to_cpu" : 15, "use_cache" : false },        
]
 
C'est en tout cas la config qui produit le meilleur hashrate en CN Heavy.

 
hello gougui !
et ceci devrait être la meilleure config sur un ryzen 1600

 
Hey Jc, alors merci de la proposition de cette config, et en effet, c'est un peu mieux qu'en auto par moment, ça me fait passer à des pointe à 233h/s, mais en retombant à 210h/s à d'autres.
 
 

Tu as bien mis le power limit à 55%? Car je tourne comme ça et mes 12 1050 ti ne chauffent pas et envoient du 15,2Mh sans problème.

 
Mea culpa, je n'avais même pas tenté de jouer avec le power limit.
 
J'utilise l'outil founi par EVGA pour overclocker ma 1050Ti. Il ne permet de réduire le power limit que jusqu'à 70° mais force est de constater qu'il réduit déjà bien la température sans pour autant impacter le hashrate.
Ma petite 1050Ti est donc parée pour l'été même si je vais chercher un freeware mieux fichu que celui d'EVGA qui me tape un peu sur les nerfs.
 
Sur ce, le minage par GPU étant pour l'instant hors sujet sur ce topic, mieux vaut clore cette discussion centrée sur mes lamentations  

un proto linux, peu testé, est dispo là
https://github.com/jceminer/cn_cpu_ [...] ed.028.zip

Je viens de monter un début de rig avec deux sapphire RX580 pulse 4 Go, il y a un Q6600 dessus (non OC) : à votre avis ça vaut le coup de faire miner le proc ou ça va me coûter plus cher en électricité que ce que ça va me rapporter ?

Environ 10 à 15c par jour en fonction de la fréquence du CPU. A toi de faire les calculs mais il y a des chances que ça ne soit pas rentable.

J'ai un X4 860K, déjà plus puissant que le Q6600, dont le hashrate ridicule en cryptonight exclut déjà toute rentabilité.

Du coup une version pour GPU AMD serait dans les starting block ?

Un Q6600 donnera 102 h/s avec JCE, ce qui fait ~0.13€/jour, à toi de calculer. Moi je fais miner mes Quad, mais avec de l'overclock à 2.66G (ça augmente la renta) et ce sont des modèles low-power (des xeons L transformés en Core2Quad).
Avec un vrai core2@stock, je ne sauris dire si c'est rentable
 
Oui ensuite je vais attaquer la version GPU AMD, mais entre Claymore 11.3 qui est sans fees (mais assez instable chez moi, et qui côté pool ne me donne que ~92% de la puissance qu'il affiche (triche?)) et SRBMiner, et CastXMR pour les vega/rx580, la concurrence va être balaise.

Attention, les Core2 ont 8M de cache L2 (et zero L3) donc ce sont des brutes en Cryptonight, pour des CPU sans AES. JCE leur permet de n'être que 50% plus lents que l'équivalent avec AES.
Les vieux AMD sans AES... oui là c'est difficilement rentable.

 
Effectivement, mon X4 860K n'a que 4M de cache, ce qui doit sérieusement le désavantager sur le CN.

quelle pool préfères tu ?
 

Fidèle à mes habitudes, j'ai choisi au pif le pool officiel: http://pool.dero.live/#
Mais la difficulté et le hashrate global sont devenu tels sur le DERO qu'il n'est plus du tout rentable de le miner avec des GPUs, et à fortiori avec des CPUs.

Version Linux et Windows 0.29 en ligne
 
fork ArtoCash et bugfixes

0.29a en ligne
pas de gros changement, nouvelle feature : Pause (touche p)