That answers exacly none of the questions i asked.
You can't recieve better speed on heavy algo than double threads with 944 multi_hash. Any other value will slower speed. And you can't reduce pagefile size. It's neccesary to have enough page file size to miner work normal. His size must be equal to size of videomemory used during miming. 2x944 multi_hash is almost 8Gb (about 7,5-7,7Gb) of videomemory during heavy algo mining. 
Topic: [XMR] JCE Miner Cryptonight/forks, now with GPU! - page 8. (Read 90832 times)
Hello all,
quick support today
Webchain and Hycon: no support yet. I know they got more popular after the support added into Srb, but i chose to focus on the CPU-friendly algos first (Masari and Turtle), as my miner is a mixed CPU/GPU miner. Webchain and Hycon are not special, except they use a pedantically different netcode than others.
@pbfarmer :
Your new data are easier to understand.
The missing hashrate being equal to CPU is coincidental, pause your CPU and you'll see a drop will remain.
The optimal yield you can get is ~99% (100% minus the fees) but depending on your pool aggressiveness, ping and overall CPU usage you may experience lower hashrate, while 96% is somehow in the lower bound. Mining with CPU + GPU has a normally little impact on performance, but it looks like on your rig, it's higher. Maybe because of the chipset or something, or the PCIe lanes used causes some internal delays.
Try to mine with 1 and 0 Cpu and i expect you'll get a better efficiency between the instant and effective hashrate. I already experienced such on one of my rig (a A320 + ryzen). Also remove the --legacy parameter if you use it, while it may provide more stable hashrate, it tends to lower the efficiency of mixed mining.
It's very possible you get different results with another mixed miner like Stak all-in-one, just because we did different choices in term of CPU/GPU sync and netcode aggressiveness. I chose a medium/high aggressivity, but not maximum, to keep a stable hashrate and zero bad shares. It may not be the best choice in term of absolute perf on your precise rig, but that's an overall all-around design.
RX 4G on Heavy/Tube:
try this as a base, for one card
Then try to increase multi_hash by steps of 16
quick support today
Webchain and Hycon: no support yet. I know they got more popular after the support added into Srb, but i chose to focus on the CPU-friendly algos first (Masari and Turtle), as my miner is a mixed CPU/GPU miner. Webchain and Hycon are not special, except they use a pedantically different netcode than others.
@pbfarmer :
Your new data are easier to understand.
The missing hashrate being equal to CPU is coincidental, pause your CPU and you'll see a drop will remain.
The optimal yield you can get is ~99% (100% minus the fees) but depending on your pool aggressiveness, ping and overall CPU usage you may experience lower hashrate, while 96% is somehow in the lower bound. Mining with CPU + GPU has a normally little impact on performance, but it looks like on your rig, it's higher. Maybe because of the chipset or something, or the PCIe lanes used causes some internal delays.
Try to mine with 1 and 0 Cpu and i expect you'll get a better efficiency between the instant and effective hashrate. I already experienced such on one of my rig (a A320 + ryzen). Also remove the --legacy parameter if you use it, while it may provide more stable hashrate, it tends to lower the efficiency of mixed mining.
It's very possible you get different results with another mixed miner like Stak all-in-one, just because we did different choices in term of CPU/GPU sync and netcode aggressiveness. I chose a medium/high aggressivity, but not maximum, to keep a stable hashrate and zero bad shares. It may not be the best choice in term of absolute perf on your precise rig, but that's an overall all-around design.
RX 4G on Heavy/Tube:
try this as a base, for one card
Code:
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ...., "multi_hash":432 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ...., "multi_hash":432 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "index" : ...., "multi_hash":432 },
Then try to increase multi_hash by steps of 16
webchain supported?
That answers exacly none of the questions i asked.
I'm trying out one cnHeavy coin.
I have 12 GPUS in the windows10 rig and I have set up 88GB swap file, now my SSD in rig is almost full, but still, my last to GPUs run in single thread, i left it at 944 intensity.
Is there a way to get better performance with different multi_hash setting then 944, or even better reduce page file/swap/virtual memory usage?
You can place your pagefile into different drives. 1st part about 8-16Gb of it you must place on system drive to improove speed. Other parts you can place into any other drive via pagefile settings. I have 12 GPUS in the windows10 rig and I have set up 88GB swap file, now my SSD in rig is almost full, but still, my last to GPUs run in single thread, i left it at 944 intensity.
Is there a way to get better performance with different multi_hash setting then 944, or even better reduce page file/swap/virtual memory usage?
I'm trying out one cnHeavy coin.
I have 12 GPUS in the windows10 rig and I have set up 88GB swap file, now my SSD in rig is almost full, but still, my last to GPUs run in single thread, i left it at 944 intensity.
Is there a way to get better performance with different multi_hash setting then 944, or even better reduce page file/swap/virtual memory usage?
I have 12 GPUS in the windows10 rig and I have set up 88GB swap file, now my SSD in rig is almost full, but still, my last to GPUs run in single thread, i left it at 944 intensity.
Is there a way to get better performance with different multi_hash setting then 944, or even better reduce page file/swap/virtual memory usage?
@pbfarmer: i'll redo some tests, but when you mine with the CPU+GPU, do you get some message like
If yes, so the shares went to the pool, and were accepted.
I've a Ryzen + AMD RX rig so i will be able to do the exact same test.
Try pressing R key to get the effective hashare of each device. CPU should not be zero, unless it has a negligible hash speed compared to the GPUs. But a Ryzen is quite poweful.
Not that the pool connection and fee sessions are global, not per-device, so it cannot be something like CPU disconnected or stuck in fee session. Otherwise you would have zero hashrate on all devices.
please tell what coin you mine on what pool, so i can do an more precise test.
webchain: no support planned, that's not a good algo for CPU, and i don't like how they changed the CN netcode conventions just because they could. Same for Hycon. Both coins can be mined with the CPU reference xmrig fork (possibly recompiled with zero fee), or on GPU with SRB.
I may add them later, but i'm getting less dev time those days and i need to choose between what i support or not. Currently i'm finishing the Stellite v8 fork.
Quote
CPU thread N finds a share, value XXX
Accepted by the pool
Accepted by the pool
If yes, so the shares went to the pool, and were accepted.
I've a Ryzen + AMD RX rig so i will be able to do the exact same test.
Try pressing R key to get the effective hashare of each device. CPU should not be zero, unless it has a negligible hash speed compared to the GPUs. But a Ryzen is quite poweful.
Not that the pool connection and fee sessions are global, not per-device, so it cannot be something like CPU disconnected or stuck in fee session. Otherwise you would have zero hashrate on all devices.
please tell what coin you mine on what pool, so i can do an more precise test.
webchain: no support planned, that's not a good algo for CPU, and i don't like how they changed the CN netcode conventions just because they could. Same for Hycon. Both coins can be mined with the CPU reference xmrig fork (possibly recompiled with zero fee), or on GPU with SRB.
I may add them later, but i'm getting less dev time those days and i need to choose between what i support or not. Currently i'm finishing the Stellite v8 fork.
The rigs in question are mining heavy/variants (XHV & TUBE atm,) and the report definitely shows CPU shares accepted. It's entirely possible it's just a coincidence that the missing effective h/r closely matches that of the actual CPU h/r, but then unfortunately, there's still an issue of effective only being ~95-96% of actual after days to weeks of uptime. Here's a snap of the API output for my intel 2700k setup. You can see that the effective is missing almost exactly the CPU actual h/r (though if you do add the CPU back in, effective would actually be higher than expected, given the unaccounted fee.) . I'm running a larger 8 RX 580 8G + ryzen 1600 setup in combo mode, and it's showing a ~3% diff, but it's only been up 36 hrs, so I'll run it a bit longer before reporting back. In the past, it stabilized around a similar 4-5% offset as this one, which happens to match the actual h/r of the CPU.
Code:
{
"hashrate":
{
"thread_0": 79.58,
"thread_1": 79.53,
"thread_2": 616.68,
"thread_3": 616.68,
"thread_4": 592.55,
"thread_5": 592.92,
"thread_6": 610.37,
"thread_7": 610.76,
"thread_all": [79.58, 79.53, 616.68, 616.68, 592.55, 592.92, 610.37, 610.76],
"thread_gpu": [1233.36, 1185.47, 1221.13],
"total": 3799.04,
"max": 4609.50
},
"result":
{
"wallet": "hvxyCNKKzE1QvQgDkZmzUVGUgGdM1fhiD2PLffSdcp6DK3mehDx1MtRW1ZzuNxW8ppS8QQsDbeqRy5u9vSYsxkrP3ZzkY1rU3W",
"pool": "ca.haven.miner.rocks:4005",
"ssl": false,
"reconnections": 163,
"currency": "Haven (XHV)",
"difficulty": 84531,
"shares": 50076,
"hashes": 1931628299,
"uptime": "147:16:23",
"effective": 3643.32
},
"gpu_status":
[
{ "index": 0, "temperature": 40, "fan": 36, "processor": "Ellesmere", "memory": 8192, "good_shares": 16484, "bad_shares": 0 },
{ "index": 1, "temperature": 39, "fan": 39, "processor": "Ellesmere", "memory": 8192, "good_shares": 15756, "bad_shares": 0 },
{ "index": 2, "temperature": 40, "fan": 35, "processor": "Ellesmere", "memory": 8192, "good_shares": 16553, "bad_shares": 0 }
],
"miner":
{
"version": "jce/0.33b14/gpu",
"platform": "Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz",
"system": "Windows 64-bits",
"algorithm": "12"
}
}
"hashrate":
{
"thread_0": 79.58,
"thread_1": 79.53,
"thread_2": 616.68,
"thread_3": 616.68,
"thread_4": 592.55,
"thread_5": 592.92,
"thread_6": 610.37,
"thread_7": 610.76,
"thread_all": [79.58, 79.53, 616.68, 616.68, 592.55, 592.92, 610.37, 610.76],
"thread_gpu": [1233.36, 1185.47, 1221.13],
"total": 3799.04,
"max": 4609.50
},
"result":
{
"wallet": "hvxyCNKKzE1QvQgDkZmzUVGUgGdM1fhiD2PLffSdcp6DK3mehDx1MtRW1ZzuNxW8ppS8QQsDbeqRy5u9vSYsxkrP3ZzkY1rU3W",
"pool": "ca.haven.miner.rocks:4005",
"ssl": false,
"reconnections": 163,
"currency": "Haven (XHV)",
"difficulty": 84531,
"shares": 50076,
"hashes": 1931628299,
"uptime": "147:16:23",
"effective": 3643.32
},
"gpu_status":
[
{ "index": 0, "temperature": 40, "fan": 36, "processor": "Ellesmere", "memory": 8192, "good_shares": 16484, "bad_shares": 0 },
{ "index": 1, "temperature": 39, "fan": 39, "processor": "Ellesmere", "memory": 8192, "good_shares": 15756, "bad_shares": 0 },
{ "index": 2, "temperature": 40, "fan": 35, "processor": "Ellesmere", "memory": 8192, "good_shares": 16553, "bad_shares": 0 }
],
"miner":
{
"version": "jce/0.33b14/gpu",
"platform": "Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz",
"system": "Windows 64-bits",
"algorithm": "12"
}
}
Hi All,
What is the best setting bittube or heavy for RX 570 4g Saphire nitro ++
Also share test result hash rate for that..
Thanks.
What is the best setting bittube or heavy for RX 570 4g Saphire nitro ++
Also share test result hash rate for that..
Thanks.
delay: that's an option that already exists in xmrstak, with a default of 40%. in jce this is automated, and yes it's related to the warmup. i won't add it as manual param, i'm confident with my automated values.
Right! Automated delay is better than manual tuning...
nVidia: no there won't be sorry.
delay: that's an option that already exists in xmrstak, with a default of 40%. in jce this is automated, and yes it's related to the warmup. i won't add it as manual param, i'm confident with my automated values.
delay: that's an option that already exists in xmrstak, with a default of 40%. in jce this is automated, and yes it's related to the warmup. i won't add it as manual param, i'm confident with my automated values.
Hi JCE! Doc releases new version of his miner and added thread_delay option. It can be changed manually for each GPU. Is this is what your miner does during warm-up? It try to find best thread delay? Delay between starting mining on 2 or more threads on one GPU?
Any hopes on implementing nVidia GPUs compatibility?
ETH: that's very different from CN, the whole miner not just the algo. i didn't have time to add webchain, i really cannot redo a miner from scratch 
disable cpu: --no-cpu param.
i'll clean the github doc to state there won't be a gpu linux miner. cpu linux exists.
i advise you use TeamRed for Linux, it's great!
disable cpu: --no-cpu param.
i'll clean the github doc to state there won't be a gpu linux miner. cpu linux exists.
i advise you use TeamRed for Linux, it's great!
Just checking .. but you don't have a GPU version for Linux, right?
Quote
by https://github.com/jceminer/cn_gpu_miner, "No Linux version (possible but unlikely)"
Hi JCE,
most likely ETH will switch to ProgPow, so are you planning to support ProgPow in your miner?
Thanks.
most likely ETH will switch to ProgPow, so are you planning to support ProgPow in your miner?
Thanks.
Command for disable cpu mining on JCE
exe file: I don't get it... sure each release has a different exe file, that's the purpose of the updates...
progress: i'm not sure of what you ask for, but the next release will get :
Do you need it or I can wait for the Masari fork too? That would be a minor release and the fork is not useful yet, except for tests.
edit: tests done, and the CPU perfs are quite good. Will be version 0.33n but i won't release it yet, since the changes are too minor. If a coin already uses Stellite v8, or a Masari test pool exists somewhere, please tell me
progress: i'm not sure of what you ask for, but the next release will get :
Quote
Stellite v8 available as --variation 21
--rig-id parameter, to set rig-id on pool
miner agent id fixed
--rig-id parameter, to set rig-id on pool
miner agent id fixed
Do you need it or I can wait for the Masari fork too? That would be a minor release and the fork is not useful yet, except for tests.
edit: tests done, and the CPU perfs are quite good. Will be version 0.33n but i won't release it yet, since the changes are too minor. If a coin already uses Stellite v8, or a Masari test pool exists somewhere, please tell me
Whats the progress?
How configure no cpu usage command. Also .exe file in different version are different..!!!
i'm polishing the test right now.
And this fork is a good fork for CPU mining, with a half main loop. Good for AES CPUs.
Ryzen +GPU test, on the default pool
On 3 minutes the hashrates didn't converge well, but my CPU, as fast as each GPU (3x stock RX560) gave similar results.
So far it looks to work, please look for those log patterns:
if there are, so it works.
Also try to add parameter --legacy which helps to lower the CPU pressure when mining on GPU+CPU (at the cost of a very little loss on GPU side, but better perf on CPU). It may have more or less effect (if any) depending on your rig.
I also fixed a bug that made JCE identify itself pool-side as MultiMiner 1.4, a stub i made to test the Pool Autoswitch on Monero Ocean and that i forgot to revert. It's very negligible, i just warn in case you observed such a change pool side. Will be in next version. I'm also adding the rigid key at pool login
And this fork is a good fork for CPU mining, with a half main loop. Good for AES CPUs.
Ryzen +GPU test, on the default pool
Code:
13:53:18 | Pool changes Difficulty to 35790.
13:53:19 | GPU 0 Thread 8 Lane 182 finds a Share, value 35790
13:53:19 | Stale Share that may be refused by the pool.
13:53:19 | Accepted by the pool in 68 ms.
13:53:21 | CPU Thread 6 finds a Share, value 35790
13:53:21 | Accepted by the pool in 105 ms.
13:53:33 | Pool pool.monero.hashvault.pro:3333
13:53:33 | Reconnections 0
13:53:33 | Currency Monero (XMR/XMV)
13:53:33 | Current pool Difficulty 35790
13:53:33 | Accepted Shares 12
13:53:33 | Total Hashes 347490
13:53:33 | Miner uptime 0:03:56
13:53:33 | Effective net hashrate 1472.42 h/s
13:53:33 | Devices results - Shares Accepted/Ignored/Rejected - Net Hashrate
13:53:33 | * CPUs - 2/0/0 - 215.21 h/s
13:53:33 | * GPU 0 - 2/0/0 - 341.95 h/s
13:53:33 | * GPU 1 - 3/0/0 - 330.51 h/s
13:53:33 | * GPU 2 - 5/0/0 - 584.75 h/s
On 3 minutes the hashrates didn't converge well, but my CPU, as fast as each GPU (3x stock RX560) gave similar results.
So far it looks to work, please look for those log patterns:
Code:
13:53:21 | CPU Thread 6 finds a Share, value 35790
13:53:21 | Accepted by the pool in 105 ms.
Also try to add parameter --legacy which helps to lower the CPU pressure when mining on GPU+CPU (at the cost of a very little loss on GPU side, but better perf on CPU). It may have more or less effect (if any) depending on your rig.
I also fixed a bug that made JCE identify itself pool-side as MultiMiner 1.4, a stub i made to test the Pool Autoswitch on Monero Ocean and that i forgot to revert. It's very negligible, i just warn in case you observed such a change pool side. Will be in next version. I'm also adding the rigid key at pool login
Jump to: