Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 12. (Read 90839 times)
I didn't use CPU and old GPU for mining at now. 100-125 Watt CPU too much energy cost for 300-350 h/s on heavy. It's too much even for 500 h/s on v8...
Hi!
About the Athlon-FX, i'm about to release a CPU version with the backport of the Bulldozer fix and optim, as detected by Unclwish.
Compared to the 33j, it should give you a few extra hashes, on par with the older version 33h
Best CPU algo:
Some maths. The Cryptonight algo is made of three main parts, and a few negligible other:
* Explode
* Scratchpad
* Implode
The 1st and 3rd are simple AES rounds on predictable memory addresses. A non-AES cpu will make it slow, unless using JCE where it would be 35% faster, but still quite slow, and an AES Cpu like the Athlon-FX will make it almost instantly. An AES CPU is like an AES cypher ASIC.
GPU do these steps quite slow, because an EAS round on GPU involves dozens of computations and LDS memory accesses.
The step 2 is slow in both cases.
The CPU are overall very fast, but they compute something like 4, 8, 12 CN hashes at the same time, on a common CPU (ultra-pimped Threadrippers/Xeons of course can do 64 or more, JCE supports up to 256).
GPU do like 500 to 4000 at the same time, so they are overall more efficient.
The trick is to choose for CPU the biggest steps 1 and 3 and the smallest step 2.
The best algo for this are:
* Cryptonight MKT (slightly smaller step 2 than Monero)
* Cryptonight Fast/Masari (better, the step 2 is half of Monero)
* Uplexa (still better, the step 2 is quarter of Monero)
Also, while the normal cache allocation is 2M, Heavy-like algo (Ryo, Haven, Tube...) use 4M and Uplexa use 1M. GPU have such a large memory to work with that the difference is tight, in both case they use all their memory and computing power.
But modern CPUs tend to run out of cache (while old CPUs like Core2 had a lot of cache but lacked cores). Use a twice smaller cache allocation allows to use twice more cores, and often double the performance.
This is why mining Monero on CPU often makes it run at 50% or 66%, while mining on GPU always makes it run at 100%.
GPUs dont' run out of cache because they simply don't really use it (*), they rely on their fast memory. They are designed for this. A CPU has a much slower memory but a very efficient cache.
My advice: technically, mine uPlexa. Just i don't know if its market value will get good, but the algo is fine for CPU.
(*) A typical real-life GPU operation is blitting a 64M texture in a game. In such case, having 256K or 512K cache or even 16M cache is useless. This is why GPUs are designed to work with async uncached fast memory, while CPU are cached and sync.
edit:
Here's the 0.33k CPU Windows (linux comes next)
Very minor revision, with a fix for Bulldozer family on x64 for v8. No other change.
Fork status:
AscendingNight: done but hidden, and likely to be dropped since the devs no longer reply on Github and the only 2 pools are offline. Sad, it was a good CPU algo, like uPlexa.
Stellite v8: done but hidden, i want a real pool to validate my devs, and haven't found any.
Turtle v2: ditto
Hycon: not started yet and i don't like this coin, looks like a normal CN algo with pedantic netcode changes. I may add it but not sure. I don't see a reason to mine it neither on GPU or CPU.
About the Athlon-FX, i'm about to release a CPU version with the backport of the Bulldozer fix and optim, as detected by Unclwish.
Compared to the 33j, it should give you a few extra hashes, on par with the older version 33h
Best CPU algo:
Some maths. The Cryptonight algo is made of three main parts, and a few negligible other:
* Explode
* Scratchpad
* Implode
The 1st and 3rd are simple AES rounds on predictable memory addresses. A non-AES cpu will make it slow, unless using JCE where it would be 35% faster, but still quite slow, and an AES Cpu like the Athlon-FX will make it almost instantly. An AES CPU is like an AES cypher ASIC.
GPU do these steps quite slow, because an EAS round on GPU involves dozens of computations and LDS memory accesses.
The step 2 is slow in both cases.
The CPU are overall very fast, but they compute something like 4, 8, 12 CN hashes at the same time, on a common CPU (ultra-pimped Threadrippers/Xeons of course can do 64 or more, JCE supports up to 256).
GPU do like 500 to 4000 at the same time, so they are overall more efficient.
The trick is to choose for CPU the biggest steps 1 and 3 and the smallest step 2.
The best algo for this are:
* Cryptonight MKT (slightly smaller step 2 than Monero)
* Cryptonight Fast/Masari (better, the step 2 is half of Monero)
* Uplexa (still better, the step 2 is quarter of Monero)
Also, while the normal cache allocation is 2M, Heavy-like algo (Ryo, Haven, Tube...) use 4M and Uplexa use 1M. GPU have such a large memory to work with that the difference is tight, in both case they use all their memory and computing power.
But modern CPUs tend to run out of cache (while old CPUs like Core2 had a lot of cache but lacked cores). Use a twice smaller cache allocation allows to use twice more cores, and often double the performance.
This is why mining Monero on CPU often makes it run at 50% or 66%, while mining on GPU always makes it run at 100%.
GPUs dont' run out of cache because they simply don't really use it (*), they rely on their fast memory. They are designed for this. A CPU has a much slower memory but a very efficient cache.
My advice: technically, mine uPlexa. Just i don't know if its market value will get good, but the algo is fine for CPU.
(*) A typical real-life GPU operation is blitting a 64M texture in a game. In such case, having 256K or 512K cache or even 16M cache is useless. This is why GPUs are designed to work with async uncached fast memory, while CPU are cached and sync.
edit:
Here's the 0.33k CPU Windows (linux comes next)
Very minor revision, with a fix for Bulldozer family on x64 for v8. No other change.
Fork status:
AscendingNight: done but hidden, and likely to be dropped since the devs no longer reply on Github and the only 2 pools are offline. Sad, it was a good CPU algo, like uPlexa.
Stellite v8: done but hidden, i want a real pool to validate my devs, and haven't found any.
Turtle v2: ditto
Hycon: not started yet and i don't like this coin, looks like a normal CN algo with pedantic netcode changes. I may add it but not sure. I don't see a reason to mine it neither on GPU or CPU.
Hey JCE!
I`m mining with your CPU miner about 5 months. I got 2 AMD FX 8350. Picked v8 forks, as cryptonight heavy looks bad for my cpus.
I`m getting about 300-330h/s on 7 cores(keeping 1 core for GPUs). Do you think it`s better to switch CPUs on light or some other algo for better efficiency?
Thanks!
I`m mining with your CPU miner about 5 months. I got 2 AMD FX 8350. Picked v8 forks, as cryptonight heavy looks bad for my cpus.
I`m getting about 300-330h/s on 7 cores(keeping 1 core for GPUs). Do you think it`s better to switch CPUs on light or some other algo for better efficiency?
Thanks!
yeah my hybrid thing caused more regressions than performance, in the b14 all is somehow fixed.
i still consider TeamRed the best deal for v8 on big RX, thanks to its low power draw.
otherwise, well configured, i should provide performances very close, in a 2% margin. taking the power and fees into account, TeamRed remains the best on cards they support, but my miner works down to the HD6000
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1632 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1632 },
try this for RX 8G, with adjustments by step of 16 for multi_hash
for vega:
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1904 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1904 },
ditto, and try beta=16 too
i still consider TeamRed the best deal for v8 on big RX, thanks to its low power draw.
otherwise, well configured, i should provide performances very close, in a 2% margin. taking the power and fees into account, TeamRed remains the best on cards they support, but my miner works down to the HD6000
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1632 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1632 },
try this for RX 8G, with adjustments by step of 16 for multi_hash
for vega:
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1904 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ..., "multi_hash":1904 },
ditto, and try beta=16 too
Hey Jce,
What's the current status of the GPU miner? There have been so many changes and reverts, its confuzing. For V8, is the miner in the same ballpark with SRB and TRM? Last time i checked i could not even get close. What are the best settings for vega 64 and 580 8G?
What's the current status of the GPU miner? There have been so many changes and reverts, its confuzing. For V8, is the miner in the same ballpark with SRB and TRM? Last time i checked i could not even get close. What are the best settings for vega 64 and 580 8G?
the drop of 1-2 h/s is due to the auto legacy, but it tends to cause either a negligible drop or a big hashrate restore, so it's now enabled most of the time.
thanks again for the report!
CPU video: you uploaded a second one, about config, thanks!
overlooked topics are Bittube v2 mining (my miner is a lot faster, like +30%, on all cpus) and other Heavy algo (still have better perf on most cpu, with a tighter gain). but Heavy is rather an algo for gpu.
i'll release a new cpu version for win and linux soon, with the Bulldozer assembly, fixed thank to Unclwish.
thanks again for the report!
CPU video: you uploaded a second one, about config, thanks!
overlooked topics are Bittube v2 mining (my miner is a lot faster, like +30%, on all cpus) and other Heavy algo (still have better perf on most cpu, with a tighter gain). but Heavy is rather an algo for gpu.
i'll release a new cpu version for win and linux soon, with the Bulldozer assembly, fixed thank to Unclwish.
Can't the 033j version run on ubuntu 18.04?
I did one of my shameless undercover re-release of the b14. Should mine good on Athlon FX.
I also relaxed the max threads per GPU to 3 (request on github)
The download is here:
https://github.com/jceminer/cn_gpu_miner/raw/master/jce_cn_gpu_miner.033b14.zip
Yes, it works now... But encountered strange situation with b14. After several hours - about 5 or 6 one of GPU RX 580 8G drops speed about 120 h/s and didn't restore it untill restart miner... I will observe more on it...I also relaxed the max threads per GPU to 3 (request on github)
The download is here:
https://github.com/jceminer/cn_gpu_miner/raw/master/jce_cn_gpu_miner.033b14.zip
It seems to me or b14 real a bit slower than b13? About 2-3 h/s?
EDIT: 8+ hours of heavy algo mining - no continous speed drops, speed looks the same as on b13. Maybe 1-2 h/s lower... Good job, JCE!
I did one of my shameless undercover re-release of the b14. Should mine good on Athlon FX.
I also relaxed the max threads per GPU to 3 (request on github)
The download is here:
https://github.com/jceminer/cn_gpu_miner/raw/master/jce_cn_gpu_miner.033b14.zip
I also relaxed the max threads per GPU to 3 (request on github)
The download is here:
https://github.com/jceminer/cn_gpu_miner/raw/master/jce_cn_gpu_miner.033b14.zip
Bingo that's it, once again you saved my release from a stupid bug, thanks so much!
No matter you don't use the CPU to mine, it gets involved to do some partial hash to detect the broken shares (the red counter in the purple report). Otherwise, I couldn't tell the difference between a share refused by the pool because of bad fork, or real GPU memory/core failure. The impact is negligible on perf, but it may crash if the CPU side is wrong.
Note that i borrowed the idea from Claymore 10+ miner.
Are you some dev angel or something? Your config of RX580 8G + Nicehash + AthlonFX triggered three bugs I could not or barely have detected myself, that's crazy you found all of them
quick answer above: the speed depends on the algo, if you mine Turtle or uPlexa you'll get very high speed, but as any other miner would, so it's not better, just different.
uPlexa is an excellent coin to mine on an AES CPU, since the AES part is big and AES CPUs do it in a split second.
Yes, I'm mining angel No matter you don't use the CPU to mine, it gets involved to do some partial hash to detect the broken shares (the red counter in the purple report). Otherwise, I couldn't tell the difference between a share refused by the pool because of bad fork, or real GPU memory/core failure. The impact is negligible on perf, but it may crash if the CPU side is wrong.
Note that i borrowed the idea from Claymore 10+ miner.
Are you some dev angel or something? Your config of RX580 8G + Nicehash + AthlonFX triggered three bugs I could not or barely have detected myself, that's crazy you found all of them
quick answer above: the speed depends on the algo, if you mine Turtle or uPlexa you'll get very high speed, but as any other miner would, so it's not better, just different.
uPlexa is an excellent coin to mine on an AES CPU, since the AES part is big and AES CPUs do it in a split second.
Just want to help. You did a lot of hard work. I'm testing and help...
Bingo that's it, once again you saved my release from a stupid bug, thanks so much!
No matter you don't use the CPU to mine, it gets involved to do some partial hash to detect the broken shares (the red counter in the purple report). Otherwise, I couldn't tell the difference between a share refused by the pool because of bad fork, or real GPU memory/core failure. The impact is negligible on perf, but it may crash if the CPU side is wrong.
Note that i borrowed the idea from Claymore 10+ miner.
Are you some dev angel or something? Your config of RX580 8G + Nicehash + AthlonFX triggered three bugs I could not or barely have detected myself, that's crazy you found all of them
quick answer above: the speed depends on the algo, if you mine Turtle or uPlexa you'll get very high speed, but as any other miner would, so it's not better, just different.
uPlexa is an excellent coin to mine on an AES CPU, since the AES part is big and AES CPUs do it in a split second.
No matter you don't use the CPU to mine, it gets involved to do some partial hash to detect the broken shares (the red counter in the purple report). Otherwise, I couldn't tell the difference between a share refused by the pool because of bad fork, or real GPU memory/core failure. The impact is negligible on perf, but it may crash if the CPU side is wrong.
Note that i borrowed the idea from Claymore 10+ miner.
Are you some dev angel or something? Your config of RX580 8G + Nicehash + AthlonFX triggered three bugs I could not or barely have detected myself, that's crazy you found all of them
quick answer above: the speed depends on the algo, if you mine Turtle or uPlexa you'll get very high speed, but as any other miner would, so it's not better, just different.
uPlexa is an excellent coin to mine on an AES CPU, since the AES part is big and AES CPUs do it in a split second.
just tried and "works for me" but, what CPU do you have? There may be a conflict with the recent Bulldozer assembly, if you have a related processor.
edit: just found I put some BMI assembly in the bulldozer code, and not all bulldozer have BMI, so it may crash. If you have a modern but not Zen CPU, so it's probably the reason.
I use --no-cpu option... CPU is FX8320... edit: just found I put some BMI assembly in the bulldozer code, and not all bulldozer have BMI, so it may crash. If you have a modern but not Zen CPU, so it's probably the reason.
just tried and "works for me" but, what CPU do you have? There may be a conflict with the recent Bulldozer assembly, if you have a related processor.
edit: just found I put some BMI assembly in the bulldozer code, and not all bulldozer have BMI, so it may crash. If you have a modern but not Zen CPU, so it's probably the reason.
edit: just found I put some BMI assembly in the bulldozer code, and not all bulldozer have BMI, so it may crash. If you have a modern but not Zen CPU, so it's probably the reason.
Version GPU b14 - RX 580 8Gb cards - heavy algo - latest driver.
Miner closes after conneting to nicehash. He write "Pool changes difficulty..." as usual and than just closes without errors...
b13 works normal.
Miner closes after conneting to nicehash. He write "Pool changes difficulty..." as usual and than just closes without errors...
b13 works normal.
Hello
I can't find the link to download the GPU version, where is it?
Another thing, my CPU hashrate seems to be too high...
12:27:17 | Hashrate CPU Thread 0: 150.04 h/s
12:27:17 | Hashrate CPU Thread 1: 200.44 h/s
12:27:17 | Hashrate CPU Thread 2: 157.66 h/s
12:27:17 | Hashrate CPU Thread 3: 193.99 h/s
12:27:17 | Total: 702.11 h/s - Max: 949.68 h/s
*When I'm not using the PC, I get 1100 h/s
I'm using the 0.33j with a I5 4440
On this post I saw some ryzen and newer I5 getting only 300h/s, how is that possible?
I can't find the link to download the GPU version, where is it?
Another thing, my CPU hashrate seems to be too high...
12:27:17 | Hashrate CPU Thread 0: 150.04 h/s
12:27:17 | Hashrate CPU Thread 1: 200.44 h/s
12:27:17 | Hashrate CPU Thread 2: 157.66 h/s
12:27:17 | Hashrate CPU Thread 3: 193.99 h/s
12:27:17 | Total: 702.11 h/s - Max: 949.68 h/s
*When I'm not using the PC, I get 1100 h/s
I'm using the 0.33j with a I5 4440
On this post I saw some ryzen and newer I5 getting only 300h/s, how is that possible?
I give priority to the GPU version this time
Pretty please ?
Woow, thank you, i take a look. 
@all: sorry no support today, lacking of time. Otherwise the b14 GPU is now online
about the assembly: it's only on pre-Zen aes AMD cpus, only x64, only xmr v8. No change in other cases.
@all: sorry no support today, lacking of time. Otherwise the b14 GPU is now online
Quote
uPlexa fork for CPU and GPU
dedicated bulldozer v8 assembly x64
legacy mode is now automatic and tends to give slightly better perf on big rigs
The --legacy param remains to force this mode if needed.
dedicated bulldozer v8 assembly x64
legacy mode is now automatic and tends to give slightly better perf on big rigs
The --legacy param remains to force this mode if needed.
about the assembly: it's only on pre-Zen aes AMD cpus, only x64, only xmr v8. No change in other cases.
I covered this miner in a video guide that should be helpful for beginners.
Fastest Ever Cryptonote CPU Miner - How to Mine Monero Type Fork & Clone Coins
https://www.youtube.com/watch?v=LM0GlR5NT3Y
Fastest Ever Cryptonote CPU Miner - How to Mine Monero Type Fork & Clone Coins
https://www.youtube.com/watch?v=LM0GlR5NT3Y
I am getting a segmentation fault (core dump) on Ubuntu 18.
I am running the jce_cn_cpu_miner.linux.033i.zip
any idea?
Thx
I am running the jce_cn_cpu_miner.linux.033i.zip
any idea?
Thx
Hi all,
Linux GPU: unlikely. I'm a niche miner (CPU and older GPUs) and adding the Linux concept would make it a niche of a niche, but a lot of dev time to do. The Win GPU is already like 15% of my fees but 90% of the support, the Linux version would be like 1% of my users for 95% of the support. I cannot afford this
Sometime i don't look at the market and do things for fun, like supporting the HD6000, but it remains an acceptable dev time. Linux GPU wouldn't.
Btw try TeamRed on Linux for v8 mining, it burns like fire
@PIOUPIOU99: yeah thanks, my new CPU miner also burns like fire
Speed on Intel: i don't even have any big Intel CPU, i'm all AMD, as for the GPU (i've zero nVidia). But that's ok, i'll do some theorical optimizations for big Intel CPU too.
Can you tell me what exact CPU you have? Maybe a good config can close the gap with xmrstak. I know i must beat it by more than 1.5% to compensate for the devfee. It's true in most cases, but yeah maybe not the i7.
I do use it but competitive linux miner is always welcome Linux GPU: unlikely. I'm a niche miner (CPU and older GPUs) and adding the Linux concept would make it a niche of a niche, but a lot of dev time to do. The Win GPU is already like 15% of my fees but 90% of the support, the Linux version would be like 1% of my users for 95% of the support. I cannot afford this
Sometime i don't look at the market and do things for fun, like supporting the HD6000, but it remains an acceptable dev time. Linux GPU wouldn't.
Btw try TeamRed on Linux for v8 mining, it burns like fire
@PIOUPIOU99: yeah thanks, my new CPU miner also burns like fire
Speed on Intel: i don't even have any big Intel CPU, i'm all AMD, as for the GPU (i've zero nVidia). But that's ok, i'll do some theorical optimizations for big Intel CPU too.
Can you tell me what exact CPU you have? Maybe a good config can close the gap with xmrstak. I know i must beat it by more than 1.5% to compensate for the devfee. It's true in most cases, but yeah maybe not the i7.
probably have 580 8gb cards with timings mods doing 1400 cn heavy or something Jump to: