[JCE]Fast & stable CN/v8/Heavy/Tube/XHV miner, CPU+GPU, Vega56 1800+ RX580 1200+

[Lermite]

"Lermite" mmh, that name sounds familiar...

I'm the one your thinking about

One way to save compiling time without compromising the security would be to compile the kernel of the first thread of a GPU, and keeping it in RAM or cache to inject it to the other treads of the same GPU if they have the exact same parameters.
This optimization would not apply to a GPU with only one thread, neither one with several threads with different parameters, but as the most usual case is two identical threads per GPU, it could save much time during each startup.

[1713962022]

1713962022

[JCE-Miner]

It may be possible, but slightly less secure. Kernels are not unsecure in ram, they are unsecure when passed to OpenCL as binaries.

I read SRB indirectly replied to my post about hashrate. I didn't want to polute his topic, so I answer here. Doktor, you're welcome to answer here, if you want.

I said and repeat that Claymore was cheating, at least on the XMR miner. Just use the no-fee mode, and you get the exact same displayed hashrate with a punishing -5% effective result. Plug it to a proxy, and you get -10%. As a vengeance. And hashrate difference was a lot worse on version 10+ than 9.7.
That's was I carefully measured when I mined with claymore, before I dev my own miner.
And I say the opposite for Stak or Xmrig. It means that anybody claiming Stak or xmrig cheats (i read one on your topic) just does a bad test, since they explicitely does nothing bad, their code is clear open and clean.
The only cheaty thing is that Stak mines +2s than said per session, to handle the connection delay. I find it oversized, no pool has a 2s ping, but that's a small difference.

Code:

inline bool is_dev_time()
{
	//Add 2 seconds to compensate for connect
	constexpr size_t dev_portion = static_cast<size_t>(double(iDevDonatePeriod) * fDevDonationLevel + 2.);
....

However, all, please do not jump back to another miner's thread to claim you found a better one. That's not polite. I know that Xmrig did it a lot with Stak so it's somehow a tradition, but please avoid.

[vmozara]

Ok, sorry, i will not do anymore. I just got angry because nobody listened to me. I will stick with JCE now

[JCE-Miner]

A technical possible reason could be a bug in code that cause false positive. Good shares that are not found.
Also, if the mining of N shares (N=multihash in JCE, intensity in Stak) is interrupted after only K shares have been computed (K<N) because of a Stale share, the share counter should be incremented by K and not by N. Since evaluating K is complicated, maybe some miners just count N. In such case this is not explicit cheat like adding +5% on the displayed hashrate like Claymore, but a technical overlook.

[Bry Guy]

Hi JCE, I just started testing your miner (I opted for the a version due to noted regressions in b) and after about 15 hours of testing on my 8 x Vega 56 rig, things are looking very good. I can post more details once it has proven stable over time, but upon initial observation, I am quite pleased.

I understand that the h/s displayed in blue is the true average physical hashes per second over the past 512 hashes. In Advanced Topics, you state that the displayed number has no tweak, and includes the fees. If I understand correctly, could this be a reason why when I refresh quickly using 'h', I see values drop considerably on one thread followed by the other, followed by yet another? The only reason I ask this, is that a highly variable h/s on any given thread can sometimes be an early warning sign that the card/thread is not stable due to overly-aggressive configuration settings or clocks/voltages). Based on my observations, the numbers come right back up into a normal and stable range, so it seems that this is by design and that you are mining to your dev pool on a thread-by-thread basis, and that this is not necessarily a sign of instability. I just want to be sure before I spend more time tweaking performance.

Also, Effective Net Hashrate as calculated by total hashes / total seconds spent mining is often much higher than my average physical hashrate, even over an extended period of time. Since this number is supposed to take into account stale/invalid shares as well as fees, this is surprising. I would expect the number to be lower. Do you have any thoughts on this matter?

Keep up the good work!

[JCE-Miner]

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

Netcode fixes
Bittube v4

[PsychoSterope]

I have a very old AMD HD5670 that I am just curious to try with the GPU miner. I know you said on Github you didn't have very good luck with a 1GB card, but I am just too curious.

What settings do you think I should try with this old 1Gb card?


Thanks!

[JCE-Miner]

i didn't test on cards older than HD7000 and i don't think it will ever compile. but you can test

use the same config that my Bonaire in the doc, and try to raise multi_hash to 240 in case it's better

[Bry Guy]

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

Netcode fixes
Bittube v4

Thanks for the thorough reply. I will indeed use the JSON to monitor moving forward. I fully understand the way luck is involved and that a hashrate shown poolside based on shares found will need considerable time to converge with physical hashrate. 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.

I suspect that you are right about the possible spikes in physical h/s on Vegas causing confusion since the current sample size for physical averages is actually closer to .25 seconds!

[NotEnough]

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

I have same issue. R7 1700x starts with 2200+ h/s and after few minutes h/r drops to 1700 h/s. Also all system GPU slow down h/r too . XMR-Stak (with similar settings for CPU) gets ~ 2140 h/s, but all works great.
P.S. Tested on two different motherboards (B350 and X470 chipsets) with two different instances of the processor.

[grendel25]

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.

[Bazzaar]

its more about the cache than the cores, you can only run as many threads as the cache has capacity for the scrtchpads

[Larvitar]

Wow

I take a few days off and you lauch the JCE-Miner GPU version!

I'll try it today. How is the CN-Lite performance?

[Lonnegan64]

Hey

there are some errors or outdated infos in the README.md:

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.

When the Ryzen 7 1700 has 16 logical cores and only 4 are used, then not 8 logical cores are unused, but 12! Perhaps you got confused by your own Ryzen 5 1600. There indeed 8 cores are unused.

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

Sumokoin is not Cryptonight-Heavy anymore. They went back to original Cryptonight to be ASIC-friendly, whereas the existing Cryptonight-Heavy chain was renamed to Ryo-currency or simple Ryo. 

[Lonnegan64]

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.

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

[JCE-Miner]

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.

Correct. This is why I call it effective. This is not a long term average, but the real yield you got from the miner.

But 8 logical CPUs would be unused

I was correct, there are 4 cores (equals 8 logical cpu) unused. But i rewrote my sentence to be more explicit.

The CPU mining is very sensitive to any event on the computer, including yourself pressing H to get the hashrate (pressing H has higher priority than mining to stay responsive, so it stops the miner for a split second and leads to a lower hashrate).
With the computer/rig Idle and dedicated to CPU mining, the hashrate should be stable.

Sumokoin is not Cryptonight-Heavy anymore.

Thanks, I updated my doc.

I'm now building the updated CPU-only version 0.31 with new netcode, bittube-v4 and updated coins.

[vmozara]

Hi everybody,

I promised update on the hash rate verification and here is:

Total of 6 miners connected to monero ocean pool

Each miner is 14.3 to 14.7 KH/s depending of cards setups

When I press R, the miner gives effective hashrate and hash count - all 6 miners showed exact the same hash count as the pool (minus 1.5% devfee). My average effective hashrate is at least 14KH/s, which is less than blue letters HS/s, I saw JCE put some explanation about this in previous posts, but I didn't read the post well.

Anyway, with such huge effective hashrate, all my rigs are now on JCE miner. My moneroocean "chart average" went from around 70-73KH/s to around 78-80KH/s (hard to say due to only one day of testing but difference is massive and obvious) compared to srbminer 1.6.1 which I was using before.

Unfortunately I did not pay attention to power consumption but seems to be the same

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!

[Sx5000]

Hello! First, I thank the developer of this miner, very happy!
I would like to emphasize the minuses and advantages of the gpu miner at the moment:

Pro:
A real hash
Many coins supported
Normal minimalistic interface
Minimal commission

Con:
No monitoring of temperature and speed, voltage, frequency, their adjustment
There is not enough identification of the card on bus_id
Display sequence is not the same as in gpuz and overdrive
A heavy algorithm on rx550 has an unstable hashrate
Very long compilation at startup. Rig on 12 cards about 5 minutes, this makes testing very difficult
No failover pools

Good luck to the developer!

[JCE-Miner]

Thanks vmozara

I don't reply about the pool side difference. I don't want to start a dev war.
I just still say Claymore obviously tweaked the effective hashrate of his XMR miner against displayed hashrate, and he pretended in his doc that was because of "disabled optims" -5%. No problem with that, but a disabled optim should also lower the displayed hashrate. If you explicitely mine @500 minus 5% of "disabled optims" you must display 475. Period.

Note that the GPU devfees are 0.9% and not 1.5%.
1.5% is on the CPU part only, your 2KH/s vegas mine with 0.9% devfee.

Normal minimalistic interface

Thanks, this is on purpose, I wanted something clear and simple, close to Claymore 9.7
I found later versions harder to read. For example, I give the pool-side value of the share, which is useful, but not the hexadecimal hash value, which is useless, except for the dev debug.

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

Planned

There is not enough identification of the card on bus_id

There's currently the PCIe ID (named "Device" at JCE startup, in green)

A heavy algorithm on rx550 has an unstable hashrate

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

Display sequence is not the same as in gpuz and overdrive

Debatable. I currently use the OpenCL order.

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

When you test on 12 cards, first test on one card, then copy-paste the optimal values to the other 11 ones.
JCE OpenCL is generated on the fly and is bound to all environement, including the card, the parameters, the memory addresses and the coin. Recycling between two tests is impossible. Recycling between two same runs of JCE with exact same parameters is possible but would compromise security, I already explained why. But I don't give up finding a way that's both secure and faster.

[Sx5000]

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!

You are not alone, who doubted the srb miner hash. I asked the doctor about the difference between the hash in the miner and the actual month before. Did not get a normal response. And the same people tried to ridicule my tests with numbers. The real difference in the hash was my estimate of about 6%