Reprise du message précédent :
Merci, et je confirme, un multi_hash trop haut peut provoquer ce problème.
Des fois il faut renoncer à qlq hash/s pour avoir une config stable, sinon le driver reprend de force de la mémoire à OpenCL et on se prend des erreurs ou un hash zero.

salut
yaisse
par contre grosse difference entre une 480 8go et 4 go -+ 100h  (j ais laisser { "mode" : "GPU", "worksize" : 4, "alpha" : 128, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 4, "multi_hash":880 },pour la 4go moins bonne,944 pour la 8go
 
sur ton futur mode "automatique" comment ca vas se passer? a la srb ou je te colle un truc plus ou moins passe partout ou ca vas etre plus pointu?  
je m explique :5 cartes identiques,meme mem,meme core ,meme marque memoire. 4 bonnes mais 1 moins bonne:srb lui colle les memes reglages....et ca couille.
 
j ais l impression que ton soft permet de "mieux" regler

Rien ne t'empêche de régler les GPU 1 par 1 dans SRB

 
Un mélange de table de configs optimales connues et d'autoconfig à la louche. Les GPU sont bien moins variés que les CPU, surtout que JCE CPU commence au pentium 4 32-bits.
Non il n'y aura pas de super optim de la mort qui dépend de la marque de ta ram, là ça devient du tuning poussé.

Un bon mode auto pourrait partir des valeurs connus pour tous les paramètres sauf multi-hash, et chercher la meilleure valeur pour cette dernière en commençant par la valeur candidate la plus base et en l'incrémentant progressivement tout en relevant le hashrate pour chaque valeur afin de trouver celle qui donne le plus haut.
 
Dit comme ça, ça a l'air simple mais j'ai dans l'idée que ça doit être une autre paire de manche pour le coder, notamment la gestion du multi-hash trop élevé parce que la transition entre la valeur optimale et celle où tout plante peut être abrupte.

 
 
oui c est que j ais fais dans le rig "fourre tout"  

version 0.31d en ligne
 
meilleure pause par gpu
tuer le process parent arrête le mineur
autoconfig gpu
petite optim

Vais essayer ça

Est ce qu il y a qques chose pour relancer le mineur ou les thread si le hash tombe a 0?

pas encore de watchdog

Si le hashrate tombe à 0, c'est que la config n'est pas adaptée.
Relancer le mineur avec cette même config aboutira donc au même problème.
La seule solution est de corriger la config pour que le hashrate soit stable.

salut
 
viens d essayer la 31e.
j arrive pas a virer le mining cpu ?
le auto config n est pas bon pour moi.trop haut.
le -c <C:\Users\coke\Desktop\jce_cn_gpu_miner.prototype.031e\config.txt>  n est pas un argument valide?
 
repasse en 30c pour le moment
 
edit:config.txt lui suffis
 
edit 2:tu as eu un rig pendant 35 min

Version 0.32 GPU en ligne.
 
très expérimentale, elle démarre beaucoup plus vite.
nouveau param -g pour filtrer les GPU

Salut

Un truc bizarre sur le rig 580 4go

Pendant plusieurs heure ,sur une carte,2 treads a +-500hs. Puis soudain tread 1 a 0 et tread 2 a 800hs.

De la même façon qu'on a à intervalle régulier le détail des hashrates, il serait appréciable d'avoir en plus le nombre de shares acceptés, rejetés et stale, par CPU et GPU.
Ca éviterait notamment de remonter tout le log pour compter les shares rejetés.

salut
 
si il y a moyen d ajouter les rpm et la temp    
 
l ordre des gpus de jce,c est le meme que overdrivetool ou gpuz?   au bout d un moment je m y perd

Aux dernières nouvelles, c'est prévu et devrait arriver sous peu.
 

L'option --probe permet d'afficher la liste des GPU avec leur index.

et sinon, que ça soit en CPU ou en GPU, t'envisages de faire une routine de bench pour auto détecter les params optimaux ? (à la minergate)

Sachant que j'utilise 2 GPU 580RX 4GO Pulse, pourriez-vous m'aider à paramétrer l'appli pour un minage exclusivement GPU (Q6600 pour le CPU)

Salut!
 
Alors déjà, la version 0.32d est en ligne
https://github.com/jceminer/cn_gpu_miner
si vous voulez tenter, sinon la 0.31f reste une valeur sûre.
 
Pour la config, avec le paramètre --no-cpu ça désactive tout minage CPU, c'est déjà ça de fait. Ensuite pour configurer tes GPU il faut un fichier de config X et passer en paramètre -c X, par exemple -c config.txt
 
Il y a un exemple dans le zip du mineur, et des bonnes config sur la page Github.
 
Je n'ai pas trop le temps de faire une super config optimale, surtout que les hashrates de GPU sont parfois instable.

slt,
 
1er mess sur hardware.fr   ,je vien de voir que ce miner est FR via googl.
 
miner qui tourne bien en 032d  ,testé sur un rig mix de rx 4xx /5xx et r9 290 , tous réglé au mini pour les T° extérieure .
[img][/img]
 
les fan+T° sont un +,mais pourquoi sont-ils en double à chaque fois ,sans taper la touche T bien entendu .
 
 
[img][/img]
 
Bonne continuation et très bon miner .
 

Le Webchain n'a pas encore de miner GPU, ça peut être intéressant de s'y pencher ?
https://bitcointalk.org/index.php?topic=3649170.0
https://github.com/webchain-network/webchain-miner

Personnellement, les shitcoins amplement préminées et basées sur une supposée variante du Crytponight, et surtout affublées d'un nom bien générique visant à la faire passer pour des coins sérieuses, ça m'a passé.
Je pense notamment aux ARQ, BL0C, XPP et RYO.
Je me recentre sur des coins qui ont moins de chances de finir considérées comme des scams.

on me l'a demandé sur bitcointalk, j'ai refusé car ils ont aussi beacoup changé le netcode, et j'ai absolument pas le temps de tout refaire pour un shitcoin.
 
cependant ils propose un xmrig modifié pour gpu il me semble (qui ne marche qu'avec webchain)

Le monitoring de la température et de la vitesse des ventilos de chaque GPU est le bienvenu.
Mais la disparition de l'affichage automatique des hashrates au-delà de la première et désormais unique occurrence l'est moins car j'ai personnellement davantage besoin de surveiller les hashrates que les températures ou la vitesse des ventilos.
 
Les hashrates risquent en effet bien plus de se retrouver avec des valeurs anormales.
 
Afficher tout le détail des hashrates est certes assez lourd visuellement mais ne serait-il pas possible de laisser l'affichage détaillé actuel accessible via la touche H tout en proposant en parallèle un affichage automatique régulier du condensé des hashrates, qui n'afficherait que le total par CPU ou GPU?
 
L'idéal serait bien sûr qu'on ait le choix via un paramètre de config qui pourrait être la fréquence d'affichage des hashrates globaux où 0 le désactiverait.
 
Une autre amélioration possible, plus superflue: pouvoir définir des seuils de température ou vitesse des ventilos, et n'afficher les valeurs monitorées que si un de ces seuils est dépassé, voire arrêter le minage.
En cas de simple avertissement sans interruption, il faudrait une couleur bien plus flashy que le magenta sombre actuel, qui gagnerait au demeurant à être éclairci pour être plus lisible.

sauf si j'ai (encore) fait une regression, la touche H continue d'afficher le hashrate en bleu, et à intervalle régulier. je l'aurais cassé avec la fonction temp/fan ?
 
le seuil pour stopper le mineur, c'est le watchdog, c'est prévu
 
edit: t'avais raison il y avait un bug, ça sera corrigé dans la version g.

Cela dit, le hashrate total par CPU ou GPU est bien plus important que le détaillé par thread.
Comme l'affichage de ce détail est assez lourd visuellement, je pense qu'il serait préférable de ne l'afficher que via la touche H, et n'afficher automatiquement que la version condensée se limitant aux totaux à intervalle régulier, idéalement paramétrable par une option.
 
Cet affichage automatique condensé pourrait même être fusionné au monitoring des cartes avec simplement une valeur supplémentaire "Avg hashrate", et une ligne pour le CPU même si lui ne serait pas monitoré au-delà du hashrate.

un affichage condensé quand il pop automatiquement, oui c'est assez simple à faire
 
version 0.32g CPU en ligne, qui backport les corrections de netcode de la version GPU

Du coup vous pourriez m'aider à configurer ce mineur pour 2 RX 580 4Go Pulse ?

JCE CN nécessite les droits d'administrateur. Soit.
 
Mais pourquoi a-t-il absolument besoin d'élever lui-même ses privilèges par --elevate ou --elevate-and-quit, sans se contenter d'un lancement "en tant qu'administrateur"?
 
Ce dernier ne serait-il pas suffisant, ou est-ce que JCE CN considère systématiquement, et donc pas toujours à raison, qu'il est lancé sans les droits d'admin?

2 RX 580 4Go Pulse :
 
 
"gpu_threads_conf" :  
[  
 
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 16, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash":900 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 16, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 0, "multi_hash":900 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 16, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 1, "multi_hash":900 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 16, "gamma" : 8, "delta" : 8, "epsilon" : 8, "zeta" : 8, "index" : 1, "multi_hash":900 }
 
 ],
 
classiquement ce que j'utilise pour  1150/880-2050/890 : 941h/s  sur rx 470 -samsung/hynix -4GO.

Normalement JCE peut se contenter des droits d'admin classiques, avec un lancement as-admin.
Ces droits ne sont utiles que pour allouer des Large-Pages. En GPU-only, pas de droits nécessaires.

bonsoir dev  , une évolution est-il  possible pour les APU type ryzen 2200/24000G vega  dans une prochaine version GPU ?

possible oui, c'est même prévu dès le début, mais j'ai plein d'autres features à finir avant…

C'est compréhensible    
merci .

J'ai une bizarrerie sur une shitcoin, le Xcash (XCA).
 
Le log fait d'abord état d'une connexion établie avec le pool, il récupère la difficulté puis annonce qu'il ne peut plus se connecter.
 
Si c'était encore une frasque de mon pare-feu, la connexion serait tout simplement impossible.
Ce problème me laisse d'autant plus perplexe qu'il ne se produit apparemment que sur cette shitcoin ou son pool officiel. Il ne se produit en tout cas pas sur le MSR, le HXV ni le TUBE.
 

 
EDIT:
J'ai testé plusieurs versions: Ce problème de connexion à minerxcash.com:5555 n'apparaît qu'avec la 0.32a.
J'ai donc dû revenir à la 0.31f pour pouvoir miner du XCA, qui pourra au passage être ajouté à la liste des coins supportés une fois le bug de connexion corrigé:
 
Xcash (XCA)
Cryptonight V7 --variation 3
https://bitcointalk.org/index.php?topic=4781246

J'ai ajouté X-Cash et zBucks dans la 0.32h
Mais pas eu le temps de regarder pour ton pb de pool

La correction de mon problème de pool n'est pas urgente dans le sens où je peux me contenter de la 0.31f le temps qu'il faudra.
J'ai tout de même testé la 0.32h et le bug est toujours présent:

La ligne de commande aboutissant à ce log, et qui fonctionne parfaitement avec la 0.31f:

 
Je viens de tester un autre pool avec la 0.32h, et le problème de connexion persiste.
Il n'est donc lié qu'au XCA avec les versions 0.32.
 
EDIT: Il n'y a vraiment plus aucune urgence pour ce qui me concerne à corriger ce bug à propos du XCA.
J'ai en effet arrêté d'en miner après être devenu millionnaire (pas en euros mais en XCA hélas)    
Il est toutefois à craindre que ce problème touche quiconque minant cette shitcoin.

La ligne "Accepted by the pool" pourrait devenir "Accepted by the pool in 237 ms", mentionnant ainsi le délai de soumission qui peut faire état d'un éventuel problème de bande passante, qualité de connexion ou disponibilité du serveur.

Yo,  
 
Tu pourrais mettre le code SHA-256 ou SHA-1 de tes zip, parce que mon AV aime pas tes dernières mise a jour.