Reprise du message précédent :
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

Merci
 
J'ai tout basculé vers la 0.14, pas vraiment de changement à noter sauf sur 1 machine (i5 3470S à 2.9GHz) ou je suis passé de 196H/s à 95H/s. Huge Page ok, aucune erreur, toujours sur 3 Cores.
Du coup, retour en 0.12 pour cette machine. (J'ai fais plusieurs essais, plusieurs reboot. Je ne comprends pas.)

Les perf /2, ça pue la non utilisation de l'algo "generic_aes". Tu peux le forcer à la main dans le fichier de config.
Du coup, c'est potentiellement un bug de mauvaise détection de ton CPU. Sur la 0.12, ça marchait du 1er coup ?

Merci beaucoup !
C'est un Ivy Bridge et il est maintenant détecté comme un Kentsfield (Core2), en forçant avec aes ça roule
Et oui, avec la 0.12 ça a toujours été correctement détecté.

Il me rend fou ce bug du Kentsfied, je vais re-refaire un tour de code.
En perf il y a normalement un leger gain en AES +0.38%
 
Je vais essayer de sortir le support du fork MoneroV ce we

0.14a-hfr en ligne
Hotfix sur la détection des CPU et de AES. Aucun changement de perfs
 
edit:
Je suis en train de faire la version Monero-V
Je drop au passge le dual-mining avec 2 ou 3 esclaves. Déjà que 1 c'est rarement utile, alors deux ou trois...
Ça va alléger le code.
 
edit : j'ai trouvé une optim en assembleur pour implémenter le Monero-V avec presque aucune perte. Je passe de 507 à 502. Je doute que la perte ne soit que de 1% chez Stak

Version MoneroV terminée mais... Vous connaissez un pool de test pour XMV ?
Ça m'embête de livrer une version non testée

En voici un: https://moriaxmv.com/
mais il n'ouvrira apparemment que quand le fork sera effectif, soit pas avant fin avril.
 
Minergate devrait aussi être de la partie.

pas encore actif.
Je n'ai plus qu'à hacker un mineur ayant le patch officiel pour faire une comparaison...

Version 0.14b en ligne.
Support du fork branché, mais pas utilisable encore.
 
Vous pouvez tenter, juste pour mesurer l'impact sur les perfs. Je mesure -1,4% sur mon ryzen
edit:
et -4% en non-aes 64-bits, et un étonnant -0.3% sur non-aes 32-bits. Faut que je vérifie que je l'ai bien branché dans ce cas

C'est le pool v7 que tu cherches ?

http://killallasics.moneroworld.com/

Je t'aime

Il y avait deux bugs dans mon implé.
C'est corrigé mais ça invalide la 0.14b
Je sors une 0.14c demain
 
Edit : Bug en monero v je veux dire, le reste marche

Avec l'attribut --low, la priorité du processus reste à "Normale".
 

 
Il serait plus efficace que cette dernière passe à "Inférieure à la normale" voire "Basse" pour éviter d'entraver les performances des autres applications sans entraver les siennes quand il a le champ libre.
Mais j'ignore si c'est faisable sur le processeur principal de jce_cn_cpu_miner64.exe sans déporter tous les calculs dans une thread dédiée.

J'ai fait quelques essais :
sans --low : process priorité 8 et threads priorité 8 (8 = normal, cf plus bas)
avec --low : process priorité 8 et threads priorité 6
START /LOW : process priorité 4 et threads priorité 4
START /HIGH : process priorité 13 et threads priorité 8

J'ai l'impression de 3 choses (à l'arrache ) :
* jesus_christ laisse le process à 8 et fixe explicitement un niveau de priorité des threads en fonction de la présence de --low (sans l'indiquer, il me semble qu'un thread hérite de celui du process)
* la command START permet de forcer un niveau de priorité du process (mais pas des threads, sauf par éventuel héritage)
* la priorité d'un thread ne semble pas pouvoir dépasser celui du process
Bref, de l'extérieur, on ne peut que brider le niveau de priorité des thread, ou augmenter celui du process (mais pas ceux des threads).

Pour rappel, le niveau de priorité va de 0 à 31 avec les correspondances usuelles suivantes :
/LOW = 4
/BELOWNORMAL = 6
/NORMAL = 8
/ABOVENORMAL = 10
/HIGH = 13
/REALTIME = 24

edit:
la commande complète que j'ai utilisé pour baisser le niveau de priorité à 4
START /LOW "JCE CPU miner" "jce_cn_cpu_miner64.exe" --auto --hfr [...]

Honte à moi, je ne connaissais pas l'astuce du start /LOW qui est pourtant excellente.

Joli reverse engeneering
En effet --low baisse la priorité des threads qui minent. Le thread principal du process lui ne fait presque rien sauf gérer les paquets réseau, donc je le laisse par défaut.
 
0.15 en cours d'upload, c'est une revision majeure
 
Support du Cryptolight AEON dans toutes les combinaisons (x32, x64 avec ou sans aes, avec ou sans dual-mine)
Support qui marche du MoneroV (merci à br9n pour son tuyau)
Meilleur choix de l'ago en automatique
Paramètre --algo pour le forcer sans se tapper toute la config manuelle
Suppression totale du triple et quadmining (inutiles)
Meilleure gestion des caches exotiques type 13.5M
Support partiel du Cryptonight Heavy
Fees 3% en 32 bits, inchangées en 64. --hfr marche toujours

Les forks et les versions s'enchaînent...
 
Nouvelle majeure 0.16
 
* Support du cryptolight-V (fork du Monero-V en version Cryptolight)
* Support du Stellite

le Cryptolight c'est le CNv7 ?

C'est rentable du coup ? J'ai un 8700k à la maison

Je ne sais même pas comment appeler cet algo.
C'est le futur algo du Turtle : Du Cryptolight (scratchpad de 1M) avec le patch du monero-V7.
 
Rentable : Plus que n'importe quel autre mineur cpu, mais en € ce n'est pas sûr, ca dépend si tu utilises ta machine par ailleurs. Un mineur cpu dédié n'est probablement pas rentable.

Y a des attaques sur CryptoNote en ce moment semble - t il, je sais pas à quel point cela nous affecte... ?
https://twitter.com/Serena_fox_dero [...] 0262996992

Un exploit dans hellium hydra permet a un attaquant ayant plus de 51% de hashrate du réseau de faire un fork puis d'y inscrire ce qu'il souhaite, comme par exemple qui as miner ou non. Du coup cet attaquant repart avec tout les blocks reward.

Techniquement autre le fait de l'arriver des ASIC qui augmente la difficulté, avec ce genre d'attaque ça revient a miner dans le vent. (Pas de reward pour les mineurs)

Le bonne nouvelle, c'est que devs de DERO ont prevu le coup :
- Immuniser a cet exploit.
- Contre-mesure NiceHash.
- Contre-mesure ASIC.

Oui oui les ASIC n'arrivent pas a miner le Dero, même en CryptoNight v6.

J'ai eu ça en mon absence :

Faut prévoir un watchdog qui surveille le mineur (avec éventuel changement de pool) ou il y a une option qui m'a échappé ?

T'es sur nicehash, c'est l'équivalent d'un ban vu que t'as pas assez de ouissance selon eux
 
perso, j'ai arrêté NiceH depuis lors. Le mineur se faisait ban toutes les 2à12H

Pas d'option particulière, il suffit de faire un .bat qui relance le mineur, éventuellement sur un autre pool.

Cryptonight Heavy terminé en non-aes 64 bits
L'impact est lourd je confirme, avec ses 12M de cache mon xeon sort 50H/s contre 116 en CN standard. Et mieux vaut alors utiliser tous les threads possible.
 
L'écart devrait être + faible avec aes

A mon avis le Dero va pas suivre le fork Monero mais partir sur sont propre PoW.

Un des dev qui nous sort qu'ils ont un algo qui génère des algos ASIC resistant à la volée toutes les secs...

Déjà que les ASIC actuel se font jeter, alors qu'on est encore en CryptoNight v6.

Bref, on en saura plus dans deux / trois jours, je sent qu'on va bien rire.

Portage en 32 bits non-aes.
Reste le AES et je release.
 
Pour faire la division 64 bits du Heavy en 32 bits j'ai...

 
Edit : J'ai limité la casse en 32 bits avec 80% des perfs du 64 bits. En fpu + sse2, la où le compilo par défaut ne fait que du int32. Je fais la partie Heavy en 9 instructions  

J'ai dû rater un truc.
 
Sur le XMR post-fork, SRBMiner fonctionne parfaitement.
Mais JCE CPU 0.18 voit tous ses shares rejetés:
 
https://puissanceled.com/vrac/JCE_C [...] jected.png
 
Ce problème est sans doute lié au "Cryptonight variation: Original Cryptonight", mais comment le forcer à passer sur le fork?

paramètre --help pour avoir la liste puis
--variation pour choisir le fork
 
Xmr ? Il ne devait pas fork à la fin du mois ?

Ca, je n'en sais rien. Je ne suis ces (nombreuses) histoires de fork que de loin.
Mais force est de constater que sans le paramètre --variation, c'est à dire --variation 0 qui sélectionne automatiquement la 1, je n'ai que des shrares rejetés.
Par contre, avec -variation 3, ça mine normalement, avec seulement des shares acceptés.
 
Mon pool pour le XMR est web.xmrpool.eu
Peut-être a-t-il une spécificité expliquant mon problème. Il mentionne pourtant bien un fork à venir, mais peut-être qu'un test d'implémentation a été publié par erreur.

Le fork Monero v7 a eu lieu cet aprem, Sumo avec le CN-heavy c'etait hier il me semble.

ok, je vais mettre à jour mon mode auto, merci du tuyau
 
edit : bon j'ai testé tout va bien. Je sors la 0.17 demain normalement, avec support complet de tous les forks dans toutes les combinaisons, sauf le dual-mining + cryptonight heavy qui n'est pas possible (le heavy ne permet pas de partager des ressources entre threads)

Catastrophe : Le calcul en FPU ne marche pas.
Si le résultat est du type 542458752146.999999996 ça sera arrondi supérieur, quelque soit le mode d'arrondi, et donc sera faux. Ça arrive environ une fois une 10M mais c'est suffisant pour faire des shares invalides (mais aussi des shares valides ). Je vais devoir repartir sur du int32

Quel est le but exactement? Arrondir à l'entier le plus proche ou à celui immédiatement égal ou inférieur?

Tu ne peux pas faire de divisons par décalage binaire ?

Un détail m'agace avec JCE CN CPU.
Je l'ouvre via un raccourci pourvu d'une icône explicite et nommé tout aussi explicitement.
Ce raccourci ouvre une fenêtre mais le mineur, au lieu de se lancer dans cette fenêtre, se lance dans une autre, elle sans icône ni nom explicite.
J'ai essayé de mettre ou non:
 - l'attribut --elevate
 - l'option "lancer en tant qu'administrateur" au niveau de l'exécutable.
 
Le résultat, où les deux fenêtres sont normalement superposées:

 
Sans aucune de ces deux options, le mineur refuse de fonctionner, réclamant les privilèges administrateurs. Normal.
Mais avec une de ces deux options ou les deux, j'ai le problème des deux fenêtres ouvertes au lieu d'une seule.
 
Il doit pourtant être possible de lancer le mineur dans la même fenêtre puis que c'est ainsi que les autres mineurs fonctionnent, SRBMiner par exemple.
Ce n'est bien sûr pas un problème bloquant mais j'apprécierais quand même qu'il soit corrigé dans une future version.

Effectivement, je n'ai pas encore trouver comment rester dans la même fenêtre, et Stak ou nircmd ont le même bug. Je ne peux pas mettre ça prioritaire mais c'est à corriger
 
Pour la division, c'est faire une division entière signée 64 bits avec la fpu, et récupérer le resuktant strictement arrondi inferieur. Hors la fpu ne peux pas être stricte si ses bits de garde ne sont pas suffisant.
 
Non régler l'arrondi sur TowardZero ne suffit pas, utiliser les float80 non plus, la fpu ne peut pas faire de div64 toujours correcte, c'est comme ca

J'imagine que la solution de bourrin consistant à convertir le flottant en chaîne de caractères, la tronquer pour ne garder que ce qu'il y a avant le point, puis la reconvertir en flottant ou entier, n'est pas applicable à l'assembleur ou ça plomberait les performances.
 
Ah si seulement je ne m'étais pas arrêté à l'assembleur 68000

Ah ouai, passer du flottant à la chaîne de caractères pour tronquer...