Reprise du message précédent :
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.

Les "Average hashrate" ne me semblent pas cohérents car ils sont chez moi souvent supérieurs aux maximums affichés en cyan, à moins qu'il ne s'agisse des "net effective".
 

Au passage, une nouvelle shitcoin à ajouter:
 
Veronite (XVV)
Cryptonight Heavy: --variation 5
https://veronite.space/
https://bitcointalk.org/index.php?topic=4872144

salut
 
viens d essayer la 32h.
je perd une 100 aine de hash sur 5 cartes
 
l espece d autotune en live est sympas mais je pense trop "safe"
du coup estce que l on peut pousser un peu plus le multihash?

la période de warmup n'est pas de l'autotune, mais un moyen d'éviter que les cartes restent bloquées à 80% de leur puissance. ça ne marche pas encore bien sur toutes les cartes.
 
oui c'est le net hashrate, je vais corriger c'est ambigu.
très bonne idée le temps de réponse du pool, et simple à faire…
 

 
ok pour le nouveau coin.

salut
sur le rig 570,sur une carte,j ais un tread sur les deux qui part en sucette au bout de 3/4h.
"rejected,low share dificulty"
 
des que j en ai un,je n ais plus que ca
le hashrate reste normal,mais plus d accepted sur ce tread.
 
"mode" : "GPU", "worksize" : 4, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 4, "multi_hash":816
 
je suis passe de 880 a 816 mais tjrs pareil.
0 erreur sous hw info
 
 
 
edit:ce qui est bizarre c est que je perd pas une seul hash en passant de 880 a 816 sur ce thread?
 
edit 2:j etais en blockchain,je tente les 18.6.1

Des zip de la version GPU?
Ok je le ferai à partir de la 0.32k
 

Corrigé dans la version 0.32j
 

Fait dans la version 0.32j
 

Ajoute --doublecheck pour savoir si c'est ton GPU ou un pb de netcode.

Mon problème de connexion au pool n'est finalement pas lié au XCA, mais à la --variation 3 (Cryptonight V7) car j'y ai aussi droit sur du XMR.
Pour miner du CN V7, je n'ai d'autre choix que d'utiliser la 0.31f, ce qui n'est pas dramatique mais ça reste frustrant.

J'ai fait une petite correction dans le netcode pour ça, dans la prochaine version ça pourrait mieux marcher.

salut
je peut enfin miner avec une version 32 sur un rig 570 .avant la 32h,j avais systematiquement un reboot a la creation du premier kernel sur la premiere carte.
 
pourtant avec les meme reglage que la 31e ?
bref ca le fait avec le 32h.
 
et la passage en 18.6.1 sur l autre rig a regler le probleme et me permet d oc un peut plus

la 0.32k2 est en ligne, avec plein de fix et les perfs de la version j
ça corrige un bug d'affichage du compteur de shares et le problème de netcode de Lermite

J'ai assez fréquemment des échecs de connexion ponctuels à XMRpool.eu pour cause de timeout alors même que ma connexion VDSL2 lui est pratiquement dédiée.
 

 
La plupart du temps, la connexion est retrouvée dès la première tentative de reconnexion mais il arrive qu'elle ne le soit qu'à la troisième.
 
Sans doute est-ce le pool qui pédale dans la semoule mais peut-être serait-il souhaitable d'attendre la réponse du serveur un peu plus longtemps avant de considérer que la connexion est en rade.
 
Ce problème est commun aux versions 0.31f et 0.32k2 et ne semble donc pas spécifique à une en particulier.

Est-il normal qu'avec la 0.32k2, le paramètre --bus-order soit sans influence sur l'ordre d'affichage des GPUS via --probe ?

non, je vais corriger ça, je dois surement lire mes paramètres dans le désordre
 
La prochaine version sera une CPU Windows 32/64
 

Ok je vais allonger un peu le délai
 
edit: corrigé dans la 0.32m

c'est la premiere fois que ça m'arrive, mozilla qui bloque carrément le téléchargement pour cause de virus dans le .zip.
 
il a meme pas fini de le dl  

oui le mineur est détourné en silent mining    
c'est ça d’être le numéro 1 en cpu  

 
? Source ?

C'est inévitable, même Claymore se faisais englober dans des versions pirates qui détournaient des shares ou les fees. J'ai blindé mon netcode autant que possible, mais ça a ses limites.
 
Et pour être encore plus Number One en cpu, j'ai sorti la 0.32n Windows, qui supporte correctement les machines à 64+ cpu, grace aux logs d'un utilisateur sur Bitcointalk, avec son Dual Epyc

Je tourne toujours avec la bonne vielle 0.29a, le I7 qui me sort du 320 h/s, pépère.

Toutes mes tentatives d'installer la version GPU ont échoué, le lobby des AV te déteste.

Plop all.
 
Je viens enfin de tenter "sérieusement" le miner de notre ami JC.
Et je dois dire que mes premières minutes avec lui sont.... surprenantes !  
 
J'ai donc installé ce miner sur mon RIG de 4 RX470 8Go et 3 RX560 4Go.  
 
Avec XMR-stack j'obtenais 3100 h/s pour une conso de 480w.  
Avec JCE j'obtiens 4700 h/s de "effective net hashrate" et de 4900 h/s lors de l'affichage général pour une conso de 570w alors que 1 thread sur 14 est à 0.  
 
C'te différence de ouf !!!  
Ca représente une hausse de conso de 18,75% mais une hausse de H/R de 58% !!!  
Et encore, j'ai tout laissé par défaut. J'en reviens pas...  
 
Avant les questions techniques, un truc qui m'étonne quand même : comment ça se fait qu'avec le même algo et le même RIG, la conso passe de 480w à 570w ? Le setup des cartes est exactement le même bien sûr.  
Quelles info je dois vous fournir pour tenter d'optimiser encore cet incroyable résultat ?
 
Bravo JC, grand respect...  

salut
 
ben jc a ecrit et optimise son code ,il n as pas pompe du vieux code sur wolf ou d autre.
et surtout il ne vole pas de share (stak je sais pas si le hr reporte est bon).
 
pour la conso,son code est plus optimise,il fait tourne " a fond" la carte.
 
a toi de voir ton oc et tes reglage core/mem

Déjà, est-ce que l'un de vous (je pense particulièrement à toi et à lermite) aurait un début d'explication pour expliquer pourquoi j'ai toujours un des 14 threads à 0 ? Ce n'est pas toujours sur la même carte, donc je ne sais pas trop comment chercher :-(

multi hash trop haut
ou oc pas bon

Les GPU sont très complexes. Et différents des CPU. En particulier, ils sont auto-vectoriels : si ton algo n'utilise que la moitié des registres, il va vectoriser par deux, un tiers par 3 etc. Et JCE a bon bon niveau de vectorisation, plus que stak, donc j'utilise plus de ton GPU, et il consomme aussi un peu plus, normal.
 
Pour le thread à zero, baisse le multi_hash, mon auto-config fait ce qu'elle peu mais ça dépend de tellement de choses un rig de GPU: les drivers, la résolution des écrans...

Merci à vous 2.
Pour l'instant j'ai coupé, juste le temps d'atteindre le payout ETH de nanopool et dans 48H je m'y remets ;-)

Si je dois baisser le multi hash dans le fichier config, je suppose qu'il faut que j'enlève le paramètre --auto du start.bat ?

Edit : en plus d'être évident, c'est écrit dans le fichier help...

Salut tout le monde (hmmmm, hmmmm   ).

Je vais essayer de me lancer dans une utilisation continue de JCE miner à la place des classiques Claymore, XMRstak et autres.

Pour cela, je vais avoir besoin de votre aide.
Voici pour commencer un screen de mon RIG composé de 4 RX470 8Go et 3 RX560 4Go me donnant 4800 h/s pour 560w à la prise:

De manière aléatoire, un thread est systématiquement à 0 à chaque lancement du soft, et ce n'est jamais le même, ni sur la même carte. Je ne sais donc pas trop comment régler ce soucis, d'autant que j'ai déjà baissé la fréquence RAM de toutes les cartes...
Avant de pousser plus loin les investigations, est-ce que le fait d'enlever le paramètre --auto et de configurer manuellement la bête me permettra de gagner en perf ou alors le jeu n'en vaut pas la chandelle ?

Mes 2 premières questions :
- Dans un premier temps, voici mon fichier .bat, voyez-vous quelque chose à modifier ?
- quand je relance le miner, il arrive qu'une fenêtre s'ouvre en indiquant que la mémoire sur mon RIG est insuffisante. J'ai 8Go de DDR3 et la mémoire virtuelle est fixée manuellement à 16Go. Dois-je modifier la mémoire virtuelle ?

Merci à vous.

Edit : je n'ai pas encore touché à la valeur multihash puisuqe je suis en auto, et que je ne sais pas encore comment la baisser. Passer de 128 à 120, baisser de 10%, de moitié, ..., ... Ca sera la prochaine étape, quand j'enlèverai le --auto

avec autant de cartes, pousse ta mem virtuelle à 64Go au moins !
et oui la config manuelle permet de corriger les pb de hash à zero en baissant multi_hash, et de tuner pour avoir un max de perfs
 
 
worksize, tente 4, 8 ou 16
alpha, 64 ou 128
beta 8 ou 16
 
les autres sont deprecated. multi_hash doit être un multiple de 16

Super, merci JC.
Je testerai ça ce soir !

Finalement, pas sûr que j'ai le temps ce soir...
 
Dans le fichier config fourni en exemple avec ton soft, nous avons ça :
 
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":128 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta":4, "index" : 0, "multi_hash":128 },
 
Ca correspond donc à 2 thread pour 1 GPU.
 
Dans mon cas, puisque j'ai 7 GPU sur ce RIG je vais avoir 14 threads.
Il me faut donc dans mon fichier config 7x les 2 lignes ci-dessus ?
Si oui, c'est la valeur "index" qui indique le n° de GPU ?
 
Je crois que Lermite a demandé il y a quelques semaines / mois, mais on peut savoir à quel paramètres les fontions "alpha", "beta", ..., ... sont relatives ? A moins que ça ne soit top secret  

yep

Concernant les fees, sur 24h lancer le miner 1*24h ou 24*1h, ça revient au même ou pas ?

les fees sont randomisées à la Claymore, donc en 24h t'auras lissé le hasard sur les 0.9% théoriques. en 1h t'auras plus de variance, des fois plus ou moins.  
 
attention la 1ere minute sans fees, en gpu elle tombe sur le warmup donc t'as un peu moins de puissance. l'écart est infime mais c'est mieux de faire 1x24h. en 24x1 je gagne pas plus, mais toi un peu moins à cause du temps perdu à relancer le mineur.

Finalement, j'ai fait la feignasse : je laisse tout en auto.
C'est la honte je sais ^^
 
J'ai augmenté un peu les tensions GPU et RAM, et je suis finalement à un peu plus de 5 kH/s (cryptonight) pour 580w. La valeur de 5 kH/s est la moyenne donnée par le pool après 24h.
 
Encore merci et bravo pour ce soft !
 
Par contre une question : y a moyen de voir les éventuelles stales share ou pas ?

normalement un mineur GPU ça se tune en manual, généralement tu gagnes pas mal en perfs
 
appuie sur R et t'auras les shares accepted/ignored/rejected
ignored c'est les stales dédéctées par JCE mais généralement c'est zero. ton pool peut compter une stale sans en avertir le mineur, la plupart des pool font ça

JC t'es un genie tu cherches pas du taff ?

Il a plus besoin là, à mon avis.

 
 
Non ça va j'en ai déjà un  
 

Photo d'illustration

Salut

A quel moment tu planifie le V8/v9? 1 ou 2 jours avant?

Dit c'est quel partis de l'algo cryptonight qui consomme le plus en temps machine ? Les algos de hachages(groestl, jh, blake, skein) ou le scratchpad ?

Au fait as-tu explorer la voie des processeurs ARM, a tout hasard ?
 

Imaginons que je mine avec un CPU et des GPU avec comme hashrates:
GPU: 1800 h/s
CPU: 200 h/s
soit un hashrate total de 2000 h/s.
 
Les fees sont deux 0.9% pour les GPU et 1% pour le CPU mais qu'est-ce que ça implique exactement?
Les fees seront-elle de 1.9% x 2000 h/s ou 0.9% x 1800 h/s + 1 x 200 h/s ?
 
Dans le premier cas, miner avec le CPU très cher en fees relativement à son hashrate.
 
Le second parait nettement plus compliqué à implémenter mais c'est pourtant le seul vraiment équitable.

J'ai noté ta remarque sur Bitcointalk sur les CPU en pause et je vais l'implémenter.
 
C'est bien la 2e solution, la premiere minute sans fees permet de moyenner correctement les fees selon le hashrate, en tenant compte du fait que sur les GPU, ça tombe sur le warmup.
Mais ensuite, c'est un chiffre fixe qui, pour l'instant, ne tient pas compte des pauses. Ce qui ouvre une faille pour celui qui met un gpu et son cpu en pause pendant la première minute, puis inverse les pauses ensuite, pour avoir des fees de GPU sur le CPU. Faille que ton idée va corriger
 
Pas de ARM ni de FPGA, je suis un dev en ASM x86/x64 (et en 6502 mais ça mine pas très bien un Apple II)
 
Sur CPU, c'est 98% le scratchpad, et en v8 ça monte à 99%, sur un CPU AES.
En GPU c'est plus dans les 80% en v7, ça devrait monter à 90% en v8
 
je peaufine mon implé v8 en CPU là, j'ai une x64 qui est pas mal, je vais attaquer la version x86-32