Reprise du message précédent :
Quelle catastrophe cette absence du total du CPU. Je ne sais pas si je vais y survivre
 
Concernant le changement de numération, ma suggestion n'était évidemment pas de rebaptiser les versions existantes, ni même d'introduire ce changement dès la 0.30c.
Ce n'est envisageable qu'à partir de la 0.31, qui pourrait alors être nommée 0.31.0, sans que cela perturbe qui que ce soit.
Mais cette question-là n'a évidemment rien de crucial.

Le paramètre --low a-t-il le moindre impact sur le minage sur GPU?

j'ai ajouté le total cpu
 
--low aucun impact sur gpu, seulement sur cpu

Nickel, merci.
...mais sans incrémenter le numéro de version? Quelle méthode de fourbe

Quant on cherche le paramétrage optimal à tatons, les 5 minutes pour atteindre le hashrate de croisière font perdre pas mal de temps.
 
Avoir une option permettant de miner directement plein pot serait appréciable même si j'imagine que ça ne doit pas être facile à coder.
 
D'ailleurs, quelle est la raison d'être de cette montée en régime progressive?

c'est le comportement par défaut des drivers AMD et je préfère ne pas faire de hacks pour contourner ça. srb et stak font de même c'est Claymore qui poussait tout à fond dès le début.

OK, pas de souci.
 
Enfin, si, je me fais régulièrement bannir de XMRPool.eu depuis quelques jours, et je ne comprends pas pourquoi sachant que je n'ai pas ce problème avec d'autres coins sur d'autres pools.
 
Un extrait de log:

 
Non, je ne fais jamais de duplicate share, chaque share a son propre nonce. Et ce ban après un seul refus ça sent l'arnaque, qui bien sûr vient d'un pool à 0%
 
C'est le pool d'exemple de mon .bat, je pense que je vais le changer

Ce pool était pas mal durant la période faste du Monero mais j'ai l'impression qu'actuellement, il file un très mauvais coton.
 
Je suis par exemple à moins de 0.001 XMR du seuil de payout depuis plusieurs jours où mes entre 1900 et 2500 h/s ne me rapportent pratiquement plus rien (vraiment rien un jour, puis l'équivalent de 0,20€ le jour suivant, etc.. ça sent vraiment le roussi.
Il va sans dire qu'une fois ce payout atteint, je laisserai tomber ce pool foireux.
 
Sur ce, deux petites suggestions:
 
- Remplacer le "It will be long" par "It could be long" au niveau de la compilation des kernels, parce que je peux vraiment pas la qualifier de longue chez moi.
 
- Revoir l'affichage des stale shares.
Actuellement, ça se présente ainsi:
 
01:44:58 | GPU 2 Thread 10 Lane 556 finds a Share, value 33173
01:44:58 | Stale Share that may be refused by the pool.
01:44:58 | Accepted by the pool.
 
L'idée serait de fusionner les deux dernières lignes avec pour résultat quelque chose comme:
 
01:44:58 | Stale Share accepted by the pool.

J'ai enfin atteint le payout sur XMRPool.eu et puis le quitter pour toujours    
 
Mais:
Le XMR n'est plus assez rentable.
Sur le MSR, j'ai essayé trois "Duplicate Share" après seulement quelques minutes de minage sur cryptoknight.cc.
Le dernier fork de l'IPBC n'est pas encore implémenté.
Les performances en CN Heavy ne sont pas encore au rendez-vous donc exit le XRN et le LOK.
Le ARQ n'est pas assez rentable pour une nouvelle shicoin.
 
Devant cette hécatombe sur le Cryptonight, me voila de retour sur l'Ethash.
 
Une petite suggestion malgré tout: émettre un bip en cas de bannissement du pool, sur une option qui pourrait être nommée "BeepOnBan" ou "NoisyBan".
Ca m'éviterait de laisser parfois mon PC miner pour rien pendant des heures, parce que je ne surveille pas en permanence les logs.
EDIT: Un arrêt automatique en cas de bannissement serait peut-être une meilleure solution.
 
Et aussi: est-il judicieux de nommer ton mineur JCE CN GPU, étant donné qu'il peut aussi miner sur CPU? Cela peut laisser entendre qu'il faut encore utiliser JCE CN CPU en parallèle pour miner sur CPU.
JCE CN tout court ne serait-il pas préférable?

Encore une shitcoin à ajouter:
 
Private Pay '(XPP)
Cryptonight Fast: --variation 11
https://goprivatepay.com/
https://bitcointalk.org/index.php?topic=4496100

Je crois que j'ai une regression sur les duplicate share, apparue quand j'ai upgradé le netcode pour nicehash. Finalement, c'est de ma faute
 
Je suis en train de faire le fork Bittube-v4
 
Je saute le shitcoin pour cette fois pour gagner du temps, je fais la 0.30c avec le fix de duplicate-share et le Bittube-v4

Pas de souci. L'erreur est humaine et tout ce qui importe est qu'on ait une solution au final.
 

Merci. Je l'attendais celui-là
 

L'intégration des shitcoins est toujours à mettre en dernière position dans la liste des trucs à faire, puisqu'il est toujours possible de les miner avec le paramètre --any.

bonnes idées, je vais mettre le Stale sur la ligne du found, et ajouter une option de quit en cas de ban, il y a déjà une option de quit en cas de pb réseau (-q)

Salut !

Je n'ai jamais miné mais j'aimerais tenter en minage CPU, j'ai un peu lu la premiere page mais j'ai des petites questions en sachant que je ne cherche pas forcément a être vraiment rentable ou quoi c'est plus pour essayer pour commencer.

Quels sont les prérequis ? Un porte monnaie je suppose ? une connexion internet et un Pc ?

Quelles sont les différences entre AES et Non AES ? c'est en fonction du CPU ?

Dans toutes ces monnaies lesquelles sortent du lot et plus généralement quelles sont les différences ou comment choisir ?

Plus efficace sous windows ou linux ? avec une paire de xeons E5620 dans un serveur HPE y'a possibilité de faire un truc rentable ?

Merci d'avance !

Ton processeur supporte les instructions AES-NI, ce qui est une bonne nouvelle en terme de perf&rentabilité.
Ceci dit, trouvé un CPU similaire, mais il semble que ce ne soit pas rentable... sauf si tu ne payes pas l'électricité (gain d'environ 3€/mois et par CPU pour du CryptonightV7/Monero).
Bref, fallait plutôt s'y prendre en début d'année

Pas répondu à toutes tes questions, peut-être devrais tu lire le 1er post du topic suivant et éventuellement y poser tes questions sans réponse :
https://forum.hardware.fr/hfr/Discu [...] 7766_1.htm

Justement, l'avantage c'est que l'electricité est gratuite la ou ce serveur se trouve  
 
Merci pour le topic !  
 
Par contre, il est détecté en tant que virus quand je le télécharge
 
Et du coup efficacité entre linux et windows ?

C'est un problème commun à pratiquement tous les mineurs: Phoenix, Claymore, SRB, SGMiner, BMiner...
Tous sont vus à tort comme étant malfaisants, mais ne s'agit que de faux positifs.
Il suffit de les mettre en liste blanche (exclusions) pour que l'antivirus arrête ses excès de zèle.

Les raccourcis clavier (h pour les hashrates, q pour quitter,...) sont sensibles à la casse, ce qui m'a valu de chercher pourquoi ils ne fonctionnaient plus jusqu'à voir que j'avais Caps Lock activé par erreur.
 
A moins que cette sensibilité à la casse ait une justification, comme une ultérieure distinction entre H et h par exemple, y mettre un terme me semble préférable.

bonne remarque la casse, je vais corriger
 
pour commencer :
https://github.com/jceminer/cn_cpu_ [...] ng-started
 
le minimum c'est de créer ton wallet (note tous les codes !!) puis change le dans le start.bat et c'est bon, laisse tout le reste par défaut.
 
les versions Windows et linux sont exactement les mêmes.

salut
 
ca a l air tres prometteur tout ca
 
par contre c est chiant de perdre du temps a recompiler les kernels a chaque fois,y a pas moyen de reutiliser?
 
je pense comprendre pourquoi j ais un rig de 580 qui se met a reboot par moment:au meme reglage des autres cartes ,le hashrate d une est merdique, 150 pour 930,suis en train de voir a peaufiner les reglages avec ton soft.
mais du coup srb me la fais bien miner ,avec le bon hashrate mais reboot parfois.
 
ton soft est plus sensible?

J'ai déjà pas mal bassiné JC à ce propos
Sa réponse la plus précise est sur bitcointalk.
 
En gros, il tient à éviter le vol de son code, notamment de ses kernels, et le seul moyen de l'éviter est de les générer en live directement sur les cartes graphiques, sans même en avoir un exemplaire en RAM.
Chaque kernel est en plus différent, adapté au GPU, à la VRAM, aux paramètres définis et je ne sais quoi.
La recompilation du kernel de chaque thread au démarrage est donc inévitable.

Un minuscule bug:
 
Les données JSON font état de la version CPU de JCE alors qu'il s'agit de la GPU + CPU.
 
  "miner":
  {
     "version": "jce/0.30c/cpu",
     "platform": "AMD Ryzen 7 1700 Eight-Core Processor ",
     "system": "Windows 64-bits",
 
 
Je pense d'ailleurs qu'il serait temps de ne plus différencier les deux vu que la version unifiée est voué à être la seule au final, qu'elle l'est déjà pratiquement de fait, et qu'elle permet de ne miner que sur CPU à ceux qui le souhaitent.

Je ne sais pas si JCE est plus "sensible", là ça devient du cas par cas.
 

Pour garder mon niveau de sécurité actuel, pour l'instant, oui.
 
Erreur dans le json en effet, je vais corriger.
 
Les deux versions vont coexister, car la version CPU
1. N'a pas besoin de opencl.dll pour démarrer (la GPU si, même avec --no-gpu)
2. Existe en 32-bits
3. Existe en Linux

daccord pas de soucis
 
par contre je retombe sur mon vieux demon,le rig qui reboot toutes les x heure ou x minutes et ce sans aucuen erreur mem

avec JCE ou SRB ou n'importe quel mineur ?

Ça me l as fais avec srb,puis du jour au lendemain fini.

La ça me le refais avec jce,je perd trop de temps suis repasser a srb.

Il vas vraiment falloir que je trouve ce qui ne vas pas.

L ordre des cartes sous jce est le même que srb ou pas?

tu dois être trop près de la limite de la vram. baisse multi_hash, ou alpha.
 
j'utilise l'ordre de opencl, je ne sais pas si srb fait pareil désolé
 
version CPU 0.31a en ligne.

L'ordre des GPUs variaient déjà d'un mineur à l'autre avant JCE.
Le principal est que cet ordre pour un mineur donné ne varie pas au fil du temps.

La section hashrate des données JSON mériterait d'être remaniée.
 
Un exemple actuel:

Les thread_xx sont redondants avec la sous-section thread_all. Personnellement, à choisir, je supprimerais les thread_xx pour ne laisser que la sous-section thread_all.
 
En l'état, la sous-section thread_gpu devait plutôt être nommée gpu_total ou gpu_subtotal parce qu'elle contient les totaux par GPU et non par thread des GPU.
Idéalement, cette sous-section devrait être nommée quelque comme subtotals et contenir en plus le total du CPU

J'avoue que j'ai baclé mon JSON, on me l'a reproché aussi sur GitHub. Je pense le remettre à plat avec la version "non-proto" de JCE GPU.
 
J'ai ajouté ton idée de pause par GPU avec 0-F, mais je n'ai pas trouvé de moyen élégant de mettre le Stale sur la même ligne, donc là je vais le laisser sur une ligne séparée.
 
J'expérimente des optims sur Heavy

Cool, non que la version actuelle était inexploitable mais il est vrai qu'elle est améliorable de bien des façons.
Elle a tout de même le mérité d'exister et de permettre de connaître les hashrates sans les impacter.
 
J'espérais pouvoir pondre une page html qui ferait office d'interface graphique pour tes données JSON, avec notamment une représentation des hashrates sur des graphiques, mais à l'instar de Windows 10 qui m'empêche d'accéder à mes propres fichiers, Firefox refuse l'accès à ces données (actuellement dans une iframe) de la page en question:
 
SecurityError: Permission denied to access property "document" on cross-origin object
 
La seule solution serait donc un fichier PHP et même idéalement une base de données, qui nécessiteraient donc un serveur web, mais ce serait trop lourd à coder comme à installer au vu de ce que ça apporterait.
Cette idée d'interface graphique est donc bien partie pour ne jamais se concrétiser    
 

Sympa ça mais s'il te plaît (et même si ça ne te plaît pas d'ailleurs ), n'oublie pas la pause du CPU seulement, parce que c'est surtout elle qui me fait défaut.
 
Pour ce qui est de l'affichage des stales, on devrait pouvoir s'en remettre
 

On doit être un paquet à les attendre celles-là

En crypto heavy, le jce est au top?
C’est à dire au moins aussi bon que les meilleurs?

A priori non, justement. Le CN Heavy est le seul algo sur lequel JCE reste pour l'instant derrière ses concurrents, notamment SRB, d'où les optimisations à venir que beaucoup attendent avec impatience

J'ai pris le temps de mettre à jour la first page HFR.
 
JCE est le meilleur... en CPU, surtout avec des threads no-cache qui t'ajoute qlq h/s en plus.
 
En GPU je viens de sortir la 0.31c qui devrait améliorer un poil la situation.

Test de la 0.31c sur le CH Heavy, après avoir bien bataillé sur le paramétrage:
 
RX 580 4Go de mémoire moisie:

=> 805 h/s, ce qui semble correct pour du CN Heavy mais sans plus.
EDIT: Le hashrate finit par s'effondrer à 130 h/s. Le CH Heavy et cette carte graphique ne font décidément pas bon ménage.
 
RX 570 8Go de mémoire top:

=> hashrate très fluctuant mais dont la moyenne se situe vers 1015 h/s  

Le relancement du CPU après une pause semble perfectible:

 
A noter que je l'avais mis en pause via la touche U alors qu'il était le seul à miner.
Ce problème de reconnexion ne se serait sans doute pas produit si j'avais utilisé la touche P, mais le miner devrait de lui-même procéder à une pause totale si l'élément mis en pause était le seul à miner.

Il semblerait finalement que, quelle que soit la variation (l'algo), la config idéale pour une RX soit
 
{ "mode": "GPU", "worksize": 4, "alpha": 64, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, ...},
{ "mode": "GPU", "worksize": 4, "alpha": 64, "beta": 8, "gamma": 4, "delta": 4, "epsilon": 4, "zeta": 4, ...},
 
Je n'ai trouvé ça qu'à l'instant, car il me m'était pas venu à l'idée de tester une combinaison worksize & alpha aussi éloignée que celles publiées ici et là.

Salut

Ais tester hier. En cn7
Un truc que j aïs pas compris: les cartes se sont mise a hachee a +200h de leurs 'normalité' puis après :block rejected 5 ou 6 fois,puis hash =0.

Je me suis dis ,il a plante mais non c est revenu normal.

?

Lorsqu'on monte le multi-hash au-delà de sa valeur optimale, le hashrate:
 - baisse
 - devient instable
 - tombe à des valeurs ridicules
 - reste à 0
La dernière étape étant le plantage de la CG ou de son driver.
 
Trouver les bons réglages prend du temps mais ça en vaut la peine.

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.