Pages:
Author

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

member
Activity: 350
Merit: 22
My CPU code is now ready, version 0.33a to be released soon, with:

Quote
Monero-v8 (enabled by default for XMR and WOW), that's --variation 15
32-bits and 64-bits support
Windows and Linux
Fix a bug that could make high multi_hash (x4 to x6) produce bad shares on Electroneum.
More shitcoins (Tritanium, Zelerius, HospitalCoin, PyrexCoin)

Now entering test phase, planned release in less than 24h hours

Quote
Threadripper 1920X

Your config lacks some multihash, with 32M cache and 24 logical cores, you can achieve more performance.
For monero, enable 16 threads, on logical CPUs:
0, 1, 2, 4, 6, 8, 10, 11, 12, 13, 14, 16, 18, 20, 22, 23

For aeon, AMD cpu are more complicated, enable all logical CPU as you did, plus turn some as multi_hash:2
try turning 0 and 12, and if you get more perf, also try 6 and 18, then also 3 and 15, and finally 9 and 21
full member
Activity: 729
Merit: 114
Some results from threadripper 1920x

XMR mining,
1090 H/s @ 3.8 Ghz 1.050V 96w


1030 H/s @ 3.6 Ghz 0.975V 84w


AEON mining,
4550 H/s @ 3.8 Ghz 1.050V 122w
member
Activity: 350
Merit: 22
Hi all!

Again I do very little support, i'm focusing on the v8 assembly. I've one that works, but i'm not satisfied with the performance yet, so i need to improve it. If i'm really stuck, i'll write some parts in C and rewrite to ASM later. I also need to keep room for the tests. I'll skip the formal performance benchmark against other miners like I did for V7 in april, i just have no time.

About the hashrate drop every 24h: i still did a quick review of my netcode, and really found nothing with a 24h period. Could it be some bottleneck with your wifi or ISP?
The fee session period is ~100 mn, like Claymore or SRB, but really not 24h. Also, stale shares are amplified by a high ping, hence why i suspect your network.
The symptom may not arise on other miner because we have different stale share aggressivity, JCE is mid-high aggressive while Claymore is smooth, so this latter provides a lower effective hashrate, but is less sensitive to bad ping.

Bad warmup: yeah it's a known problem, but can by avoided with a combination of Watchdog and script (.bat) that restarts the miner in case of disconnect that makes it slower. Also the option -q quits the miner at first network problem, it can be used in place of the watchdog, or even both. Since JCE starts in a few seconds now, it's an convinient workaround.

What's sad is that is would be very simple to re-trigger the warmup after a disconnect in my netcode, just that v8 forks eats all my dev time.
sr. member
Activity: 1484
Merit: 253
Hi JCE,

i updated my 3 Rigs to JCE Miner. It works great, effective hash increase, but i have a problem.



At around 3:30 o´clock all 3 rigs deliver stale shares for around 1.5 hours, 5 days in a row. Other people in this pool don´t have this problem, other miner (for example SRB) don´t have this problem. If it is on 1 Rig then i say ok to much OC, but 3 realy different rigs with different cards and different drivers make the same problem? i think it is a jce miner problem. A Ryzen R5 1600 delivers also stales shares and with the older version 0.32m it works.
I use jce 0.32q at the moment. Any solution or other guys with this problem?

JCE there is a problem in your code or something like this.

Rig1 with JCE 0.32q mining on nanopool normal port -> all fine
Rig2 with SRB 1.6.7 mining on nanopool ssl port -> all fine
Rig3 wtih JCE 0.32q mining on nanopool ssl port -> from 3:30 to around 5 o´clock only stale shares, tested 3 days in a row
Test GPU with JCE 0.32q mining on nanopool ssl port -> from 3:30 to around 5 o´clock only stale shares, tested 3 days in a row
I'm use ssl port on nicehash pool with CPU and GPU on 0.32q without any issues during several days in a row. Maybe nanopool did something with ssl port in your pointed time?
member
Activity: 1558
Merit: 69
Hi JCE,

i updated my 3 Rigs to JCE Miner. It works great, effective hash increase, but i have a problem.



At around 3:30 o´clock all 3 rigs deliver stale shares for around 1.5 hours, 5 days in a row. Other people in this pool don´t have this problem, other miner (for example SRB) don´t have this problem. If it is on 1 Rig then i say ok to much OC, but 3 realy different rigs with different cards and different drivers make the same problem? i think it is a jce miner problem. A Ryzen R5 1600 delivers also stales shares and with the older version 0.32m it works.
I use jce 0.32q at the moment. Any solution or other guys with this problem?

JCE there is a problem in your code or something like this.

Rig1 with JCE 0.32q mining on nanopool normal port -> all fine
Rig2 with SRB 1.6.7 mining on nanopool ssl port -> all fine
Rig3 wtih JCE 0.32q mining on nanopool ssl port -> from 3:30 to around 5 o´clock only stale shares, tested 3 days in a row
Test GPU with JCE 0.32q mining on nanopool ssl port -> from 3:30 to around 5 o´clock only stale shares, tested 3 days in a row

jr. member
Activity: 176
Merit: 2
I don't know it's a bug or not!my miner work find on cn-saber with 8K,but after a disconnected from pool and reconnected again,the hashrade drop to about 7300 and won't restore to 8K,i have to restart the miner to get 8K again... here is the log

You can see a Connection interrupted and reconnect at 05:04:11, then the hashrade drop to about 7.3K!This happend on all of my miners so i think i have to report this!

it's known issue for Heavy variant after reconnecting JCE not doing warm up again. what I do is put watchdog and if miner close then restart rig.
newbie
Activity: 49
Merit: 0
I don't know it's a bug or not!my miner work find on cn-saber with 8K,but after a disconnected from pool and reconnected again,the hashrade drop to about 7300 and won't restore to 8K,i have to restart the miner to get 8K again... here is the log


05:01:03 | Hashrate GPU Thread 0: 500.58 h/s
05:01:03 | Hashrate GPU Thread 1: 500.58 h/s - Total GPU 0: 1001.15 h/s
05:01:03 | Hashrate GPU Thread 2: 502.17 h/s
05:01:03 | Hashrate GPU Thread 3: 502.12 h/s - Total GPU 1: 1004.28 h/s
05:01:03 | Hashrate GPU Thread 4: 500.68 h/s
05:01:03 | Hashrate GPU Thread 5: 500.68 h/s - Total GPU 2: 1001.35 h/s
05:01:03 | Hashrate GPU Thread 6: 502.12 h/s
05:01:03 | Hashrate GPU Thread 7: 499.15 h/s - Total GPU 3: 1001.26 h/s
05:01:03 | Hashrate GPU Thread 8: 502.17 h/s
05:01:03 | Hashrate GPU Thread 9: 500.68 h/s - Total GPU 4: 1002.84 h/s
05:01:03 | Hashrate GPU Thread 10: 500.68 h/s
05:01:03 | Hashrate GPU Thread 11: 500.68 h/s - Total GPU 5: 1001.35 h/s
05:01:03 | Hashrate GPU Thread 12: 502.12 h/s
05:01:03 | Hashrate GPU Thread 13: 500.68 h/s - Total GPU 6: 1002.79 h/s
05:01:03 | Hashrate GPU Thread 14: 502.02 h/s
05:01:03 | Hashrate GPU Thread 15: 502.12 h/s - Total GPU 7: 1004.14 h/s
05:01:03 | Total: 8019.11 h/s - Max: 8022.47 h/s
05:01:12 | GPU 2 Thread 5 Lane 820 finds a Share, value 400015
05:01:12 | Accepted by the pool in 406 ms.
05:01:16 | Pool sends a new Job.
05:02:09 | Pool xxx.xxx.xxx.xxx:xxxx
05:02:09 | Reconnections 0
05:02:09 | Currency BitTube (TUBE)
05:02:09 | Current pool Difficulty 400015
05:02:09 | Accepted Shares 1154
05:02:09 | Total Hashes 461617310
05:02:09 | Miner uptime 15:40:05
05:02:09 | Effective net hashrate 8183.98 h/s
05:02:09 | Devices results - Shares Accepted/Ignored/Rejected - Net Hashrate
05:02:09 | * GPU 0 - 149/0/0 - 1056.68 h/s
05:02:09 | * GPU 1 - 129/0/0 -  914.85 h/s
05:02:09 | * GPU 2 - 147/0/0 - 1042.50 h/s
05:02:09 | * GPU 3 - 137/0/0 -  971.58 h/s
05:02:09 | * GPU 4 - 127/0/0 -  900.66 h/s
05:02:09 | * GPU 5 - 148/0/0 - 1049.59 h/s
05:02:09 | * GPU 6 - 164/0/0 - 1163.06 h/s
05:02:09 | * GPU 7 - 153/0/0 - 1085.05 h/s
05:02:58 | Pool sends a new Job.
05:03:55 | GPU 7 Thread 15 Lane 88 finds a Share, value 400015
05:04:11 | Connection failed: Pool response timeout.
05:04:11 | Connection interrupted, waiting 5s then retry, attempt #1
05:04:15 | Connecting to mining pool xxx.xxx.xxx.xx:xxxx ...
05:04:15 | Connected to pool. Now logging in...
05:04:16 | Successfuly logged as bxdLhsWY56SNjVN2aQ5Yyb6hhCFfAQJVbYsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.400000
05:04:16 | Pool changes Difficulty to 400015.
05:04:28 | GPU 5 Thread 10 Lane 279 finds a Share, value 400015
05:04:28 | Accepted by the pool in 391 ms.
05:04:29 | GPU 0: Temp: 57C - Fan: 99% -- Shares: Good: 149 Bad: 0
05:04:29 | GPU 1: Temp: 56C - Fan: 99% -- Shares: Good: 130 Bad: 0
05:04:29 | GPU 2: Temp: 53C - Fan: 99% -- Shares: Good: 148 Bad: 0
05:04:29 | GPU 3: Temp: 54C - Fan: 99% -- Shares: Good: 138 Bad: 0
05:04:29 | GPU 4: Temp: 56C - Fan: 99% -- Shares: Good: 129 Bad: 0
05:04:29 | GPU 5: Temp: 55C - Fan: 99% -- Shares: Good: 151 Bad: 0
05:04:29 | GPU 6: Temp: 56C - Fan: 99% -- Shares: Good: 166 Bad: 0
05:04:29 | GPU 7: Temp: 52C - Fan: 99% -- Shares: Good: 155 Bad: 0
05:04:36 | Pool sends a new Job.
05:04:36 | Hashrate GPU Thread 0: 458.10 h/s
05:04:36 | Hashrate GPU Thread 1: 456.86 h/s - Total GPU 0: 914.96 h/s
05:04:36 | Hashrate GPU Thread 2: 453.18 h/s
05:04:36 | Hashrate GPU Thread 3: 453.18 h/s - Total GPU 1: 906.35 h/s
05:04:36 | Hashrate GPU Thread 4: 454.44 h/s
05:04:36 | Hashrate GPU Thread 5: 453.18 h/s - Total GPU 2: 907.61 h/s
05:04:36 | Hashrate GPU Thread 6: 453.18 h/s
05:04:36 | Hashrate GPU Thread 7: 453.18 h/s - Total GPU 3: 906.35 h/s
05:04:36 | Hashrate GPU Thread 8: 488.96 h/s
05:04:36 | Hashrate GPU Thread 9: 493.35 h/s - Total GPU 4: 982.31 h/s
05:04:36 | Hashrate GPU Thread 10: 458.79 h/s
05:04:36 | Hashrate GPU Thread 11: 456.82 h/s - Total GPU 5: 915.61 h/s
05:04:36 | Hashrate GPU Thread 12: 453.18 h/s
05:04:36 | Hashrate GPU Thread 13: 455.07 h/s - Total GPU 6: 908.25 h/s
05:04:36 | Hashrate GPU Thread 14: 453.18 h/s
05:04:36 | Hashrate GPU Thread 15: 451.42 h/s - Total GPU 7: 904.59 h/s
05:04:36 | Total: 7346.00 h/s - Max: 8022.47 h/s


You can see a Connection interrupted and reconnect at 05:04:11, then the hashrade drop to about 7.3K!This happend on all of my miners so i think i have to report this!
member
Activity: 340
Merit: 29
Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !
Speed of heavy algo on 8Gb+ cards allways faster than on V7. It's normal.

I thought it was 1,5KH/s on CN Heavy (Vega 56/64) and 2K/s on V7. Huh

Vegas took a hit.  RX4/5XX 8Gb got a 5-10% bump from heavy.
sr. member
Activity: 1106
Merit: 251
hi JCE Miner! I love your miner. But I wish you also include Monero v8 variant in your next release version of this miner because Wownero have changed to it already in anticipation to Monero's soon move to it.
newbie
Activity: 3
Merit: 0
Hi,
I've been trying to run jce_cn_gpu_miner.032q and jce_cn_gpu_miner.prototype.032n on this card. I'm using Windows 10 and 18.8.1 drivers. No overclock. Card Sapphire Radeon RX 560 4GB
+------------------------------------------+
| JC Expert Cryptonote CPU+GPU Miner 0.32n |
+------------------------------------------+

For Windows 64-bits
Analyzing Processors topology...
AMD Ryzen 5 1600 Six-Core Processor
Assembly codename: ryzen
SSE2 : Yes
SSE3 : Yes
SSE4 : Yes
AES : Yes
AVX : Yes
AVX2 : Yes

Found CPU 0, with:
L1 Cache: 32 KB, shared with CPU 1
L2 Cache: 512 KB, shared with CPU 1
L3 Cache: 8192 KB, shared with CPU 1, 2, 3, 4, 5
Found CPU 1, with:
L1 Cache: 32 KB, shared with CPU 0
L2 Cache: 512 KB, shared with CPU 0
L3 Cache: 8192 KB, shared with CPU 0, 2, 3, 4, 5
Found CPU 2, with:
L1 Cache: 32 KB, shared with CPU 3
L2 Cache: 512 KB, shared with CPU 3
L3 Cache: 8192 KB, shared with CPU 0, 1, 3, 4, 5
Found CPU 3, with:
L1 Cache: 32 KB, shared with CPU 2
L2 Cache: 512 KB, shared with CPU 2
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 4, 5
Found CPU 4, with:
L1 Cache: 32 KB, shared with CPU 5
L2 Cache: 512 KB, shared with CPU 5
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 5
Found CPU 5, with:
L1 Cache: 32 KB, shared with CPU 4
L2 Cache: 512 KB, shared with CPU 4
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 4
Found CPU 6, with:
L1 Cache: 32 KB, shared with CPU 7
L2 Cache: 512 KB, shared with CPU 7
L3 Cache: 8192 KB, shared with CPU 7, 8, 9, 10, 11
Found CPU 7, with:
L1 Cache: 32 KB, shared with CPU 6
L2 Cache: 512 KB, shared with CPU 6
L3 Cache: 8192 KB, shared with CPU 6, 8, 9, 10, 11
Found CPU 8, with:
L1 Cache: 32 KB, shared with CPU 9
L2 Cache: 512 KB, shared with CPU 9
L3 Cache: 8192 KB, shared with CPU 6, 7, 9, 10, 11
Found CPU 9, with:
L1 Cache: 32 KB, shared with CPU 8
L2 Cache: 512 KB, shared with CPU 8
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 10, 11
Found CPU 10, with:
L1 Cache: 32 KB, shared with CPU 11
L2 Cache: 512 KB, shared with CPU 11
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 9, 11
Found CPU 11, with:
L1 Cache: 32 KB, shared with CPU 10
L2 Cache: 512 KB, shared with CPU 10
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 9, 10

Detecting OpenCL-capable GPUs...
Pм)╨╫�


+------------------------------------------+
| JC Expert Cryptonote CPU+GPU Miner 0.32q |
+------------------------------------------+

For Windows 64-bits
Analyzing Processors topology...
AMD Ryzen 5 1600 Six-Core Processor
Assembly codename: ryzen
SSE2 : Yes
SSE3 : Yes
SSE4 : Yes
AES : Yes
AVX : Yes
AVX2 : Yes

Auto-configuration, selected CPUs will be highlighted...
Found CPU 0, with:
L1 Cache: 32 KB, shared with CPU 1
L2 Cache: 512 KB, shared with CPU 1
L3 Cache: 8192 KB, shared with CPU 1, 2, 3, 4, 5
Found CPU 1, with:
L1 Cache: 32 KB, shared with CPU 0
L2 Cache: 512 KB, shared with CPU 0
L3 Cache: 8192 KB, shared with CPU 0, 2, 3, 4, 5
Found CPU 2, with:
L1 Cache: 32 KB, shared with CPU 3
L2 Cache: 512 KB, shared with CPU 3
L3 Cache: 8192 KB, shared with CPU 0, 1, 3, 4, 5
Found CPU 3, with:
L1 Cache: 32 KB, shared with CPU 2
L2 Cache: 512 KB, shared with CPU 2
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 4, 5
Found CPU 4, with:
L1 Cache: 32 KB, shared with CPU 5
L2 Cache: 512 KB, shared with CPU 5
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 5
Found CPU 5, with:
L1 Cache: 32 KB, shared with CPU 4
L2 Cache: 512 KB, shared with CPU 4
L3 Cache: 8192 KB, shared with CPU 0, 1, 2, 3, 4
Found CPU 6, with:
L1 Cache: 32 KB, shared with CPU 7
L2 Cache: 512 KB, shared with CPU 7
L3 Cache: 8192 KB, shared with CPU 7, 8, 9, 10, 11
Found CPU 7, with:
L1 Cache: 32 KB, shared with CPU 6
L2 Cache: 512 KB, shared with CPU 6
L3 Cache: 8192 KB, shared with CPU 6, 8, 9, 10, 11
Found CPU 8, with:
L1 Cache: 32 KB, shared with CPU 9
L2 Cache: 512 KB, shared with CPU 9
L3 Cache: 8192 KB, shared with CPU 6, 7, 9, 10, 11
Found CPU 9, with:
L1 Cache: 32 KB, shared with CPU 8
L2 Cache: 512 KB, shared with CPU 8
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 10, 11
Found CPU 10, with:
L1 Cache: 32 KB, shared with CPU 11
L2 Cache: 512 KB, shared with CPU 11
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 9, 11
Found CPU 11, with:
L1 Cache: 32 KB, shared with CPU 10
L2 Cache: 512 KB, shared with CPU 10
L3 Cache: 8192 KB, shared with CPU 6, 7, 8, 9, 10

Detecting OpenCL-capable GPUs...
Found GPU 0, with:
Vendor: AMD
Processor: Baffin
Device: 09:00
Compute-Units: 16
Cache Memory: 16 KB
Local Memory: 32 KB
Global Memory: 4096 MB
Addressing: 64-bits

Preparing 10 Mining Threads...

+-- Thread 0 config -----------------------+
| Run on CPU: 0 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 1 config -----------------------+
| Run on CPU: 1 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 2 config -----------------------+
| Run on CPU: 2 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 3 config -----------------------+
| Run on CPU: 4 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 4 config -----------------------+
| Run on CPU: 6 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 5 config -----------------------+
| Run on CPU: 7 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 6 config -----------------------+
| Run on CPU: 8 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 7 config -----------------------+
| Run on CPU: 10 |
| Use cache: yes |
| Multi-hash: no |
| Assembly module: ryzen |
+------------------------------------------+

+-- Thread 8 config -----------------------+
| Run on GPU: 0 |
| Multi-hash: 464 |
| Worksize: 8 |
| Factor Alpha 64 |
| Factor Beta 8 |
+------------------------------------------+

+-- Thread 9 config -----------------------+
| Run on GPU: 0 |
| Multi-hash: 464 |
| Worksize: 8 |
| Factor Alpha 64 |
| Factor Beta 8 |
+------------------------------------------+

Cryptonight Variation: Cryptonight V7 fork of April-2018

Low intensity.

Starting CPU Mining thread 0, affinity: CPU 0
Thread 0 successfully bound to CPU 0
Allocated shared Large Page at: 0000023044c00000
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 0 of NUMA node 0 at: 0000023044e00000

Starting CPU Mining thread 1, affinity: CPU 1
Thread 1 successfully bound to CPU 1
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 1 of NUMA node 0 at: 0000023045000000

Starting CPU Mining thread 2, affinity: CPU 2
Thread 2 successfully bound to CPU 2
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 2 of NUMA node 0 at: 0000023045200000

Starting CPU Mining thread 3, affinity: CPU 4
Thread 3 successfully bound to CPU 4
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 4 of NUMA node 0 at: 0000023045400000

Starting CPU Mining thread 4, affinity: CPU 6
Thread 4 successfully bound to CPU 6
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 6 of NUMA node 0 at: 0000023045600000

Starting CPU Mining thread 5, affinity: CPU 7
Thread 5 successfully bound to CPU 7
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 7 of NUMA node 0 at: 0000023045800000

Starting CPU Mining thread 6, affinity: CPU 8
Thread 6 successfully bound to CPU 8
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 8 of NUMA node 0 at: 0000023045a00000

Starting CPU Mining thread 7, affinity: CPU 10
Thread 7 successfully bound to CPU 10
Allocated 2MB Cached Large Page Scratchpad Buffer for CPU 10 of NUMA node 0 at: 0000023045c00000

Starting GPU Mining thread 8, on GPU 0
Created OpenCL Context for GPU 0 at 000002304485e040
Created OpenCL Thread 8 Command-Queue for GPU 0 at 0000023044872e10
Scratchpad Allocation success for OpenCL Thread 8
Allocating big 928MB scratchpad for OpenCL Thread 8...
Compiling kernels of OpenCL Thread 8...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10

Starting GPU Mining thread 9, on GPU 0
Created OpenCL Thread 9 Command-Queue for GPU 0 at 0000023044846400
Scratchpad Allocation success for OpenCL Thread 9
Allocating big 928MB scratchpad for OpenCL Thread 9...
Compiling kernels of OpenCL Thread 9...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10
Devfee for CPU is 1.5%
Devfee for GPU is 0.9%

15:34:41 | OpenCL Thread 8 failed, Stop.
15:34:41 | Unloaded OpenCL kernels of GPU Thread 8
15:34:41 | Connecting to mining pool pool.supportxmr.com:5555 ...
15:34:41 | Monero (XMR/XMV) Mining session starts!

During mining time, press:
h display hashrate for each mining thread.
r display full report.
p pause all.
u pause CPUs.
0-F pause GPU 0-15.
t GPU temperature and fan speed.
q quit.

15:34:41 | GPU Compute allocation starts at 80% and reaches 100% after ~5min,
15:34:41 | during this time, the hashrate may be unstable and inconsistent.
15:34:41 | Let the miner warm-up if you're tuning for performance.
15:34:41 | OpenCL Thread 9 failed, Stop.
15:34:41 | Unloaded OpenCL kernels of GPU Thread 9
15:34:41 | Released OpenCL Thread 8 Scratchpad at 000002304ad32ac0
15:34:41 | Released OpenCL Thread 9 Scratchpad at 00000230449d9fb0
15:34:41 | Released OpenCL Thread 8 Command-Queue of GPU 0 at 0000023044872e10
15:34:42 | Released OpenCL Thread 9 Command-Queue of GPU 0 at 0000023044846400
15:34:42 | Connected to pool. Now logging in...
15:34:42 | Successfuly logged as 47aepaEmi318XjZV5k5Svf4jYdzb4dKcZX7bLbSPCP41Ade7NZs816rjXqrT3anyZ22j7DEE74GkbVc QFyH2nNiC3hzR3gr
15:34:42 | Pool changes Difficulty to 10000.

Any thoughts on that? xmr-stak, Claymore and other GPU miners work just fine.
newbie
Activity: 76
Merit: 0
Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !
Speed of heavy algo on 8Gb+ cards allways faster than on V7. It's normal.

Good to know ! i tried Alloy too and it was half of my normal speed. i was sure heavy algo was a bit slower in speed.
full member
Activity: 1120
Merit: 131
Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !
Speed of heavy algo on 8Gb+ cards allways faster than on V7. It's normal.

I thought it was 1,5KH/s on CN Heavy (Vega 56/64) and 2K/s on V7. Huh
sr. member
Activity: 1484
Merit: 253
Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !
Speed of heavy algo on 8Gb+ cards allways faster than on V7. It's normal.
newbie
Activity: 76
Merit: 0
Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !
newbie
Activity: 26
Merit: 1
Hey hey hey! Maybe it was asked before (at least i couldn't find it).
Any plan of adding webchain to the list of supported coins? Cheesy

Cheers!
member
Activity: 90
Merit: 10
hi, gpu 0 for me has lower hash rate then the other gpu's, same OC settings and parameters in miner, is it because it has a monitor plugged in? difference in hashrate is noticable

also 1 gpu on CN heavy is averaging around 460h/s but has spiked to 590 h/s! is that normal on CN-heavy?



It's normal to get a lower hashrate on a GPU that has a monitor plugged into it. Either power down the monitor and disconnect it from the card, or setup Windows startup programs to automatically run your miner program on system boot up. The latter will be the best option IMO as your miner will automatically restart after a system reboot from a Windows update or something with no monitor connection or interaction from you required. Some guys disable Windows update, I don't. There are many reason Windows needs to be up to date. Easy to find a step by step guide on Youtube to show you how to add a program to the Windows start up folder.

Hashrates will be up and down depending on the share submitted, no worries.
Chris B.
newbie
Activity: 156
Merit: 0
Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature Smiley

I hope i'll be able to release the v8-capable CPU version soon.

Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.

Just sayin', so you don't get left behind  Wink


While i do agree with you and think that auto algo switch is a good idea and can create better profits, i also think that the way is currently implemented in other miners is very trivial and thus i refused to use it. The fact that you need to manually configure and test every algo is wasting time in my opinion. Another waste of time is that in the current trivial implementation, the miner has to restart when changing the algo.

What i really hope is that in the future more altcoins will implement algos that are very compatible with what Monero is putting out there and that due to this, miner software can be modified to perform an auto algo switch as fast as they do the devfee switch.

At this point i find the current implementation of algo switch more of an interruption to mining with very small increase in profits.



XMrig does what you describe, it changes algo without restart or compile and it will also benchmark your rig so you are left just with the fine tuning.
I hope that something similar can be implemented into JCE and others, especially SRBminer that has really awkward and way too long algo changes ( restart + compile + warmup ), which makes it useless for algo switching
Miner developers should really look at MoneroOcean + XMrig, algo switching is done on the fly and really well implemented, and since we have tons of CN based coins one could assume algo switching is gonna become even more popular in the future.

You can check CN mining pool profits below ( especially for last half a year ).
https://moneroocean.stream/profits/

XMrig for cpu version change algo without restart not gpu.
Compile needs only once on SRB, not every restart  Grin
full member
Activity: 327
Merit: 100
Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature Smiley

I hope i'll be able to release the v8-capable CPU version soon.

Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.

Just sayin', so you don't get left behind  Wink


While i do agree with you and think that auto algo switch is a good idea and can create better profits, i also think that the way is currently implemented in other miners is very trivial and thus i refused to use it. The fact that you need to manually configure and test every algo is wasting time in my opinion. Another waste of time is that in the current trivial implementation, the miner has to restart when changing the algo.

What i really hope is that in the future more altcoins will implement algos that are very compatible with what Monero is putting out there and that due to this, miner software can be modified to perform an auto algo switch as fast as they do the devfee switch.

At this point i find the current implementation of algo switch more of an interruption to mining with very small increase in profits.



XMrig does what you describe, it changes algo without restart or compile and it will also benchmark your rig so you are left just with the fine tuning.
I hope that something similar can be implemented into JCE and others, especially SRBminer that has really awkward and way too long algo changes ( restart + compile + warmup ), which makes it useless for algo switching
Miner developers should really look at MoneroOcean + XMrig, algo switching is done on the fly and really well implemented, and since we have tons of CN based coins one could assume algo switching is gonna become even more popular in the future.

You can check CN mining pool profits below ( especially for last half a year ).
https://moneroocean.stream/profits/
newbie
Activity: 39
Merit: 0
Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature Smiley

I hope i'll be able to release the v8-capable CPU version soon.

Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.

Just sayin', so you don't get left behind  Wink


While i do agree with you and think that auto algo switch is a good idea and can create better profits, i also think that the way is currently implemented in other miners is very trivial and thus i refused to use it. The fact that you need to manually configure and test every algo is wasting time in my opinion. Another waste of time is that in the current trivial implementation, the miner has to restart when changing the algo.

What i really hope is that in the future more altcoins will implement algos that are very compatible with what Monero is putting out there and that due to this, miner software can be modified to perform an auto algo switch as fast as they do the devfee switch.

At this point i find the current implementation of algo switch more of an interruption to mining with very small increase in profits.

full member
Activity: 327
Merit: 100
Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature Smiley

I hope i'll be able to release the v8-capable CPU version soon.

Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.

Just sayin', so you don't get left behind  Wink
Pages:
Jump to: