 Show Posts
|
|
Pages: [1] 2 »
|
I have the same problem on 4 rigs with 4 various Vega 56 cards (ref with samsun g and asus/powercolor with hynix, with timings and without timings ). The card runs for an hour or two and then the hash rate drops to zero or to 1400 h/s with a DEAD message. I have observed in several rigs, but for some reason problems always with the first PCI slot (PCIe 3:0.0). If you do not stick the card into the first PCI slot (PCI 16x), then the problem disappears. Now I just do not use 16x pci slot  Hi, interesting... for me it is GPU4 and it is located at PCIex16 slot too. LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- |
|
|
|
2 kerney666
Hi, my rig can't run longer then 1-2 hours on v 0.4.5 and newer. One GPU hangs (this is from 0.5.1 after autoconfig):
[2019-06-10 21:22:55] GPU 0 [57C, fan 87%] cnr: 2.486kh/s, avg 2.477kh/s, pool 2.709kh/s a:46 r:0 hw:0
[2019-06-10 21:22:55] GPU 1 [58C, fan 85%] cnr: 2.490kh/s, avg 2.482kh/s, pool 1.261kh/s a:22 r:0 hw:0
[2019-06-10 21:22:55] GPU 2 [56C, fan 86%] cnr: 2.486kh/s, avg 2.478kh/s, pool 2.969kh/s a:51 r:0 hw:1
[2019-06-10 21:22:55] GPU 3 [63C, fan 87%] cnr: 2.480kh/s, avg 2.468kh/s, pool 2.377kh/s a:42 r:0 hw:0
[2019-06-10 21:22:55] GPU 4 [45C, fan 90%] cnr: 2.483kh/s, avg 2.471kh/s, pool 2.737kh/s a:47 r:0 hw:3
[2019-06-10 21:22:55] Total cnr: 12.42kh/s, avg 12.38kh/s, pool 12.05kh/s a:208 r:0 hw:4
[2019-06-10 21:23:05] GPU 4: detected DEAD (11:00.0), will execute restart script watchdog.sh
but v0.4.4 with exactly same config can run for weeks:
[2019-06-10 19:40:27] Stats Uptime: 13 days, 12:58:15
[2019-06-10 19:40:27] GPU 0 [59C, fan 87%] cnr: 2.471kh/s, avg 2.470kh/s, pool 2.340kh/s a:7780 r:0 hw:17
[2019-06-10 19:40:27] GPU 1 [60C, fan 85%] cnr: 2.474kh/s, avg 2.473kh/s, pool 2.423kh/s a:8057 r:0 hw:39
[2019-06-10 19:40:27] GPU 2 [57C, fan 86%] cnr: 2.471kh/s, avg 2.471kh/s, pool 2.337kh/s a:7768 r:0 hw:106
[2019-06-10 19:40:27] GPU 3 [63C, fan 87%] cnr: 2.464kh/s, avg 2.464kh/s, pool 2.381kh/s a:7917 r:0 hw:73
[2019-06-10 19:40:27] GPU 4 [55C, fan 88%] cnr: 2.470kh/s, avg 2.468kh/s, pool 2.259kh/s a:7519 r:0 hw:321
[2019-06-10 19:40:27] Total cnr: 12.35kh/s, avg 12.35kh/s, pool 11.74kh/s a:39041 r:0 hw:556
[2019-06-10 19:40:39] Pool pool.supportxmr.com received new job. (job_id: +kOSIEF95a5dlkxX6slHR0EW+l34)
I know, I'm pushing hard on limit, but what changed in TR miner 0.4.5 that causes this instability? With 0.4.4 and older was this rig rock stable. OS is Linux & amd18.3 drivers.
Thank you for answer,
Migo
Hi! Man, it's such a hard question to answer. The changes between 0.4.4 and 0.4.5 are really tiny, and nothing that "should" affect anything in terms of stability. For cn/r, absolutely nothing of interest was touched in the kernels, and not anything specific in the host-side code either. For every release, we get a few people telling us how stable things are with the new version, then a others that (like you) unfortunately have a harder time keeping things running smoothly. Since you're running linux, do you see anything interesting in your "dmesg" output from the kernel when a crash occurs? -- K Hi, this time it run bit longer: [2019-06-12 04:25:27] GPU 4 [55C, fan 88%] cnr: 2.483kh/s, avg 2.485kh/s, pool 2.078kh/s a:225 r:0 hw:18 [2019-06-12 04:25:27] Total cnr: 12.42kh/s, avg 12.43kh/s, pool 11.40kh/s a:1240 r:0 hw:25 [2019-06-12 04:25:57] Stats Uptime: 0 days, 10:07:37 [2019-06-12 04:25:57] GPU 0 [60C, fan 88%] cnr: 2.484kh/s, avg 2.486kh/s, pool 2.371kh/s a:259 r:0 hw:0 [2019-06-12 04:25:57] GPU 1 [61C, fan 85%] cnr: 2.489kh/s, avg 2.490kh/s, pool 2.168kh/s a:236 r:0 hw:3 [2019-06-12 04:25:57] GPU 2 [57C, fan 86%] cnr: 2.485kh/s, avg 2.487kh/s, pool 2.320kh/s a:256 r:0 hw:2 [2019-06-12 04:25:57] GPU 3 [63C, fan 87%] cnr: 2.478kh/s, avg 2.480kh/s, pool 2.458kh/s a:264 r:0 hw:2 [2019-06-12 04:25:57] GPU 4 [46C, fan 89%] cnr: 2.484kh/s, avg 2.484kh/s, pool 2.076kh/s a:225 r:0 hw:18 [2019-06-12 04:25:57] Total cnr: 12.42kh/s, avg 12.43kh/s, pool 11.39kh/s a:1240 r:0 hw:25 [2019-06-12 04:26:09] GPU 4: detected DEAD (11:00.0), will execute restart script watchdog.sh relevant dmesg output sent to PM, don't want to pollute thread... Thanx, Milan |
|
|
|
2 kerney666
Hi, my rig can't run longer then 1-2 hours on v 0.4.5 and newer. One GPU hangs (this is from 0.5.1 after autoconfig):
[2019-06-10 21:22:55] GPU 0 [57C, fan 87%] cnr: 2.486kh/s, avg 2.477kh/s, pool 2.709kh/s a:46 r:0 hw:0
[2019-06-10 21:22:55] GPU 1 [58C, fan 85%] cnr: 2.490kh/s, avg 2.482kh/s, pool 1.261kh/s a:22 r:0 hw:0
[2019-06-10 21:22:55] GPU 2 [56C, fan 86%] cnr: 2.486kh/s, avg 2.478kh/s, pool 2.969kh/s a:51 r:0 hw:1
[2019-06-10 21:22:55] GPU 3 [63C, fan 87%] cnr: 2.480kh/s, avg 2.468kh/s, pool 2.377kh/s a:42 r:0 hw:0
[2019-06-10 21:22:55] GPU 4 [45C, fan 90%] cnr: 2.483kh/s, avg 2.471kh/s, pool 2.737kh/s a:47 r:0 hw:3
[2019-06-10 21:22:55] Total cnr: 12.42kh/s, avg 12.38kh/s, pool 12.05kh/s a:208 r:0 hw:4
[2019-06-10 21:23:05] GPU 4: detected DEAD (11:00.0), will execute restart script watchdog.sh
but v0.4.4 with exactly same config can run for weeks:
[2019-06-10 19:40:27] Stats Uptime: 13 days, 12:58:15
[2019-06-10 19:40:27] GPU 0 [59C, fan 87%] cnr: 2.471kh/s, avg 2.470kh/s, pool 2.340kh/s a:7780 r:0 hw:17
[2019-06-10 19:40:27] GPU 1 [60C, fan 85%] cnr: 2.474kh/s, avg 2.473kh/s, pool 2.423kh/s a:8057 r:0 hw:39
[2019-06-10 19:40:27] GPU 2 [57C, fan 86%] cnr: 2.471kh/s, avg 2.471kh/s, pool 2.337kh/s a:7768 r:0 hw:106
[2019-06-10 19:40:27] GPU 3 [63C, fan 87%] cnr: 2.464kh/s, avg 2.464kh/s, pool 2.381kh/s a:7917 r:0 hw:73
[2019-06-10 19:40:27] GPU 4 [55C, fan 88%] cnr: 2.470kh/s, avg 2.468kh/s, pool 2.259kh/s a:7519 r:0 hw:321
[2019-06-10 19:40:27] Total cnr: 12.35kh/s, avg 12.35kh/s, pool 11.74kh/s a:39041 r:0 hw:556
[2019-06-10 19:40:39] Pool pool.supportxmr.com received new job. (job_id: +kOSIEF95a5dlkxX6slHR0EW+l34)
I know, I'm pushing hard on limit, but what changed in TR miner 0.4.5 that causes this instability? With 0.4.4 and older was this rig rock stable. OS is Linux & amd18.3 drivers.
Thank you for answer,
Migo
Hi! Man, it's such a hard question to answer. The changes between 0.4.4 and 0.4.5 are really tiny, and nothing that "should" affect anything in terms of stability. For cn/r, absolutely nothing of interest was touched in the kernels, and not anything specific in the host-side code either. For every release, we get a few people telling us how stable things are with the new version, then a others that (like you) unfortunately have a harder time keeping things running smoothly. Since you're running linux, do you see anything interesting in your "dmesg" output from the kernel when a crash occurs? -- K Hi, thank you for your answer! I'm sorry I've not looked into dmesg. I'll stop 0.4.4 and run 0.5.1 again to look at dmesg. Can I provide some more info after crash? 0.4.4 run nicely from last 0.5.1 experiment yesterday: [2019-06-11 18:16:28] Stats Uptime: 0 days, 20:38:06 [2019-06-11 18:16:28] GPU 0 [59C, fan 87%] cnr: 2.470kh/s, avg 2.470kh/s, pool 2.443kh/s a:512 r:0 hw:2 [2019-06-11 18:16:28] GPU 1 [60C, fan 84%] cnr: 2.470kh/s, avg 2.475kh/s, pool 2.537kh/s a:532 r:0 hw:0 [2019-06-11 18:16:28] GPU 2 [56C, fan 85%] cnr: 2.468kh/s, avg 2.471kh/s, pool 2.303kh/s a:482 r:0 hw:8 [2019-06-11 18:16:28] GPU 3 [63C, fan 87%] cnr: 2.461kh/s, avg 2.464kh/s, pool 2.401kh/s a:503 r:0 hw:7 [2019-06-11 18:16:28] GPU 4 [55C, fan 88%] cnr: 2.464kh/s, avg 2.468kh/s, pool 2.314kh/s a:485 r:0 hw:26 [2019-06-11 18:16:28] Total cnr: 12.33kh/s, avg 12.35kh/s, pool 12.00kh/s a:2514 r:0 hw:43 [2019-06-11 18:16:30] Pool pool.supportxmr.com received new job. (job_id: BI3HJirVchNMe6LpNGRZuX5bez1a) Now I'm on 0.5.1 for debuging: Team Red Miner version 0.5.1 [2019-06-11 18:18:19] Auto-detected AMD OpenCL platform 0 [2019-06-11 18:18:20] Initializing GPU 0. [2019-06-11 18:18:21] Initializing GPU 1. [2019-06-11 18:18:22] Initializing GPU 2. [2019-06-11 18:18:23] Initializing GPU 3. [2019-06-11 18:18:24] Initializing GPU 4. [2019-06-11 18:18:25] Watchdog thread starting. [2019-06-11 18:18:25] Runtime Command Keys: h - help, s - stats, e - enable gpu, d - disable gpu, t - tuning mode, q - quit [2019-06-11 18:18:25] API initialized on 127.0.0.1:4028 [2019-06-11 18:18:25] Successfully initialized GPU 0: Vega with 64 CU (PCIe 03:00.0) (CN 16*14:CAA) [2019-06-11 18:18:25] Successfully initialized GPU 1: Vega with 64 CU (PCIe 08:00.0) (CN 16*14:CAA) [2019-06-11 18:18:25] Successfully initialized GPU 2: Vega with 64 CU (PCIe 0b:00.0) (CN 16*14:CAA) [2019-06-11 18:18:25] Successfully initialized GPU 3: Vega with 64 CU (PCIe 0e:00.0) (CN 16*14:CAA) [2019-06-11 18:18:25] Successfully initialized GPU 4: Vega with 64 CU (PCIe 11:00.0) (CN 16*14:CAA) Thank you, Migo |
|
|
|
|
2 kerney666
Hi, my rig can't run longer then 1-2 hours on v 0.4.5 and newer. One GPU hangs (this is from 0.5.1 after autoconfig):
[2019-06-10 21:22:55] GPU 0 [57C, fan 87%] cnr: 2.486kh/s, avg 2.477kh/s, pool 2.709kh/s a:46 r:0 hw:0
[2019-06-10 21:22:55] GPU 1 [58C, fan 85%] cnr: 2.490kh/s, avg 2.482kh/s, pool 1.261kh/s a:22 r:0 hw:0
[2019-06-10 21:22:55] GPU 2 [56C, fan 86%] cnr: 2.486kh/s, avg 2.478kh/s, pool 2.969kh/s a:51 r:0 hw:1
[2019-06-10 21:22:55] GPU 3 [63C, fan 87%] cnr: 2.480kh/s, avg 2.468kh/s, pool 2.377kh/s a:42 r:0 hw:0
[2019-06-10 21:22:55] GPU 4 [45C, fan 90%] cnr: 2.483kh/s, avg 2.471kh/s, pool 2.737kh/s a:47 r:0 hw:3
[2019-06-10 21:22:55] Total cnr: 12.42kh/s, avg 12.38kh/s, pool 12.05kh/s a:208 r:0 hw:4
[2019-06-10 21:23:05] GPU 4: detected DEAD (11:00.0), will execute restart script watchdog.sh
but v0.4.4 with exactly same config can run for weeks:
[2019-06-10 19:40:27] Stats Uptime: 13 days, 12:58:15
[2019-06-10 19:40:27] GPU 0 [59C, fan 87%] cnr: 2.471kh/s, avg 2.470kh/s, pool 2.340kh/s a:7780 r:0 hw:17
[2019-06-10 19:40:27] GPU 1 [60C, fan 85%] cnr: 2.474kh/s, avg 2.473kh/s, pool 2.423kh/s a:8057 r:0 hw:39
[2019-06-10 19:40:27] GPU 2 [57C, fan 86%] cnr: 2.471kh/s, avg 2.471kh/s, pool 2.337kh/s a:7768 r:0 hw:106
[2019-06-10 19:40:27] GPU 3 [63C, fan 87%] cnr: 2.464kh/s, avg 2.464kh/s, pool 2.381kh/s a:7917 r:0 hw:73
[2019-06-10 19:40:27] GPU 4 [55C, fan 88%] cnr: 2.470kh/s, avg 2.468kh/s, pool 2.259kh/s a:7519 r:0 hw:321
[2019-06-10 19:40:27] Total cnr: 12.35kh/s, avg 12.35kh/s, pool 11.74kh/s a:39041 r:0 hw:556
[2019-06-10 19:40:39] Pool pool.supportxmr.com received new job. (job_id: +kOSIEF95a5dlkxX6slHR0EW+l34)
I know, I'm pushing hard on limit, but what changed in TR miner 0.4.5 that causes this instability? With 0.4.4 and older was this rig rock stable. OS is Linux & amd18.3 drivers.
Thank you for answer,
Migo
|
|
|
|
All my shares are rejected now! Anybody else? [2019-03-09 20:38:04] Pool pool.supportxmr.com share rejected. (GPU2) Error code: -1 - Low difficulty share (a:141 r:6) (188 ms) [2019-03-09 20:38:22] Stats Uptime: 0 days, 01:04:31 [2019-03-09 20:38:22] GPU 0 [59C, fan 87%] cnr: 2.311kh/s, avg 2.315kh/s, pool 2.235kh/s a:27 r:0 hw:0 [2019-03-09 20:38:22] GPU 1 [57C, fan 86%] cnr: 2.342kh/s, avg 2.336kh/s, pool 1.774kh/s a:23 r:1 hw:0 [2019-03-09 20:38:22] GPU 2 [55C, fan 86%] cnr: 2.306kh/s, avg 2.304kh/s, pool 1.845kh/s a:24 r:2 hw:0 [2019-03-09 20:38:22] GPU 3 [63C, fan 87%] cnr: 2.279kh/s, avg 2.279kh/s, pool 2.649kh/s a:32 r:1 hw:0 [2019-03-09 20:38:22] GPU 4 [54C, fan 88%] cnr: 2.274kh/s, avg 2.279kh/s, pool 2.888kh/s a:35 r:2 hw:1 [2019-03-09 20:38:22] Total cnr: 11.51kh/s, avg 11.51kh/s, pool 11.39kh/s a:141 r:6 hw:1 [2019-03-09 20:38:26] Pool pool.supportxmr.com received new job. (job_id: PnLU2XWpyX31dj7IhXHtUQHsgi5h) [2019-03-09 20:38:26] Pool pool.supportxmr.com share rejected. (GPU3) Error code: -1 - Low difficulty share (a:141 r:7) (89 ms) [2019-03-09 20:38:52] Pool pool.supportxmr.com received new job. (job_id: PRfxENISbIlmg3C0riLiIqM1Gf3/) [2019-03-09 20:38:52] Pool pool.supportxmr.com share rejected. (GPU1) Error code: -1 - Low difficulty share (a:141 r:  (114 ms) [2019-03-09 20:38:52] Stats Uptime: 0 days, 01:05:01 [2019-03-09 20:38:52] GPU 0 [58C, fan 88%] cnr: 2.315kh/s, avg 2.315kh/s, pool 2.218kh/s a:27 r:0 hw:0 [2019-03-09 20:38:52] GPU 1 [57C, fan 85%] cnr: 2.335kh/s, avg 2.336kh/s, pool 1.760kh/s a:23 r:2 hw:0 [2019-03-09 20:38:52] GPU 2 [57C, fan 86%] cnr: 2.306kh/s, avg 2.304kh/s, pool 1.831kh/s a:24 r:2 hw:0 [2019-03-09 20:38:52] GPU 3 [62C, fan 87%] cnr: 2.279kh/s, avg 2.279kh/s, pool 2.629kh/s a:32 r:2 hw:0 [2019-03-09 20:38:52] GPU 4 [54C, fan 88%] cnr: 2.281kh/s, avg 2.279kh/s, pool 2.866kh/s a:35 r:2 hw:1 [2019-03-09 20:38:52] Total cnr: 11.52kh/s, avg 11.51kh/s, pool 11.30kh/s a:141 r:8 hw:1 [2019-03-09 20:39:03] Pool pool.supportxmr.com received new job. (job_id: 9c5hNr/H/mBkFQ6w5pbU+nSUk5Jv) [2019-03-09 20:39:03] Pool pool.supportxmr.com share rejected. (GPU4) Error code: -1 - Low difficulty share (a:141 r:9) (93 ms) [2019-03-09 20:39:12] Pool pool.supportxmr.com share rejected. (GPU0) Error code: -1 - IP Address currently banned for using an invalid mining protocol, please check your miner (a:141 r:10) (17 ms) EDIT: was pool side problem, it is OK now. THX! |
|
|
|
Is it a quite weak machine? I had that problem a while ago with Monero and some older machines. The pool rised the difficulty higher and higher till the machine had no chance to return a hash in the given time. As a solution, I added the smallest allowed difficulty after the wallet address in the config file. With your pool it should be ".100000"  I'm using fixed difficulty, but I think the main problem is the linux JCE just goes to command line after IP ban instead of reconnecting. It should keep trying to reconnect to the pool. hi, add --forever --keepalive to your cmd line when starting jce miner. M/ |
|
|
|
Hello,
Sure it would be helpful to get comparison with same algo...
stak mines with 3 threads with 2M cache each, for your total of 6M cache, which sounds good.
What happens if you mine with the same configuration with JCE ?
multi_hash:1 on three CPUs: 0, 1 and 2?
I'd expect you get at least on par results, not -40%.
Your current config using only 2 cores and 8M cache (2M overflood) is expected to be bad.
Hi again, your avx code path is buggy, look at this: Analyzing Processors topology... Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz Assembly codename: generic_aes_avx SSE2 : Yes SSE3 : Yes SSE4 : Yes AES : Yes AVX : Yes AVX2 : No Found CPU 0, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 1, 2, 3 Found CPU 1, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 0, 2, 3 Found CPU 2, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 0, 1, 3 Found CPU 3, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 0, 1, 2 Preparing 3 Mining Threads... +-- Thread 0 config ------------------------+ | Run on CPU: 0 | | Use cache: yes | | Multi-hash: no | | Assembly module: generic_aes | +-------------------------------------------+ +-- Thread 1 config ------------------------+ | Run on CPU: 1 | | Use cache: yes | | Multi-hash: no | | Assembly module: generic_aes | +-------------------------------------------+ +-- Thread 2 config ------------------------+ | Run on CPU: 2 | | Use cache: yes | | Multi-hash: no | | Assembly module: generic_aes | +-------------------------------------------+ Cryptonight Variation: Cryptonight-Stellite/Masari V8 Starting CPU Thread 0, affinity: CPU 0 Thread 0 successfully bound to CPU 0 Allocated shared Large Page at: 0x7fa0aea00000 Allocated 2MB Cached Large Page Scratchpad Buffer at: 0x7fa0ae800000 Starting CPU Thread 1, affinity: CPU 1 Thread 1 successfully bound to CPU 1 Allocated 2MB Cached Large Page Scratchpad Buffer at: 0x7fa0adc00000 Starting CPU Thread 2, affinity: CPU 2 Thread 2 successfully bound to CPU 2 Allocated 2MB Cached Large Page Scratchpad Buffer at: 0x7fa0ad000000 Devfee for CPU is 1.5% 15:23:25 | Masari (MSR) Mining session starts! During mining time, press: h display hashrate for each mining thread. r display full report. p pause all. q quit. 15:23:26 | Connecting with SSL to mining pool pool.masari.hashvault.pro:443 ... 15:23:26 | Connected to pool. Now logging in... 15:23:26 | Successfuly logged as xxx 15:23:26 | Pool changes Difficulty to 9000. 15:23:56 | Hashrate CPU Thread 0: 70.08 h/s 15:23:56 | Hashrate CPU Thread 1: 57.92 h/s 15:23:56 | Hashrate CPU Thread 2: 72.19 h/s 15:23:56 | Total: 200.19 h/s - Max: 200.19 h/s 15:23:59 | Pool sends a new Job. 15:24:00 | CPU Thread 1 finds a Share, value 9000 15:24:00 | Accepted by the pool in 82 ms. 15:24:31 | CPU Thread 1 finds a Share, value 9000 15:24:31 | Accepted by the pool in 50 ms. 15:24:33 | Pool sends a new Job. 15:25:00 | Pool changes Difficulty to 5790. 15:25:24 | CPU Thread 1 finds a Share, value 5790 15:25:24 | Accepted by the pool in 50 ms. 15:25:24 | CPU Thread 0 finds a Share, value 5790 15:25:24 | Accepted by the pool in 47 ms. 15:25:25 | Hashrate CPU Thread 0: 72.83 h/s 15:25:25 | Hashrate CPU Thread 1: 51.36 h/s 15:25:25 | Hashrate CPU Thread 2: 71.62 h/s 15:25:25 | Total: 195.80 h/s - Max: 200.19 h/s Can you look at it please? Thank you! Milan |
|
|
|
Hello,
Sure it would be helpful to get comparison with same algo...
stak mines with 3 threads with 2M cache each, for your total of 6M cache, which sounds good.
What happens if you mine with the same configuration with JCE ?
multi_hash:1 on three CPUs: 0, 1 and 2?
I'd expect you get at least on par results, not -40%.
Your current config using only 2 cores and 8M cache (2M overflood) is expected to be bad.
Hi JCE, here are results with the same (suggested) config as xmr-stak on CNv8: Analyzing Processors topology... Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz Assembly codename: generic_aes_avx SSE2 : Yes SSE3 : Yes SSE4 : Yes AES : Yes AVX : Yes AVX2 : No Found CPU 0, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 1, 2, 3 Found CPU 1, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 0, 2, 3 Found CPU 2, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 0, 1, 3 Found CPU 3, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 0, 1, 2 Preparing 3 Mining Threads... +-- Thread 0 config ------------------------+ | Run on CPU: 0 | | Use cache: yes | | Multi-hash: no | | Assembly module: generic_aes_avx | +-------------------------------------------+ +-- Thread 1 config ------------------------+ | Run on CPU: 1 | | Use cache: yes | | Multi-hash: no | | Assembly module: generic_aes_avx | +-------------------------------------------+ +-- Thread 2 config ------------------------+ | Run on CPU: 2 | | Use cache: yes | | Multi-hash: no | | Assembly module: generic_aes_avx | +-------------------------------------------+ Cryptonight Variation: Cryptonight-Stellite/Masari V8 Starting CPU Thread 0, affinity: CPU 0 Thread 0 successfully bound to CPU 0 Allocated shared Large Page at: 0x7f26b0c00000 Allocated 2MB Cached Large Page Scratchpad Buffer at: 0x7f26b0a00000 Starting CPU Thread 1, affinity: CPU 1 Thread 1 successfully bound to CPU 1 Allocated 2MB Cached Large Page Scratchpad Buffer at: 0x7f26a3e00000 Starting CPU Thread 2, affinity: CPU 2 Thread 2 successfully bound to CPU 2 Allocated 2MB Cached Large Page Scratchpad Buffer at: 0x7f26a3200000 Devfee for CPU is 1.5% 14:33:26 | Masari (MSR) Mining session starts! During mining time, press: h display hashrate for each mining thread. r display full report. p pause all. q quit. 14:33:26 | Connecting with SSL to mining pool pool.masari.hashvault.pro:443 ... 14:33:27 | Connected to pool. Now logging in... 14:33:27 | Successfuly logged as xxx 14:33:27 | Pool changes Difficulty to 9000. 14:33:57 | Hashrate CPU Thread 0: 17.27 h/s 14:33:57 | Hashrate CPU Thread 1: 14.99 h/s 14:33:57 | Hashrate CPU Thread 2: 16.76 h/s 14:33:57 | Total: 49.01 h/s - Max: 49.01 h/s .... 14:52:15 | Pool pool.masari.hashvault.pro:443 (SSL) 14:52:15 | Reconnections 0 14:52:15 | Currency Masari (MSR) 14:52:15 | Current pool Difficulty 5000 14:52:15 | Accepted Shares 4 14:52:15 | Total Hashes 28000 14:52:15 | Miner uptime 0:18:49 14:52:15 | Effective net hashrate 24.80 h/s ... 14:59:45 | Hashrate CPU Thread 0: 17.41 h/s 14:59:45 | Hashrate CPU Thread 1: 15.07 h/s 14:59:45 | Hashrate CPU Thread 2: 16.29 h/s 14:59:45 | Total: 48.76 h/s - Max: 49.26 h/s Something is wrong here I think... Thank you! |
|
|
|
Hello,
Sure it would be helpful to get comparison with same algo...
stak mines with 3 threads with 2M cache each, for your total of 6M cache, which sounds good.
What happens if you mine with the same configuration with JCE ?
multi_hash:1 on three CPUs: 0, 1 and 2?
I'd expect you get at least on par results, not -40%.
Your current config using only 2 cores and 8M cache (2M overflood) is expected to be bad.
Hi, with suggested config it is worse This is best what I can get. Will post details later, I've kid in care now xmr-stak can't mine CNfast_V8 now. Thank you for reply. Milan |
|
|
|
Hi JCE, I've strange performance problem on one avx machine, JCE minig MSR is 2times slower as xmrstak minig XMR. Hmmm. Any sugestions? Config line: -o pool.masari.hashvault.pro:443 -u xxx -p db -c ./config.jce --variation 21 --ssl --forever Changing threads count, multihash all tried but this is maximum what I can get out of this. Thank you. You mine 2 different algos  So you can not compare it. JCE you mine Masari and on XMR Stak you mine monero. Hi, yes I know but CNFastv8 is faster than CNv8 thus I should get +40% more HR not -40% XMR example only demonstrates real HS on CNv8 with this CPU... |
|
|
|
Hi JCE, I've strange performance problem on one avx machine, JCE minig MSR is 2times slower as xmrstak minig XMR. Hmmm. Any sugestions? Config line: -o pool.masari.hashvault.pro:443 -u xxx -p db -c ./config.jce --variation 21 --ssl --forever Changing threads count, multihash all tried but this is maximum what I can get out of this. Thank you. Analyzing Processors topology... Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz Assembly codename: generic_aes_avx SSE2 : Yes SSE3 : Yes SSE4 : Yes AES : Yes AVX : Yes AVX2 : No Found CPU 0, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 1, 2, 3 Found CPU 1, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 0, 2, 3 Found CPU 2, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 0, 1, 3 Found CPU 3, with: L1 Cache: 32 KB L2 Cache: 256 KB L3 Cache: 6144 KB, shared with CPU 0, 1, 2 Preparing 2 Mining Threads... +-- Thread 0 config ------------------------+ | Run on CPU: 0 | | Use cache: yes | | Multi-hash: x2 | | Assembly module: generic_aes_avx | +-------------------------------------------+ +-- Thread 1 config ------------------------+ | Run on CPU: 1 | | Use cache: yes | | Multi-hash: x2 | | Assembly module: generic_aes_avx | +-------------------------------------------+ Cryptonight Variation: Cryptonight-Stellite/Masari V8 Starting CPU Thread 0, affinity: CPU 0 Thread 0 successfully bound to CPU 0 Allocated shared Large Page at: 0x7f92b9800000 Allocated 4MB Cached Large Page Scratchpad Buffer at: 0x7f92b9400000 Starting CPU Thread 1, affinity: CPU 1 Thread 1 successfully bound to CPU 1 Allocated 4MB Cached Large Page Scratchpad Buffer at: 0x7f92b8600000 Devfee for CPU is 1.5% 08:57:13 | Masari (MSR) Mining session starts! During mining time, press: h display hashrate for each mining thread. r display full report. p pause all. q quit. 08:57:14 | Connecting with SSL to mining pool pool.masari.hashvault.pro:443 ... 08:57:14 | Connected to pool. Now logging in... 08:57:14 | Successfuly logged as xxx 08:57:14 | Pool changes Difficulty to 9000. 08:57:26 | Pool sends a new Job. 08:57:27 | Hashrate CPU Thread 0: 36.12 h/s 08:57:27 | Hashrate CPU Thread 1: 33.31 h/s 08:57:27 | Total: 69.42 h/s - Max: 69.42 h/s 08:57:50 | Hashrate CPU Thread 0: 35.90 h/s 08:57:50 | Hashrate CPU Thread 1: 33.14 h/s 08:57:50 | Total: 69.04 h/s - Max: 69.42 h/s 08:57:57 | Pool sends a new Job. 08:58:11 | Hashrate CPU Thread 0: 35.90 h/s 08:58:11 | Hashrate CPU Thread 1: 33.06 h/s 08:58:11 | Total: 68.95 h/s - Max: 69.42 h/s 08:58:14 | Stop signal received, Quitting... 08:58:14 | Large Page Scratchpad 4MB Buffer 0x7f92b8600000 released. 08:58:14 | Large Page Scratchpad 4MB Buffer 0x7f92b9400000 released. 08:58:14 | Pool connection socket closed. 08:58:14 | Mining thread 0 stopped. 08:58:14 | Mining thread 1 stopped. 08:58:14 | Shared Large Page 0x7f92b9800000 released. and xmrstak: [2019-02-07 08:59:02] : Mining coin: monero [2019-02-07 08:59:02] : Starting 1x thread, affinity: 0. [2019-02-07 08:59:02] : hwloc: memory pinned [2019-02-07 08:59:02] : Starting 1x thread, affinity: 1. [2019-02-07 08:59:02] : hwloc: memory pinned [2019-02-07 08:59:02] : Starting 1x thread, affinity: 2. [2019-02-07 08:59:02] : hwloc: memory pinned [2019-02-07 08:59:02] : Fast-connecting to pool.supportxmr.com:5555 pool ... [2019-02-07 08:59:02] : Pool pool.supportxmr.com:5555 connected. Logging in... [2019-02-07 08:59:02] : Difficulty changed. Now: 10000. [2019-02-07 08:59:02] : Pool logged in. [2019-02-07 08:59:02] : Switch to assembler version for 'intel_avx' cpu's [2019-02-07 08:59:02] : Switch to assembler version for 'intel_avx' cpu's [2019-02-07 08:59:02] : Switch to assembler version for 'intel_avx' cpu's HASHRATE REPORT - CPU | ID | 10s | 60s | 15m | ID | 10s | 60s | 15m | | 0 | 39.1 | (na) | (na) | 1 | 27.2 | (na) | (na) | | 2 | 39.9 | (na) | (na) | Totals (CPU): 106.3 0.0 0.0 H/s ----------------------------------------------------------------- Totals (ALL): 106.3 0.0 0.0 H/s Highest: 0.0 H/s ----------------------------------------------------------------- HASHRATE REPORT - CPU | ID | 10s | 60s | 15m | ID | 10s | 60s | 15m | | 0 | 42.6 | (na) | (na) | 1 | 26.1 | (na) | (na) | | 2 | 40.2 | (na) | (na) | Totals (CPU): 109.0 0.0 0.0 H/s ----------------------------------------------------------------- Totals (ALL): 109.0 0.0 0.0 H/s Highest: 107.5 H/s ----------------------------------------------------------------- [2019-02-07 08:59:46] : Difficulty changed. Now: 8108. [2019-02-07 08:59:46] : New block detected. HASHRATE REPORT - CPU | ID | 10s | 60s | 15m | ID | 10s | 60s | 15m | | 0 | 38.5 | 40.6 | (na) | 1 | 28.6 | 27.3 | (na) | | 2 | 39.0 | 39.1 | (na) | Totals (CPU): 106.2 107.1 0.0 H/s ----------------------------------------------------------------- Totals (ALL): 106.2 107.1 0.0 H/s Highest: 109.2 H/s ----------------------------------------------------------------- [2019-02-07 09:00:46] : Difficulty changed. Now: 5405. [2019-02-07 09:00:46] : New block detected. [2019-02-07 09:00:51] : Result accepted by the pool. [2019-02-07 09:01:39] : New block detected. [2019-02-07 09:01:46] : Difficulty changed. Now: 5000. [2019-02-07 09:01:46] : New block detected. [2019-02-07 09:02:46] : New block detected. [2019-02-07 09:03:00] : New block detected. HASHRATE REPORT - CPU | ID | 10s | 60s | 15m | ID | 10s | 60s | 15m | | 0 | 45.6 | 42.6 | (na) | 1 | 25.4 | 26.0 | (na) | | 2 | 36.7 | 36.9 | (na) | Totals (CPU): 107.9 105.6 0.0 H/s ----------------------------------------------------------------- Totals (ALL): 107.9 105.6 0.0 H/s Highest: 109.2 H/s ----------------------------------------------------------------- [2019-02-07 09:03:46] : New block detected. |
|
|
|
linux version 0.33q to be uploaded in about an hour, i'm finishing the package.
i expect you reach 800+ on new masari as an order of magnitude on a HD7950/270. i depends on the card, and of course you should flash the bios to use better memory timings, if not already done.
edit: it's online
Hi! Thank you very much! Great work as always! Milan |
|
|
|
Yes, use the private messages feature of that forum please, i don't use social medias like Discord (too time consuming). Also, i dev alone, no pural developer s  @Unclwish: i mined the same way as you (Nicehash Heavy on GPU 0, one thread) and it worked for me. Sad i couldn't reproduce the bug. What happens when you add parameter --legacy ? I'm building the 0.33b18 GPU, with the same changes as CPU: * Fix Masari v8 bad shares
* CN-Waltz fork
* Turtle defaults to v2
edit: it's online now Hi JCE, updated/fixed Linux CPU version? I've increased you linux mining fee income a bit now:) Trying to mine MSR now What is your MSR HR on old 270x and 280x cards? I've some 270x and 280x on linux runnig ETP, wondering if it make sense to switch to win10 and JCE? Thanx, Milan |
|
|
|
@migo77 : so you also have a Dual Opteron?  Are you an old hardware collector? Those servers are getting rarer. I don't plan to buy one now, the old cpu mining is evaporating because of the low coin prices, i entered quite late into the miner dev game Even your Opteron perf are quite disapointing, that's like +8% here, but the +30% was for v7, i didn't rebench meanwhile. Hi JCE, yes I've only one dual opteron, all other CPU miners are old xeons. I've some 270x,280x,290x and vega64 too, but all on Linux so no chance for JCE. Yes, V8 fork degraded performance for all my old servers by 30% and more sometimes using XMR-stak. ( Som of looses can be recovered with JCEminer but not all. Most problematic is Xeon E5520 and I've several of them Yes, collector of old good HW mostly SUN servers |
|
|
|
I got reports that on Opteron (old non-aes AMD) i also give +30% perf, so maybe the Nehalem is a special case of non-AES cpu which runs bad on my code Yes I can confirm this too, with xmr-stak I get 160H/s and with JCE: { "hashrate": { "thread_0": 14.55, "thread_1": 14.55, "thread_2": 14.56, "thread_3": 14.55, "thread_4": 14.55, "thread_5": 14.56, "thread_6": 14.64, "thread_7": 14.64, "thread_8": 14.64, "thread_9": 14.64, "thread_10": 14.64, "thread_11": 14.64, "thread_all": [14.55, 14.55, 14.56, 14.55, 14.55, 14.56, 14.64, 14.64, 14.64, 14.64, 14.64, 14.64], "total": 175.11, "max": 176.21 }, "result": { "wallet": "xxx", "pool": "xxx", "ssl": false, "reconnections": 0, "currency": "Monero (XMR/XMV)", "difficulty": 5160, "shares": 2673, "hashes": 13941780, "uptime": "22:27:24", "effective": 172.45 }, "miner": { "version": "jce/0.33k/cpu", "platform": "Dual Six-Core AMD Opteron(tm) Processor 2435", "system": "Linux 64-bits", "algorithm": "15" } } |
|
|
|
@migo: Looks like my miner uses 8 threads and stak uses 16, and stak is probably right to do such. Can you copy-paste the beginning of my log, where it detects the CPUs ? Otherwise, try this manual config, which is very like the one of stak: "cpu_threads_conf" :
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 4, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 5, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 6, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 7, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 8, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 9, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 10, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 11, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 12, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 13, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 14, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 15, "use_cache" : true },
] Hi JCE, as I said, this config is good for xmr-stak not for jce: { "hashrate": { "thread_0": 9.05, "thread_1": 8.68, "thread_2": 8.66, "thread_3": 8.68, "thread_4": 8.80, "thread_5": 8.81, "thread_6": 8.80, "thread_7": 8.80, "thread_8": 9.08, "thread_9": 8.69, "thread_10": 8.66, "thread_11": 8.67, "thread_12": 8.80, "thread_13": 8.80, "thread_14": 8.81, "thread_15": 8.80, "thread_all": [9.05, 8.68, 8.66, 8.68, 8.80, 8.81, 8.80, 8.80, 9.08, 8.69, 8.66, 8.67, 8.80, 8.80, 8.81, 8.80], "total": 140.51, "max": 140.58 }, "result": { "wallet": "xxx", "pool": "xxx", "ssl": false, "reconnections": 0, "currency": "Monero (XMR/XMV)", "difficulty": 6240, "shares": 4, "hashes": 36240, "uptime": "0:06:16", "effective": 96.38 }, "miner": { "version": "jce/0.33k/cpu", "platform": "Dual Intel(R) Xeon(R) CPU E5520 @ 2.27GHz", "system": "Linux 64-bits", "algorithm": "15" } } This is with Nehalem architecture optimizations, but when I manually set generic_sse4 architecture I get +1 H/s what is interesting: { "hashrate": { "thread_0": 19.16, "thread_1": 19.16, "thread_2": 19.16, "thread_3": 19.16, "thread_4": 19.21, "thread_5": 19.21, "thread_6": 19.21, "thread_7": 19.21, "thread_all": [19.16, 19.16, 19.16, 19.16, 19.21, 19.21, 19.21, 19.21], "total": 153.46, "max": 153.46 }, "result": { "wallet": "xxx", "pool": "xxx", "ssl": false, "reconnections": 0, "currency": "Monero (XMR/XMV)", "difficulty": 6660, "shares": 2, "hashes": 19990, "uptime": "0:01:50", "effective": 181.73 }, "miner": { "version": "jce/0.33k/cpu", "platform": "Dual Intel(R) Xeon(R) CPU E5520 @ 2.27GHz", "system": "Linux 64-bits", "algorithm": "15" } } I think there is something wrong in your optimizations for this architecture... I can sell you one Sun 1U server for 3XMR + shipping for development if interested. |
|
|
|
@migo: Looks like my miner uses 8 threads and stak uses 16, and stak is probably right to do such. Can you copy-paste the beginning of my log, where it detects the CPUs ? Otherwise, try this manual config, which is very like the one of stak: "cpu_threads_conf" :
[
{ "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 4, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 5, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 6, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 7, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 8, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 9, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 10, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 11, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 12, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 13, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 14, "use_cache" : true },
{ "cpu_architecture" : "auto", "affine_to_cpu" : 15, "use_cache" : true },
] Hi, It is my manual config for xmr-stak which gives me max hr. For your miner it is not best one, I'll post results later. I've done hours of config fine tuning to get max hr already. I must take care of my son now, sorry. |
|
|
|
Surprising. Just benched, between last JCE and last xmrstak, official release, not recompiled myself. Using autoconfig to mine Monero v8 in both cases, 4 threads on my Core2Quad Xeon oc@ 2.666G [2018-12-25 20:23:41] : Your CPU doesn't support hardware AES. Don't expect high hashrates.
[2018-12-25 20:23:41] : Mining coin: cryptonight_v8
[2018-12-25 20:23:41] : Starting 2x thread, affinity: 0.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:23:41] : Starting 1x thread, affinity: 1.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:23:41] : Starting 2x thread, affinity: 2.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:23:41] : Starting 1x thread, affinity: 3.
[2018-12-25 20:23:41] : hwloc: memory pinned
[2018-12-25 20:25:15] : New block detected.
HASHRATE REPORT - CPU
| ID | 10s | 60s | 15m | ID | 10s | 60s | 15m |
| 0 | 12.5 | 11.5 | (na) | 1 | 14.2 | 13.5 | (na) |
| 2 | 13.6 | 13.0 | (na) | 3 | 14.8 | 14.4 | (na) |
Totals (CPU): 55.2 52.4 0.0 H/s
For Windows 64-bits
Analyzing Processors topology...
Intel(R) Xeon(R) CPU L5408 @ 2.13GHz
Assembly codename: core2_sse4
Preparing 4 Mining Threads...
20:26:36 | Hashrate CPU Thread 0: 22.92 h/s
20:26:36 | Hashrate CPU Thread 1: 23.79 h/s
20:26:36 | Hashrate CPU Thread 2: 24.33 h/s
20:26:36 | Hashrate CPU Thread 3: 24.52 h/s
20:26:36 | Total: 95.55 h/s - Max: 96.24 h/s
So that's even more than +30%. What CPU and algo did you test on? Hi JCE, here is my comparsion: { "hashrate": { "thread_0": 19.08, "thread_1": 19.08, "thread_2": 19.07, "thread_3": 19.08, "thread_4": 19.12, "thread_5": 19.11, "thread_6": 19.12, "thread_7": 19.12, "thread_all": [19.08, 19.08, 19.07, 19.08, 19.12, 19.11, 19.12, 19.12], "total": 152.72, "max": 152.74 }, "result": { "wallet": "xxx", "pool": "xxx", "ssl": false, "reconnections": 0, "currency": "Monero (XMR/XMV)", "difficulty": 5000, "shares": 1554, "hashes": 7797738, "uptime": "14:38:16", "effective": 147.98 }, "miner": { "version": "jce/0.33k/cpu", "platform": "Dual Intel(R) Xeon(R) CPU E5520 @ 2.27GHz", "system": "Linux 64-bits", "algorithm": "15" } } and XMR-Stak Monero Miner Hashrate Results Connection Hashrate Report Thread ID 10s 60s 15m H/s 0 9.4 9.4 9.4 1 9.4 9.4 9.4 2 9.4 9.4 9.4 3 9.4 9.4 9.4 4 9.3 9.3 9.4 5 9.3 9.3 9.4 6 15.3 15.3 15.3 7 9.4 9.4 9.4 8 9.4 9.4 9.4 9 9.4 9.4 9.4 10 9.4 9.4 9.4 11 9.3 9.4 9.4 12 9.3 9.4 9.4 13 4.3 4.4 4.4 14 9.4 9.4 9.4 15 4.3 4.4 4.4 Totals: 146.9 147.0 147.2 Highest: 148.9 Your miner is marginally faster, but no 30% in this case I'm not complaining but want to find problem. |
|
|
|
Sure, online is the 0.33k CPU LinuxMasari: yeah, yet another fork And again with no reference dedicated miner and no test pool. Otherwise it looks like just Masari with the v2 additions, so if that's it, it will be easy to add. I've still found no pool for test on Stellite v8 or Turtle v2.  Hi JCE, seems that k version restored speed of g version. But I can't still see +30% improvement over xmr-stak on my old non-AES hardware |
|
|
|
|
