Reprise du message précédent :
0.29a en ligne
pas de gros changement, nouvelle feature : Pause (touche p)

Merci  

Là je bosse sur la version OpenCL

Mets toi au VERILOG tu gagneras du temps

La fonction Pause pourrait avoir besoin d'une amélioration.
 
L'avoir utilisée pendant quelques minutes m'a valu d'être jeté par le pool.
Un relancement de l'exécutable l'a remis sur les rails.
 
Je n'ai hélas pas noté le message d'insulte du pool, et je ne suis pas très chaud à l'idée de me faire bannir volontairement.

ok il faudrait se reco quand on un-pause, je note

J'ai retesté la pause à deux reprises:
 - pause de 4 minutes: RAS
 - pause de 14 minutes: BOUM:

Le pool en question: graftpool.network:5555

ok je vois, je gère mal la pause dans le netcode. je vois comment corriger, merci !

 
HS: J'ai le chic pour choisir les pools les plus désertiques, et celui-ci en est un bon exemple.
Pour miner du GRF, mieux vaut en choisir un autre qui soit un minimum fréquenté.

Une autre idée d'amélioration: une pause automatique.
 
Cette pause s'activerait automatiquement dès qu'un des logiciels dont la liste serait renseignée dans un fichier de config serait détecté parmi ceux lancés.
Le minage reprendrait dès que plus aucun des logiciels listés n'est détecté.
 
Ca m'éviterait notamment d'oublier le le relancer après avoir dû l'arrêter, après un jeu, un encodage vidéo ou quoi que ce soit nécessitant pas mal de ressources matérielles.

bonne idée ergonomique, mais incompatible avec la charte JCE (en bas de la doc en anglais) qui promet que jce ne scan rien sur le pc, sauf les cpu.
donc non car serait vu comme intrusif. déjà qu'il est flaggé comme virus
 
j'avance sur la version gpu, je compte faire une version pure cpu, et une version cpu+gpu. il sera possible de désactiver l'une ou l'autre partie avec --no-gpu ou --no-cpu.
 
 
edit : tu peux lancer jce avec start /low jce….. pour qu'il soit idle donc ça revient un peu au même...

Dommage.
L'important n'est pourtant pas qu'un programme ne scanne pas de donnée confidentielle qui serait utile à son fonctionnement, mais qu'il ne la transmette nulle part.
 
J'imagine que permettre de désactiver cette fonctionnalité via une option dans un fichier de config où elle serait désactivée par défaut irait aussi à l'encontre des termes de ta charte?
 
Cette fonctionnalité se retrouve sur VidCoder, et c'est elle qui m'avait fait choisir ce logiciel plutôt que Handbrake lorsque j'encodais avec un Q9450 qui était rapidement à genoux.
 
Pour la version CPU + GPU, le top serait de pouvoir en plus tout activer / désactiver via des touches:
 "C": CPU
 "0": GPU 0
 "1": GPU 1
 "2": GPU 2
...
 "A": GPU 10
...
 "F": GPU 16
et osef les rigs à plus de 16 GPUs

j'ai une question un peu bête, désolé... Je ne parviens pas à trouver dans Avast la fonction qui me permet d'autoriser le programme.
Du coup, je suis obligé de désactiver les agents quand je le lance, pas top.
Quelqu'un pourrait-il me guider ?

Je passe pour Avast, je ne connais pas et préfère ne pas dire de bétise
 
Pause : un autre point qui me chiffone, c'est que ça ferait de la config un peu lourde (même si optionnelle) et du code différent entre windows et Linux. Pas mal de compléxité. Ce rôle est plutôt pour un gestionnaire type Awsome Miner qui peut pause et de-pause son mineur (JCE ou autre).
 
Par contre j'aime bien ton idée de la pause de GPU

 
Question piège : si j'appuie sur 'C' c'est le CPU ou le GPU 12 qui pause ?  

Effectivement, je n'avais pas pensé à la complexité de la gestion de plusieurs environnements d'exploitation.
 

J'ai en fait tiré cette idée de PhoenixMiner, mais ce dernier doit être en grande partie pompé sur Claymore    
 

Euh... la touche "P" pour le CPU n'est peut-être pas si mal réflexion faite    
Mais il pourrait aussi être assigné à la touche "0" si les GPU commencent à 1.
 
Sur ce, j'en reviens au principe de quelques lignes fixes en haut de la fenêtre.
Sans aucune modification du log qui continuerait de défiler en-dessous comme actuellement, ce petit cadre récapitulerait les informations essentielles comme par exemple:
 - l'activation de chaque "périphérique" (CPU ou GPU) où "_1_34_" signifierait que le CPU et les GPUs 2 et 5 sont arrêtés tandis que les 1, 3 et 4 sont actifs.
 - le hashrate global
 - le hashrate de chaque périphérique
 - le nombre de shares acceptés, stales  et rejetés avec la proportion de ces derniers.
 - l'uptime du logiciel

Deux doléances mineures:
 
 - L'ajout du Saronite (XRN) à la liste des coins supportés
 - Le classement par ordre alphabétique de la liste des coins supportées affichée par --coins

vendu !
je suis toujours sur la version gpu, j'attaque des optims en assembleur cgn. mais je garde le OpenCL en secours.
 
saronite est déjà dans la 0.29b qui n'est pas officielle car j'a pas fini la Linux mais dispo sur GitHub.

Hello, est ce que jce miner prend en charge la nouvelle version cryptonight Light V7 de l'Aeon ?
 
J'ai des messages d'erreur si je laisse la détection automatique en rem Fork=0 (low  
 
Pas de messages d'erreur en rem FORK=3, mais il a les perf d'un cryptonight normal du coup.
 
Edit : en fait le message d'erreur concerne un "Low difficulty share" malgrés le bon port. Je n'ai pas le bug sous xmrig par exemple.

N'est-ce pas plutôt --variation 4 pour l'AEON?

c'est 2 pour la aeon historique et 4 pour le nouveau v7 light du turtlecoin. je n'ai pas eu le temps de suivre un eventuel nouveau fork

Nickel, ça fonctionne avec 4 ! (oui, y'a eu un fork de l'Aeon le 3 Juin, afin de mettre les nouveauté du Xmr V7, et de le protéger entre autre des Asic)

ok il faudra que je passe le Aeon en fork 4 par défaut

Version 0.29c en ligne
 
La version Linux arrive, pas encore en ligne.
La prochaine sera une version GPU

petit retour de ma part 410h/s sur 6 cores : ryzen 5 1500x

Je n'ai jamais été calé en réseau. Vous m'excuserez donc cette question de noob.
 
J'utilise Windows Firewall Control pour gérer le pare-feu de Windows 10 configuré pour bloquer en entrant comme en sortant tout ce qui n'est pas autorisé par une règle.
C'est là que Windows Firewall Control facilite bien les choses puis qu'il permet d'autoriser un programme plus rapidement et simplement qu'en créant manuellement une règle dans le pare-feu.
 
La première fois, curieusement, l'autorisation définie par ce logiciel ne fonctionnait pas pour JCE_CPU. J'avais résolu le problème en créant les règles manuellement.
 
Mais je viens de réinstaller Windows 10 LTSB et cette fois, même des règles manuelles sont sans effet. La seule solution pour que JCE_CPU parvienne à se connecter au pool est d'autoriser par défaut toutes les connexions sortantes, ce qui ne fait pas, mais alors vraiment pas mon affaire.
 
Ce qui est louche, c'est ce que ce problème ne touche que JCE_CPU, alors que j'ai plein d'autres programmes, pas seulement de minage, qui n'ont aucun problème de connexion.
 
La connexion de JCE_CPU aurait-elle quelque chose de spécifique?
 
Je peux produire une flopée de captures d'écran pour illustrer le problème mais ça polluerait sans doute le topic.
 
EDIT: j'ai testé tour à tour des règles automatiques puis manuelles, sans jamais qu'aucune ne fonctionne.
Comme je ne puis laisser mon pare-feu ouvert aux quatre vents, je dois renoncer au Cryptonight par CPU  
En effet, n'étant pas désireux de passer sur un autre programme moins performant, j'aime autant changer carrément d'algo mais reste à en trouver qui soit un minimum rentable sur CPU.

sans doute du au fait que ma version 64 Bits masquerade son process en attrib.exe, c'est à lui qu'il faut donner les droits. un bon test serait d'essayer la version 32 Bits voir si elle passe car elle n'utilise pas cette technique.

Bingo: en autorisant attrib.exe, plus de problème de connexion.
Merci.

J'ai hélas d'autres bugs, avec la 0.29 en voulant miner du IPBC sur mining.bit.tube:15555
 
a) "--variation 0" aboutit à la section du Cryptonight Heavy, la 5 à priori, alors que l'IPBC nécessite la 6: Cryptolight-IPBC
 
b) Le log affiche "Bixbite (BXB) Mining session starts!" au lieu de l'IPBC
 
La 0.29b fonctionne nickel. Je la conserve donc dans l'attente de la prochaine release.

la 0.29c a des soucis de selection d'algo, on m'en a reporté sur bitcointalk aussi. je l'ai un peu baclée pour passer à la GPU je vais faire un hotfix.

0.29d dispo (version Linux en cours d'upload)

Elle apporte le GPU ou c'est juste une correction de la 29c ?

correction de la 0.29c
Si tu ne mines ni BXB, ni BLOC ni IPBC, elle n'apporte rien.
 
La 0.30 sera en GPU+CPU.

Vivement cette tant attendue 0.30.
SRBMiner ne gère pas le fork du MSR et à supposer que XMR-Stak le gère, j'ai la flemme de le compiler juste pour ça.
Tous les développeurs ne sont pas aussi réactifs face aux différents forks, ce qui fait un bon point pour JCE.

Le FAST ? Bien sur que si SRBMiner le gère !

Encore fallait-il savoir que le fork du MSR est le Cryptonight Fast  
Merci pour l'info en tout cas

en effet, je vais le préciser dans ma doc, c'est ambigu
Merci

Ce n'est pas à toi de le préciser puisque c'est déjà fait à travers l'aide qui mentionne bien "Cryptonight-Masari fork of June-2018", mais plutôt à SRBMiner qui se contente de mentionner "Fast".
Tout au plus pourrais-tu changer la désignation de la variation 11 en "Cryptonight Fast (MSR June-2018)" mais ce serait presque faire du zèle.
 
En l'état, quelqu'un qui, comme moi jusqu'à récemment, ignore que le CN Fast est le fork du MSR peut miner avec JCE CN alors qu'il ne peut pas avec SRBMiner à moins évidemment de tester toutes les variations une par une mais comme il est nettement plus long à démarrer, c'est assez lourdingue.

En utilisant les bonnes ressources on sait tout de suite qui utilise quoi.
 
https://masari.miner.rocks/

 
solution retenue