Reprise du message précédent :

Ha oui là c'a fait très mal...
 

 
quasi 50% de hash en plus

Que xmr-stak ? Avec 8 thread ?
En automatique, le réglage des mineurs est souvent non optimal.

Bordel. si ca marche avec tout les threads..

Un Xeon Phi et ses 72 core (288 threads) et son AVX-512

C'est moi qui ai du mal

C'est surement cela. T'as de conseil pour XMR-Stack pour un Core i7 non optimisé en auto    
 
Par contre JCECpu, il n'aime pas l'hyperthreading. J'ai un serveur vmware 16core/32 hyperthreader
Ben j'ai 2 VM 8 core : 410 H\S chacune depuis la dernière version.
dès que j'en rajoute une 3ieme pour taper dans les cores hyperthreader, le Hash rate diminue de plus de la moitié.  
En gros cela donnait
Mineur 1 : 410H/S
Mineur 2 : 170H/S
Mineur 3 : 150H/S
 
Bref je reste à 2 Vm.  

Sur ton Xeon, le réglage à utiliser sera le même, cad 8 threads (le fichier de config est du même principe de fonctionnement).

T'as en gros 2 limitations : le nombre de core physique et la quantité de cache L3. L'idéal est que chaque thread du mineur puisse utiliser une unité de calcul AES-NI dédiée et avoir accès à 2Mo de L3 pour lui tout seul (je simplifie ). Dès que tu dépasses les perfs globales plafonnes voire baissent.
Sur ton Xeon CPU E5-2630 v3 (8C/16T/20Mo), l'idéal doit se situer entre 8 et 10 threads grand max. Tu devrais d'ailleurs tester avec 9 et 10 thread en modifiant le fichier de config, juste pour voir
Sur ton serveur 16C/32T, ça dépend de la taille du L3, mais ton résultat n'est à priori pas étonnant.

Quelqu'un a t'il fait le test suivant sur un Ryzen 5 1500x :
Test 1 : Utiliser juste 4T des 4C. (Utilisation uniquement du cache L2)
Test 2 : Utiliser les 8T des 4C.  (Utilisation uniquement du cache L2 et L3)

Je me pose la question s'il y a une difference notable. (Theoriquement oui, maintenant a voir dans la pratique.)

Enfin le Ryzen 1500x reste un des meilleurs* CPU pour le cryptonight sur le papier.

*: rapport prix + performance.

Merci pour vos retours, je note le bug de la detection du Kensfield comme un core2, ça sera corrigé dans la 0.13

Sur machine virtuelle, la limite physique ne change pas, deux vm ne double pas ton cache !
Et JCE ne peut pas savoir qu'une autre vm tourne. Ni même un autre jce.

Sinon, petit test sur mon skylake 1cpu / 4 core / 8mo cache
 
Xmr stak - GPU Nvdia 1070 :660H/s  + CPU : 240H/s (60h/s*4)  
 
Xmr stak - GPU Nvdia 1070 :660H/s  et JCE Miner CPU : 220H/s (55h/s *4)
 
Comment expliquer la différence? AES forcer dans fichier de config.  
 
Et l'ordi semble + souffrir dans la config XMR + JCE

Merci jesus_christ, j'ai déjà 2 Ryzen qui tournent avec JCE, bientôt 3

Je n'ai testé que sur Ryzen, pas sur les cpu intel, mon asm y est peut-être plus lent.
Aussi par défaut dans mon .bat jce est lancé en low priority
Je veux bien un test avec le minage cpu seul, parce que -10% c'est violent

Hello,
J'ai testé JCE sur plusieurs machines AES, le résultat est variable. Perso, j'utilisais plus XMRig que je trouvais plus performant que XMR Stak.
Sur un Xeon E5 2620 (HT coupé), je suis passé de 247.5 à 257.5.
Sur des i5 sans HT, c'est kifkif.
Par contre, sur des machines avec HT (surtout des i7), je suis inférieur à XMRig :
i7 4770, j'étais à 300, je passe à 284; sur du i7 7567U, je passe de 167 à 151. Je dois encore affiner les essais sur des 6700 et 6700k, mais ça tombe aussi un peu.
Quand j'aurais le temps, je ferais plus d'essais (avec et sans HT, tout configurer en manu car tout est en auto là). Les tests ont été fait sur 24h.
 
Autre point, y'a moyen de faire remonter le 'Worker Name' pour NiceHash ? Ou un tuto pour implémenter un mineur dans NH ? Ça devient compliqué à suivre quand le script tourne sur X machines

Pour nicehash, la syntaxe c'est

 
exemple :
 

 
Pour les perfs, comme c'est vraiment par cpu, ça ne m'étonne pas trop que ça déconne sur certains, je suis juste bon sur ryzen, je pourrai optimiser sur Bulldozer (j'en ai un) mais sur Intel i5/i7/Xeon ça va être plus dur
 
Version 0.13 en ligne
 
J'ai jetté un œil à XMRig et Claymore CPU, sur mon ryzen, 8 threads, avec les binaires releasé stock, je suis à 463h. Stak c'est ~501/502 et JCE c'est entre 503 et 505, avec à chaque fois les 8 huge pages dispos.
 
Il faut sûrement que j'optimise en asm bien pour intel i5/7 mais déjà sur ryzen XMRig je l'enrhume
 
Je vais intégrer le nouvel algo Monero variation-1 dans la 0.14, c'est top priorité.
Ca aura un impact négatif sur les perfs... le nouvel algo est + complexe. Pas mal plus.

J'ai regarder vite fait le nouveau code monero 0.12
 
En gros ils ont modifier juste la boucle principale avec une nouvelle fonction d'encryptage qui selon une certaine condition encrypte avec des valeurs pre-hasher ou non.
 
Tout les autres algo de hash et d'encryptage ne sont pas toucher.
 
T'as beau comprendre en gros, mais quand tu regardes leur code...
 
 
 
Bref, bon courage

J'aurais préféré qu'ils changent les 4 petits hash à la fin.
Là pour le faire bien ça va être chiant. Choisir entre un pinsrb, un movb, ou un rol en amont... Plein de tests à faire...

Résultats de mes test d'hier soir sur ma machine CoreI7 4core & Gtx 1070.
 
Donc, avant j'étais bloqué à :  
Xmrstack - gpu 660h/s (pas d'overclock de la 1070 pour le moment ) et JCe 220h/s  -> analyse perf cpu 100% gpu 100%
 
Xmstack seul - gpu 660h/s et cpu 240h/s -> analyse perf cpu 80% gpu 100%
 
Dans le premier j'avais lancé xmrstack en premier pius le jce
 
donc, hier, je lance JCE seul -> direct 245-255h/s beaucoup mieux.
Ensuite je lance xmrstack -> 660h/s et Jce reste à 245h/s -> analyse perf de ce matin cpu 70-75% gpu 100%
 
Bref, lancer XMR stack GPU avant doit réservé du cpu pour son utilisation ou bien prendre des page mémoire pour lui ce qui à bloquer le JCE à -10% de perf.
 
En gros maintenant, je reste comme cela.

Toujours sur mon Ryzen 1700:
v0.11: 625 h/s
v0.13: 626 h/s
 
Mais un tel écart n'est pas forcément pertinent. C'est peut-être seulement dû à la fluctuation du hashrate, surtout si celui affiché par JCE est l'instantané (ou presque parce qu'il se calcule forcément sur un certain laps de temps).

mais pourquoi tu mines du cryptonight avec une 1070?      

Disons que c'est une machine de test, et qu'elle sert pour le moment pour aider JCE à avoir des infos entre xmrstack et JCE miner.
 
Ensuite, j'essaye de finir le mining en xmr pour avoir le paiement, et vu que là, je suis full cpu, c'est lent même si la nouvelle version depuis 0,12, carbure en H/S
 
Ensuite tu conseillerais quoi, sachant que je n'ai qu'une seule GTX1070?

 
Bienvenue au club    

A priori tout ce qui est à base de Ethash ou Equihash.

Je mine déjà de ETH avec mes RX (6)  
j'avais testé l'ETC mais le prix ne compense pas la difficulté et les autres coins Ethash, bof bof.
 
Pareil pour l'equihash, j'ai testé du ZEC, et j'ai plutot perdu du temps pour rien, et les autres coins bof bof.
 
Par contre, je me pose la question vis à vis du XMR qui risque de prendre cher avec les Asics déjà en place. Faut regarder la puissance de calcul de certains mineurs xmr sur nanopool pour se dire qu'il va y avoir un Pb.
 
JCE, as tu prévu de viser d'autres cryptos, ou bien c'ets juste que le mineur XMR était le + facile à optimisé et sans droit de licence.  

Du coup pourquoi ne pas les mettre sur le l'ETH également. En plus ça te permettrait d'atteindre le seuil de paiement plus régulièrement.

Pour l'XMR (je réponds à sa place ), oui il y avait un gros potentiel d'optimisation concernant les CPU sans AES-NI, il avait justement ce type de CPU et l'algo Cryptonight est le seul algo rentable sur CPU.
Ceci dit, il n'est pas limité qu'au XMR !
>jce_cn_cpu_miner.exe --coins

A ça peut s'adapter à n'importe quel monnaie basée sur le même algo (Cryptonight voire Crptonight-lite).

Ensuite je sais qu'il a déjà fait quelques optis d'un mineur GPU open source, sur un tout autre algo (Ethash ?), mais on sort du cadre de ce topic.

tiens JC, peut etre un algo plus intéressant :
http://cryptomining-blog.com/9571- [...] -for-wavi/

Cryptonight v7 dans 9 jours

Nan, c'est repoussé au 6 avril, il me semble
 
Puis les derniers maj de certain mineurs intgre le switch en auto.

 
En effet, c'est le même code entre 0.11 et 0.13, c'est la détection de l'algo qui a changé.
 
draugtor : merci pour le feed super test  
 
Mon mineur GPU était une variante de XMR-Stak, donc toujours en cryptonight. Je ne le maintiens plus, faute de temps  
Il était un poil + rapide sur RX550/560
 
La prochaine version intégrera le fork d'algo Monero

Testé sur un Core i7-8700k, 6c/12t (12Mo de L3), dual DDR4-2666 (32 Go), huge pages, windows 10 rev 1709

Config forcée, j'ai spécifié coffeelake et ça utilise l'algo generic_aes, sur 6 threads, affixed to cpu 0,2,4,6,8,10.

JCE : environ 430 H/sec.
Stak cpu only, même config/affix : 432 H/sec

Chose étrange (??), les shares trouvés (plutôt nombreux, parfois des rafales de 5-6) sont toujours de valeur 2048 ou 120001

J'ai cru voir que l'--auto faisait un peu nawak (démarre sur 4 threads, il faut que je vérifie).

Je vais pouvoir tester sur un Ci3 8100 (4C/4T, 6 Mo) aussi. et sur un Opteron X3421 sous peu, ça risque d'être "marrant" (dans le mauvais sens du terme probablement ²²)

On fait comment d'ailleurs pour obtenir une moyenne 60sec / 15 min à la stak ? c'est pas implémenté ?

S'il détecte bien 12M de cache, il devrait te filer 6 threads.
 
Je viens de trouver une énorme regression sur la detection des cpus AMD, hotfix demain.
 
Je vais regarder cette histoire de hash value qui varie trop

Essai avec 12 Threads en generic_aes, tes 6T habituel en utilisant la cache et les 6T autres sans cache (bon ça sera 10 à 20 fois moins qu'avec la cache, mais tu peux gagner 15 à 25 H /s en plus )

Le mode sans cache gêne quand même les autres threads avec cache car ça tappe les tlb. Donc c'est souvent contre productif
 
Version 0.14 ce soir, correction de la detection cpu AMD + une infime optim.
Edit : + correction des Shares trop variables si j'ai le temps
 
Edit : Pour répondre à la question, JCE fait la moyenne de vitesse sur les 512 derniers hash (j'ai dit hash, pas share) par thread. Donc si vous minez à 50h/thread, c'est une moyenne de ~10s etc.
Pas de moyenne à 15mn, je ne veux pas alourdir l'interface, sur cpu le rate est plutôt constant, et les moyennes sur des longues durées c'est le boulot de ton Pool.

Cela est normal... Cela est du au pool dans lequel tu mines et sa difficulté intracec.
 
Je m'explique :  
je suis chez dwarfpool qui propose 3 difficultés en fonction de la puissance.  
Cpu / gpu simple -> 20000
Rig -> 50000
High end CPU et GPU -> 100000
 
J'ai fait un test sur les 3 difficultés avec mes mineurs de test xmr d'une puissance de 2KH/s (2 JCE cpu VM  +  GTX1070 + coreI7)
 
Voici les résultats :  
Difficulté 20000 -> Share trouvé 2048 et 20001 -> Share trouvé rapidement - share diff/H 6M et très régulier - moyenne journalière 0.004xmr
Difficulté 500000 ->    Share trouvé 2048 et 50001 ->  Share trouvé moins rapidement -> share diff/H mini 2M -> 8M - moyenne journalière 0.003 xmr
Difficulté 100000 -> Share trouvé 2048 et 100001 -> Share trouvé Rarement -> share diff/H mini 1M -> 12M - moyenne journalière 0.0025 xmr
 
On voit bien que ma puissance n'est pas suffisante pour les difficultés supérieurs à 20000 car au lieu d'avoir des share trouvé régulièrement, c'est variable voir carrément aléatoire à 100000 et que la rentabilité descend.  
 
Par contre si vous avez de bon rig ou des asic, il est plus rentable de miner aux difficultés + élevées car en moyenne vous trouverez des shares à 100000 et donc votre renta explosera.
 
Un dernier point, je vais finir jusqu'au point de paiement (fin du mois) et ensuite fini le Cryptonight. La difficulté explose vu que des asics sont arrivé sur le marché et qu'ils sont pas discret. Best mineur sur nanopool 8M H/s soit quand même 10 fois + performant que le 3 ieme qui a 0.8MH/s. Le 2ieme a 4MH/s.
En quasi 1 mois de test, je suis passé de 0.005 xmr/jour avec 1200H/s à 0.004Xmr/jour mais pour maintenant 2200H/s soit une difficulté x4.  
 
Je ne sais pas si le fork de Monero sera interessant, mais il est clair que les asics tuent les cryptos car une masse de monnaie arrive trop vite sur le marché qui n'a pas le temps de les intégrer. donc Fiat xmr dès que possible même si je perds un peu par rapport à debut mars.

 
Je teste le minage de WAVI depuis hier soir et ça fonctionne pas mal, notamment question rentabilité.
 
Mais si les Ryzen font des merveilles sur le Cryptonight, ils font pâle figure sur ce nouvel algo.
J'ai testé divers nombres de threads mais pas moyen de dépasser 565 h/s alors que des détenteurs de i7 annoncent plus de 1 kh/s    
 
Il y aura donc toujours du boulot pour JC, même après que le CN aura été massacré par les ASICs

 
Désolé pas encore de nouvelle version, j'ai une regression  
Je vais quand même voir si je peux bufferiser des shares pour lisser la Difficulté, passer de 200k à 2k c'est trop violent.

Pff le monero a encore augmenté en difficulté.  
Depuis hier avec mes mineurs je suis passé à 0.003xmr /jour... A ce rythme, je n'aurais jamais le paiement avant un mois...  
 
Ceux qui ont fait des asics, sont en train de tout syphonner... C'est vraiment une plaie. J'espère que le Fork de monero sera asics resistant, mais bon ils vont pas recommencer à 0 donc la difficulté sera la même non?
 
Tout ce travail fait par JCE... pour plus grand chose.

 
 
   
 
bah non, il aura juste à adapter un peu... d'autres mineurs l'ont déjà fait comme cast xmr par exemple

Oui, justement un mineur soft ça se change très facilement
 
La version forkée sera dispo sous peu.
Et la diff du XMR s'adapte en temps réel, donc sans les asics, elle redescendra instantanément.

Je vais faire une 0.14 intermédiaire sans le fork, avec une stabilisation des Difficultés, et une optim qui donne +1h sur ryzen (pas testé ailleurs).
 
J'ai écrit le Blake256 en asm, et cet algo est finalement bourré de constantes une fois qu'on déroule tout. Et comme il est 32-bits, on peut mettre ces constantes direct dans l'asm (en 64 bits c'est plus indirect).
 
edit : 0.14 en cours de test.
Donc nouveautés:

Question con : comment tu fais le benchmark de la perf de tes algos aussi précisément ? tu as une boucle ou une procédure de test sur une durée ?

j'ai une version de test qui ne mesure pas en H/s mais en cycles par hash (avec un rdtsc)
 
Ensuite en pratique, je suis bien vers 505,7-506 en croisière contre 504,7-505 avant, donc c'est cohérent.
 
0.14 en ligne !
 
ha oui, et en AES-32 bits (si ça existe...   oui sur Portable Atom par exemple ) gain de +0.5% (grace au Blake256 qui s'écrit très bien en asm 32-bits)
 
Edit : Mon bench était biaisé par mon remote desktop sur rig, qui bouffait de la perf, nu je monte à 507,4 le gain est donc plus dans les 0,4%
 
Par contre en changeant mes mobo de rig je crois avoir flingué mon système Excavator