Reprise du message précédent :

Ok ok Je crois que j'ai rien de tout ça sous la main j'ai bien une base en 775 je sais pas ce que c'est le proco et le rig est pas encore "allumable" donc je verrais ce que ya dessus

J'aimerais tellement comprendre ce que tu comprends en lisant mon pavé

et paramètre --hfr pour les fees plus basses, je l'ai fait pour vous, utilisez-le !

Je fait du tutlecoin ( codage monero) , tu pourrais rendre compatible STP.
 
Merci

*Turtle Pardon

ok je mets ça dans la prochaine version.
un autre coin demandé ?
Tout sauf AEON car il a une implé différente.
 
Je rapelle que Nicehash est considéré comme un coin à part entière, avec un wallet de Bitcoin.

 
Juste une version ryzen qui me sort 1kh/s c'est tout  

le mineur marche correctement mais plante quand je le démarre en admin (--elevate ou via propriété sur le raccourci)

La topologie de tes caches et tes core. C'est très compliqué sur ryzen, mais mon algo --auto a l'air de s'en sortir.
sur core2 c'est un cpu == un core c'est facile  
 
Il me faut un vrai ryzen physique pour tester. Je n'ai que du vieux matos là.
 
Ceux qui ont du 775 je veux bien des retours. C'est le kernel dont j'avais déjà parlé, avec encore +1% d'optims, et un core2 quad @ 3G devrait envoyer ~128h

plante : vrai crash ? t'as quel windows ?

windows 10 home 64bits avec un i5 2400 et 4go de ram qui sort 76 h/s (en --auto donc 3 cores)
 
la fenêtre s'ouvre et se referme en 1/2 seconde en mode admin, sinon ça fonctionne

si tu peux mettre un log (paramètre --log <file> ) et me mettre le log ici ça m'interresse. Ça ressemble plus à un pb de config qu'un crash, mais tout de même
76h c'est pas top, même si c'est sans AES, à 3.4G je m'attendais à ~90h

@jesus : tu devrais mettre ton mineur sur github, ce sera plus facile pour les rapports de bug

Release uniquement sur HFR pour l'instant, avec une version spéciale, ça ira sur Bitcointalk ensuite.
 
Github c'est plus pour le code source, et là c'est pas open. Ce qui est légal car mon code est 100% de ma main

 
ça fluctue entre 65 et 85...
 
sinon pour le log, il s'enregistre bien si je lance en mode normal mais en mode admin, il enregistre rien, il n'y a pas de fichier

mhhh, windows parfois change le path courant quand on est en mode admin, ça peut être ça. Merci du retour
 
ça fluctue ? le hashrate sur CPU est normalement ultra stable, tu utilises ton PC en même temps ?
 
edit : tu utilisais le mode --auto ?

oui --auto, peut être à cause de teamviewer, je ne sais pas mais oui ça fluctue

Sur mon C2Q@3.2GHz (Kentsfield, donc sans SSE4) :
118 vs 133
JC wins

Je suis en "--auto --low" et je n'ai pas l'impression de gagner qqch en virant le --low. C'est l'assembly kernel "core 2" qui est utilisé.
Le hashrate affiché, c'est l'instantané ou une moyenne glissante, valeur réelle ou en retranchant les fees ?

le --low fait perdre 0.01% de perfs en échange d'un pc qui rame pas à mort, donc c'est un deal gagnant. Il est par défaut dans mon .bat d'exemple.
 
c'est un hashrate instantané, valeur réelle physique, exactement comme Claymore. Les fees sont volontairement opaques, la règle c'est que 2% (ou 1.5% avec --hfr) des shares sont pour moi. Quand, comment, où, c'est un secret industriel à présent.
Les chiffres sont fair, le hashrate est exact, et les N% de fees c'est vraiment N%. Et pas de fees la première minute, pour ceux qui veulent juste bencher sans rien me donner.

Ca a l'air de bien tourner (sauf les déco toutes les 10min à cause de NH).
Beau travail

Ton progamme marche sur tout les CPU ou bien uniquement AMD comme l'ancien?

Absolument tous les CPU x64, du vieux pentium4 au dernier Ryzen.
 
Mais les perfs++ c'est pour les p4 et les core2, sur un bon CPU récent (ryzen, core i5, i7, athlonFX...) xmrig est pour l'instant meilleur car je n'ai pas encore inclus mon code optimisé pour CPU récents.
 
Tu peux tenter de toute façon, mets --auto et tu verras.
Paramètre --hfr pour me donner moins de fees, ou --autoclose 1 pour zero fees, limité à 1mn

jesus_christ> 'kentsfield' c'est un alias de 'core2' ?

Faut que je vois ce que je peux faire pour ça.

Pour l'instant oui. Si tu configure manuellement "kentsfield" ça restera sur core2.
Mais je ne pense pas qu'une optim dédiée à kentsfield puisse créer un gain de perfs mesurable. Déjà entre core2 et core2_sse41 il y a que 0.5% d'écart...

Ca se déco puis reco 5s (par défaut) plus tard.
Tu voudrais faire quoi d'autre ? Se déconnecter avant le délai de 10min (si pas de share soumis) et se reconnecter presque aussitôt pour gratter quelques secondes ?
Ceci dit, à une époque on pouvait se prendre des ban temporaires (quand ils sont très chargés j'imagine qu'ils élaguent un peu les connexions clients), si ça permet d'éviter ça ce serait déjà pas mal.

Je me doutais bien, j'voyais pas non plus quelle différence permettrait de gagner en perf

moi ça me donne environ 77 h/s sur un phenom II x4 955 win7  

oui, ne pas attendre 5s mais 0s, 5s sur 600s (10mn) c'est presque 1% de temps perdu.
 
J'ai trouvé le bug du --elevate  
 
Prochaine version :
* kernel sse4.1 et 4.2 pour les Intel Core et les AMD récents. Pas de AES encore, donc pour miner en vrai sur ces CPU, honnêtement, restez sur xmrig et compagnie
* correction du bug --elevate
* Support du Turtle

merci
un petite copie du log du début avec la Topology je prends, j'ai fait ça à l'aveugle sur ces CPU que je ne possède pas  

La connexion au pool échoue systématiquement chez moi:

La ligne de commande:

 
Avec --auto à la place de mon fichier de config: même combat.
Idem en supprimant le --elevate.
 
J'ai pourtant bien pris soin de lui ouvrir l'accès via le firewall, comme je le fais pour n'importe quel nouveau logiciel de minage.
Le message d'erreur est de toute différent de celui obtenu quand le firewall fait des siennes.
 
Cet échec de connexion me laisse perplexe.
Mais que cette version ne soit pas encore optimisée pour Ryzen me console.

                +----------------------------------------+
                | JC Expert Cryptonote CPU Miner 0.3-hfr |
                +----------------------------------------+
 
 
Analyzing Processors topology...
AMD Phenom(tm) II X4 955 Processor
Architecture codename: Deneb
  SSE3          : Yes
  SSSE3         : No
  SSE4.1        : No
  SSE4.2        : No
  AES           : No
  AVX           : No
 
Auto-configuration, selected CPUs will be highlighted...
Found CPU 0, with:
  L1 Cache: 64 KB
  L2 Cache: 512 KB
  L3 Cache: 6144 KB, shared with CPU 1, 2, 3
Found CPU 1, with:
  L1 Cache: 64 KB
  L2 Cache: 512 KB
  L3 Cache: 6144 KB, shared with CPU 0, 2, 3
Found CPU 2, with:
  L1 Cache: 64 KB
  L2 Cache: 512 KB
  L3 Cache: 6144 KB, shared with CPU 0, 1, 3
Found CPU 3, with:
  L1 Cache: 64 KB
  L2 Cache: 512 KB
  L3 Cache: 6144 KB, shared with CPU 0, 1, 2
 
Preparing 3 Mining Threads...
 
+-- Thread 0 config ---------------+
| Run on CPU:      #0              |
| Use cache:       yes             |
| Assembly kernel: generic_sse3    |
+----------------------------------+
 
+-- Thread 1 config ---------------+
| Run on CPU:      #1              |
| Use cache:       yes             |
| Assembly kernel: generic_sse3    |
+----------------------------------+
 
+-- Thread 2 config ---------------+
| Run on CPU:      #2              |
| Use cache:       yes             |
| Assembly kernel: generic_sse3    |
+----------------------------------+
 
Nicehash mining detected, auto-enabling Nicehash mode.
Starting Mining thread 0, affinity: CPU 0
Thread 0 successfully bound to CPU 0.
Allocated shared Huge Page at: 0000000002a00000
Allocated 2MB Cached Huge Page Scratchpad Buffer for cpu 0 of NUMA node 0 at: 00
00000002c00000
Starting Mining thread 1, affinity: CPU 1
Thread 1 successfully bound to CPU 1.
Allocated 2MB Cached Huge Page Scratchpad Buffer for cpu 1 of NUMA node 0 at: 00
00000003000000
Starting Mining thread 2, affinity: CPU 2
Thread 2 successfully bound to CPU 2.
Allocated 2MB Cached Huge Page Scratchpad Buffer for cpu 2 of NUMA node 0 at: 00
00000003200000
Devfee is 1.5%
 
18:29:42 | Connecting to mining pool cryptonight.eu.nicehash.com:3355 ...
18:29:42 | Nicehash Cryptonight Mining session starts!
 
 
 

   
 
Rhoo ce CPU encore pire que mon core2  
Lermite : ok, je me doutais que j'avais pas testé tous les problèmes réseau possible, je regarde ça merci

 
Sur un i7 7700k @5ghz je perd 60h/s avec ton soft  
Le ryzen 1700x comme azecece1
 
Je testerai à l'ocase sur un i5 2500k
je perd 80h/s

NH ca donne une Renta de merde en ce moment où c'est moi ?

Je vais  finir par activité l'auto exchange vers le BTC ça sera toujours plus rentable que NH

 
Merci c'est jolie (les couleurs love) et ça tourne sur threadripper 1950x en monothread (bios),
mais le hash rate est 300 moins bon que xmr stack cpu:
 

 
Référence xmr stack sous 13 cores:

Non pas jusqu'à il ya peu de temps, les blockchain fonctionnaient mieux .

@tous ceux qui testent sur des Ryzen, AthlonFX ou des core i5/i7
 
Mon mineur actuellement ne supporte pas le AES, qui est une instruction clé du Cryptonight, c'est donc normal que les perfs soient pourries. Mais le facteur de perte est faible (-50%) ce qui est de bonne augure
Merci pour les logs, finalement la config auto a l'air de bien marcher  

jesus_christ >
 
Un truc que je pige pas, si t'as les compétences pour faire un mineur, pourquoi tu ne fait pas un mineur de CG ?
Vu le peu de mineur sur le marché, j'imagine qu'ils se font des couilles en or, alors pourquoi pas toi ?
 
Ne vois aucune agression ou aucun troll dans mon message, je précise parce que sur hfr c'est commun.... juste ca m'intrigue.
 

Tu peux utiliser Github pour mettre ton .exe en téléchargement (dans les "releases" ), et sur le dépôt tu ne crées qu'un seul fichier README.md dans lequel tu formates ta documentation en markdown. Tu conserves donc ton code.

Ainsi, les gens peuvent utiliser l'onglet "issues" pour te remonter les bugs / améliorations constatées.

Je dis ça juste pour éviter que ce topic deviennent un bugtracker.

M'étant moi-même pencher sur le sujet : CPU et GPU, c'est abolument pas la même architecture.

Et puis l'OpenCL en C ca va, mais en Assembleur O'scour !!! (le x86 a coté c'est une partie de plaisir.)

Sans compter si tu veux vraimant gagner en perf, c'est surtout en retravaillant les algos de hashage tel que: groest256, jh, etc. pour une archi particuliere.

Ex: sur la Vega en utilisant les instruction assembleur Packed Math il y aurai moyen de gagner 25 a 50% de perf de plus que cast_xmr.

fin bon ca reste un taff qui pourrais prendre des mois.

Celui qui sort le mineur avec cette optimisation et 2% de fees, il prend tout le marché .

Le gros du marché c'est les CPU (botnet) et les rx 5x0.

Les Vega c'est pas encore la norme.

Puis avec un tel mineur les Vega serait a 3000e facile