Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 85. (Read 90841 times)

Oh. Alloy is a harder variant of CN Heavy. You shouldn't mine CN-Heavy or CN-Alloy with CPUs, since their drop of hashrate in comparison to CN ist enormous, whereas GPUs aren't affected in the same way. CN-Heavy and CN-Alloy are tailormade for GPUs.   Consider to mine a CN-Lite coin with your CPUs. You may reach around 2700 H/s with CN-Lite (Aeon, Turtlecoin) or about 1300 H/s with CN-Fast (Masari).   If you want to mine CNv7, why not Monero? Sumo is back to ASIC friendly original CN. It's absurd to mine an ASIC coin with CPUs.  
No problem

Coin/Algo:  Alloy  /  cryptonight-alloy  

How would I determine optimized settings?  I guess I should see what I get on CN v7 to see if it's close to that 900 number.  any suggestions of coins to try?  Sumo?

I didn't know that about AMD FX Piledriver dies.  Your response is very informative.  Thank you for that.

I know my heavy is bad, i need to optimize it. I even tell it explicitely in my doc.

does the gpu miner compile fresh kernel every run?  It seems to be lot slower with multi GPU rigs.
EDIT:  Just read the posts above.

What coin/algo?

The Opteron 6376 is basically two AMD FX Piledriver dies on one package. An FX 8300 hashes around 1000 H/s Cryptonight-Lite or 340 H/s with CN v7.

Your system with two Opteron 6376 (say four FX dies), but lower frequency, should be around FX-8300-hashrate * 4 * 2.3 / 3.3. So CN v7 hashrate should be VAGUELY 900 H/s for the whole system with optimized settings But that depends on what coin/algo you want to mine

The people in other topic tried hard to convince me that my math is bad or I have issues with rigs, and simple change of miner increased my hashrate by like 10%. I have never been more happy to give 1.5% dev fee 

Dear JCE, thanks for awesome miner, please keep developing!

Normal minimalistic interface

No monitoring of temperature and speed, voltage, frequency, their adjustment
No failover pools

There is not enough identification of the card on bus_id

A heavy algorithm on rx550 has an unstable hashrate

Display sequence is not the same as in gpuz and overdrive

Very long compilation at startup. Rig on 12 cards about 5 minutes, this makes testing very difficult

I now see that you are simply multiplying shares found for the non-dev pool x difficulty value and that luck is included in this Effective Hashrate number.

But 8 logical CPUs would be unused

Sumokoin is not Cryptonight-Heavy anymore.

question:  I'm using 2x opteron 6376 and get around 475 h/s using 16 of 32 available cores which seems to consume about 57% of CPU resources.  Could i tune this up to get better performance and also use the other 16 cores?  Thank you for any comments or suggestions.

Another exclusive feature of JCE!
❗️ The no-cache mode is available only in the Windows version.
This is the reciprocal of multi-hash: for cases when your have wasted CPU cores, typically when mining Cryptonight Heavy. If you have a Ryzen 1700, 8 physical cores, 16 logical CPUs, 16M cache, the naive configuration would be 4 threads on 4 cores, 4M cache each, total 16M.

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :  1, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :  5, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" :  9, "use_cache" : true },
     { "cpu_architecture" : "ryzen", "affine_to_cpu" : 13, "use_cache" : true },
]
But 8 logical CPUs would be unused. Enabling them would flood the cache and lead to worse performance. What to do is making them mine, but with no cache, direct to memory.

Sumokoin, Loki, Ombre, Italo, Bloc, Niobio, Saronite are now Cryptonight-Heavy,

any hints why Ryzen starts with 180hs per Thread and drop to 130hs after some minutes (CNV7 lite)

and yes..got many duplicates at no nicehash pool

hello,

When i say the fees are included, that means the displayed hashrate is the same no matter if you're in a devfee session or not. This is the raw physical hashrate.
If you punch h, you lock the mining thread to force it to update the hashrate counter and display it on screen, so if you punch again and again, it will lower the hashrate, that's normal. This is the same for the CPU version. Better use the JSON http output which is updated in the network thread, and does not cause such a problem. From your browser, you can press F5 as much as you want. But not H from the console.

Effective hashrate should converge mathematicaly to lower than the average physical hashrate. Normaly by ~2% on a very long term.
If it's higher, so you had a good luck biasis. You can check that number two ways :
1. Look at your pool, you should get a similar hashrate (the computation range of the pool may be different from JCE, but on the long term, they should converge).
2. Get your total hashes and divide it by the uptime. You should get the same value. The hashes themselve can be checked against your pool history, or JCE log, and the uptime by... your wall clock

A difference can be explained by some instant peaks from your cards that make you mine faster but may not be reported by the blue instant hashrate, if you mine so fast that the 512 hashes are obsoleted fast. I admit that 512 was good for CPU, which can mine at 150h/s per core at best, but that's just half a second for a Vega. Average rate over half a second is too low. This is the problem. Good remark, i'll increase the time period for average of fast cards like Vega

Version 0.30c online