Reprise du message précédent :

 
ah bha ça doit être ça !
Sympas NH,  
 
c'est quoi la solution ?
Ne plus miner sur NH ?

Si tu ne soumets pas de share, au bout de 10min t'es automatiquement déco. Les mineurs gèrent la reco, rien de grave à part la perte dû au délai de reco (traité spécifiquement par JCE).
Or il arrive qu'à force de se faire déco, on subisse un BAN temporaire (quelques heures du peu que j'ai vécu). Ca m'étais déjà arrivé pendant quelques jours le mois dernier et depuis plus rien, mais j'ai à nouveau eu ce matin. J'imagine que lorsqu'ils ont besoin de faire un peu le ménage niveaux connections actives (en cas de grosse charge par ex), ils finissent par banir temporairement les IP qui ont été déco pour inactivité un certains nombre de fois (incluant donc les mineurs CPU à faible hashrate).

Je me demande s'il ne faudrait pas réagir pro-activement en provocant une déconnexion quelques secondes avant la déco auto des 10min de NH.

Testé sur un Ci3-7100 (Kabylake, 3.9 Ghz, 2C/4T), en dual DDR4-2133, no huge pages, win 10 rev 1709, process exclus dans defender

En laissant tout en auto par défaut, le décompte de coeurs et d'archi ne marche pas. Il ne tourne que sur le thread 0, en generic sse3.

J'ai forcé via -c configfile le lancement sur deux threads sur le CPU 0 et 2 en kabylake : ça tourne bien sur deux coeurs, mais toujours en generic sse3 (normal peut être ?)

Petite surprise sur les scores :
JC : ~56 H/s sur deux threads (sur 4 thread on perd comme prévu un peu, entre 2 et 3 H/s)
XMR stak : ~64 H/s

Hello tous !
 

 
Pas de surprise : KabyLake a le AES, donc XMR Stak y est meilleur. Ma future version AES va le battre
Faut que je regarde pourquoi il a merdé sur l'autoconfig
 

 
Pas normal, c'est ma plateforme de test principale (enfin un L5408 OC@2.66 mais c'est exactement pareil 4 core 12M de cache) et je pousse à 116. T'aurais pas oublié d'activer les Huge Page ? Ou utilisé la version 32 bits ? Sur cette dernière je suis à 91 sur ce cpu.
 

J'ai fait un message + explicite dans la 0.9, que vous trouverez en 1ere page
 
edit : il y a un soucis avec la 32-bits, faut que je regarde ça, revert

yoyo
 
J'ai pas de messages d'erreurs lorsque je mine en mode admin,
et en théorie, j'ai activé les Huge Page
 
Par contre en effet ça doit monter un peu si je n'utilise pas l'ordi.
Me suis fait kicker de NH,
Je vais trouver un aut' moyen de miner, peut être du turtle après tout.

Tu ne peux plus te connecter à NH, même pas sur le serveur usa ?
 
Les taux que j'affiche, c'est avec le mineur seul bien sûr
Si les Huge Page merdent, il y a un message en rouge, donc tu dois les avoir oui

 
La surprise pour moi était dans le bon sens, je m'attendais à plus d’ecart en défaveur de ton build comparé à stak en AES  
 
(Note : on se connais Monsieur, si tu te souviens bien, à l'époque de la "guerre" des rippers de DVD, quand je faisais mes filtres SECAM et translation virtualdub, avec Blacksun et toute la clique...)

Mmmh, c'était il y a 20 ans mais oui, avec DVDRIPP, c'est loin mais oui je me souviens. J'avais même été modo quelques temps sur HFR
 
Version 0.9 corrigée, mais le --elevate en 32 bits plante toujours

D'autant plus étonnant que tu n'a pas les huge pages. Une raison à ça ?

 
si je pense mais faut que je change de serveur toutes les X minutes

he ben c'était plutôt simple et rapide le TurtleCoin !
 
Voici des screens, j'ai toujours un thread de perdu avec le i5 ??
V0.8
i5 3 Thread donc : 115 H/s ( 38 / T )
Q9650 : 100 H/s ( 25 / T environ )
 
Edit : ok tu m'as dit 32 Bits
Re - Edit : la version 32 bits se lance pas sur la v0.8
 

 

J'ai eu le cas dernièrement, moralité, j'ai passé les mineurs JCE sur dwarfpool XMR et sa mine sans déco, bon je suis à 30cts/jour mais au moins je fais progresser la science  

dulos : La 0.9 corrige un bon bug de la 32 bits tu peux retenter, mais si t'as un Windows 64 préfère la 64 elle est pas mal plus rapide.
 
Le core du i5 perdu c'est parce que t'as 6M de cache, donc 3x 2M.
Cette limitation sera contournée mais je dois faire plus de tests avant de release.
 
100 sur ton Quad c'est décevant tu devrais être vers ~115

6Mo de L3, donc théoriquement 3 thread est l'idéal. T'as testé manuellement avec 4 ?

Ha c'est donc ça le thread supplémentaire à 40% de CPU ?
Une version pour ceux qui n'ont pas assez de cache

 
Plutôt 15/16, n'allons pas trop vite ²²

 
Poste que je livrais cet aprem, pas eu le temps de trop m'amuser avec...

 
Faut que je trouve comment faire
 
65 TRTL de miné, à moi la richessssssse
 

 
J'ai fait plus de tests sur la version 32 bits, c'est une catastrophe, il faut vraiment que je la stabilise

Tu copies le fichier config.example.txt en config.txt (par ex) et tu modifies ce dernier pour mettre 4 lignes dans le "cpu_threads_conf" (ce qui semble être déjà le cas par défaut).
Ensuite dans ta ligne de commande, tu supprimes le --auto et ajoutes -c config.txt

version 0.9a en ligne, c'est un hotfix qui invalide et remplace la 0.9
 
Le 32-bits marche bien à présent, avec le --elevate
la 64 n'a pas vraiment de changement
 
J'ai fait un test sur un Atom ultra-low-power 32-bits avec 2x 1M de cache, sur 4 cores, et qui mine donc sur les cpu 0 et 2.
12 h/s  
avec mon futur mode top secret je monte à 14  
en mettant manuellement 4 threads complets, je monte à... 20
 
Le 14 est encourageant, même si on est loin des +40% que je vous fais miroiter.
Le 20 avec quatre threads provient sûrement du Atom qui doit être tellement lent en calcul, surtout sans AES, que le manque de cache n'est plus un soucis à ce niveau. Je prends ça pour un cas particulier. Il faudra que je teste avec un vrai Ryzen qui a plus de cores que de cache.

 
Merci pour le twix
Avec 4 thread suis à 115 H/s
Pareil qu'avec 3 donc ! Mais avec en prime un ordi assez lent
 

T'es donc un bon candidat pour la prochaine version

Hanéfé c'est le cas ideal pour le test du Thread mystère  

Mets le paramètre --low ça sacrifie 0.1% de perfs en échange d'un pc qui rame pas à mort

Pour minergate, ce serait cool, étant donné que je suis un grand paresseux !
 
Merci

Je vais faire un support générique pour les pools avec Login.
Nicehash restera un cas géré à part

Moi j'attends maintenant la version AES.  
 
Je mine du monero sur dwarfpool, et depuis j'ai arrêté d'avoir des déconexions. Nicehash, c'est vraiment bof, ou alors juste pour tester pendant un temps.  
Et leur ban, c'est n'importe quoi. mais bon, là c'est mieux.
 
Sinon, tu ne fera pas de mineur GPU + CPU avec Nvidia      par ce que cela serait interessant pour moi.
 
Pour ceux qui connaisse XMR-stak vous faites comment pour voir les Hashrate?

Il faut appuyer sur la touche h non ?
Mais c'est pas très lisible.

 
Les hashrates sont aussi affichés automatiquement à l’intervalle exprimé en secondes dans le fichier config.txt:

Je viens de voir qu'il faut aussi mettre le verbose en mode 4 pour avoir toutes les informations.
 
merci pour l'infos

Sur JCE c'est automatique, et l'intervalle est de 240s environ.

Version 0.10
Support de plus de pool exotiques.

Merci.
tests concluants sur minergate/xmr
Vivement une version linux pour mes serveurs sans GPU

Ça va tarder la version linux, ma pile de taches là c'est le AES et le mode low-cache pour les cpu qui ont plus de core que de cache.

no-probs
Bon boulot

^^^^ Je vais virer mes vm linux et mettre vm windows.  LOL

Merci du feedback.
J'ai simplifié mon code sur les pools exotiques, si vous voulez en supporter d'autres dites moi ça sera simple.

Je lève le voile sur la prochaine grosse feature de la 0.11
 
Le Dual Mining
 
Pour faire simple, ceci consiste à utiliser les creux d'un algorithme pour piquer des ressources et les prêter à un autre thread qui va miner un peu autre chose pendant ce temps, puis rendre la ressource au thread principal.
 
Le cryptonight s'y prête car il alterne des phases où il bourrine son cache avec d'autres où il bourrine ses registres. L'idée est donc d'avoir deux threads décalés qui font l'un et l'autre alternativement. Et oui ça veut dire qu'on va dual miner du XMR avec... un autre XMR  
 
Il y aura donc des threads maitres, qui auront du cache et une huge page à eux, et des threads esclaves qui emprunteront le cache et la huge page du maitre pendant que ce dernier est occupé avec ses registres, pour miner un peu.
 
En théorie, ça peut doubler les perfs.
En pratique ce n'est bien sûr pas le cas :
• Les parties registres et mémoire ne sont pas de 50/50 l'esclave ne peut pas avancer autant que le maitre
• Le transfert de ressources et la synchronisation des threads a un léger coût.
 
J'ai +40% sur mon core2 et +16% sur un Atom. J'espère que ça sera un bon chiffe sur Ryzen
 
Il est possible de caser deux voire trois esclaves sur un maitre, mais le gain devient faible, c'est pour le cas rare des CPU avec 2M de cache mais 3 (rare, Athlon x3 ?) ou 4 cores.
Ou 4M avec plus de 3 cores.

Nickel, Tu vas plus t'arreter ?
 
Question au pro : sur un dell r720 , vaux t il mieux faire une vm unique avec tous les proc ou faire plusieurs vm avec 1 vcpu 1 coeur
 ou autre ???

Je dirais une vm avec tous les cpu

 
Beau boulot
J’attends avec impatience cette v11 avec tous mes Ryzen
 
Si elle est efficace tu vas devenir le maître du monde