Hello,
I'm getting the following since version 3.9.1.1 on a Xeon D-2141I CPU while compiling with gcc 6.3.0 under a debian system
In file included from algo-gate-api.h:5:0,
from util.c:48:
avxdefs.h: In function ‘avx512_compile_test’:
In file included from algo-gate-api.h:5:0,
from cpu-miner.c:64:
avxdefs.h: In function ‘avx512_compile_test’:
avxdefs.h:2035:7: warning: implicit declaration of function ‘mm256_rorv_16’ [-Wimplicit-function-declaration]
y = mm256_rorv_16( y, 3 );
^~~~~~~~~~~~~
avxdefs.h:2035:7: warning: implicit declaration of function ‘mm256_rorv_16’ [-Wimplicit-function-declaration]
y = mm256_rorv_16( y, 3 );
^~~~~~~~~~~~~
avxdefs.h:2035:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
y = mm256_rorv_16( y, 3 );
^
avxdefs.h:2036:7: warning: implicit declaration of function ‘mm256_ror_1x16’ [-Wimplicit-function-declaration]
y = mm256_ror_1x16( y );
^~~~~~~~~~~~~~
avxdefs.h:2035:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
y = mm256_rorv_16( y, 3 );
^
avxdefs.h:2036:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
y = mm256_ror_1x16( y );
^
avxdefs.h:2036:7: warning: implicit declaration of function ‘mm256_ror_1x16’ [-Wimplicit-function-declaration]
y = mm256_ror_1x16( y );
^~~~~~~~~~~~~~
avxdefs.h:2036:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
y = mm256_ror_1x16( y );
^
and later on
In file included from algo-gate-api.h:5:0,
from algo-gate-api.c:20:
avxdefs.h: In function ‘avx512_compile_test’:
avxdefs.h:2035:7: warning: implicit declaration of function ‘mm256_rorv_16’ [-Wimplicit-function-declaration]
y = mm256_rorv_16( y, 3 );
^~~~~~~~~~~~~
avxdefs.h:2035:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
y = mm256_rorv_16( y, 3 );
^
avxdefs.h:2036:7: warning: implicit declaration of function ‘mm256_ror_1x16’ [-Wimplicit-function-declaration]
y = mm256_ror_1x16( y );
^~~~~~~~~~~~~~
avxdefs.h:2036:5: error: incompatible types when assigning to type ‘__m256i {aka __vector(4) long long int}’ from type ‘int’
y = mm256_ror_1x16( y );
^
Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 6. (Read 444067 times)
June 05, 2019, 08:25:18 AM
June 04, 2019, 09:50:06 PM
cpuminer-opt-3.9.2.2
Fixed some day 1 cpu-affinity issues.
https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2.2
Fixed some day 1 cpu-affinity issues.
https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2.2
I may have introduced a regression to cpu-affinity affecting Linux. Linux can support
up to 128 CPUs by using a 128 bit mask. Support for 128 bit integers is very limited
with no way to enter a 128 bit number on the command line.
As a result I replicated the 64 bit mask entered on the command line to the upper half of
the 128 bit mask resulting in a symetrical 128 bit mask.
The problem is I did this even when there are fewer than 64 CPUs available resulting in an
invalid mask. It will be ignored because it has bits set that don't have a matching CPU.
I will make a change in the next release to only replicate the lower 64 bits of the mask
if there are more than 64 CPUs.
June 04, 2019, 04:22:25 PM
cpuminer-opt-3.9.2.2
Fixed some day 1 cpu-affinity issues.
https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2.2
Fixed some day 1 cpu-affinity issues.
https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2.2
June 04, 2019, 11:58:33 AM
I was wondering about that when I saw it but hadn't followed up (too much multitasking).
I think I found the problem, it's day 1. The argument to SetThreadAffinityMask is supposed to be DWORD_PTR,
not a DWORD, so "&affinity_mask" instead of "affinity_mask". It supports 64 CPU by casting the pointer as DWORD64_ptr.
It's all clear now. Thanks for your persistence.
Thank YOU for all your hard work.
My plan for the opt_affinity option when it is int128 is to replicate the command line 64 bit mask to the
upper 64 bits of opt-affinity. The debug output will use a union overlay to display int128 as 2 int64.
This might allow specifying affinity with more than 64 cpus on linux.
EDIT:
It's looking good. I'm able to do some basic arithmetic with __int128, in particular I can shift 64 bits
so I can easilly extract both halves for 64 bit formatting. Didn't have to use a union. My testing
capabilities are limited without a >64 core cpu bt I was able to see a correctly formed 128 bit
affinity mask.
I won't try handling the 128 bit affinity yet for big cpus on linux, I want this change to soak first.
June 04, 2019, 09:49:18 AM
I was wondering about that when I saw it but hadn't followed up (too much multitasking).
I think I found the problem, it's day 1. The argument to SetThreadAffinityMask is supposed to be DWORD_PTR,
not a DWORD, so "&affinity_mask" instead of "affinity_mask". It supports 64 CPU by casting the pointer as DWORD64_ptr.
It's all clear now. Thanks for your persistence.
Thank YOU for all your hard work.
June 04, 2019, 09:39:20 AM
I tried using --cpu-affinity=0x3 in another computer (laptop) without setting affinity externally. Results are similarly problematic:
This "Binding process to cpu mask a5fce0" seems to occur in every machine, no matter how many CPUs it's got: it's always a5fce0.
Also, a quick look at the process affinity in Task Manager and I see all 4 CPUs affined, instead of just the first 2.
Code:
********** cpuminer-opt 3.9.2 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI and AVX2 and SHA extensions.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz.
SW built on Jun 3 2019 with GCC 7.3.0.
CPU features: SSE2 AES SSE4.2 AVX AVX2.
SW features: SSE2 AES SSE4.2 AVX AVX2.
Algo features: SSE2.
Start mining with SSE2.
[2019-06-04 14:17:20] 4 CPU cores available, 2 miner threads selected.
[2019-06-04 14:17:20] Binding process to cpu mask a5fce0
****** [2019-06-04 14:17:20] affine_to_cpu_mask for 4294967295 returned 57 ********
[2019-06-04 14:17:20] 2 miner threads started, using 'yespower' algorithm.
[2019-06-04 14:17:20] Starting Stratum on stratum+tcp://******
[2019-06-04 14:17:20] Binding thread 0 to cpu mask 32cfbe0
[2019-06-04 14:17:20] Binding thread 1 to cpu mask 34cfbe0
[2019-06-04 14:17:20] Stratum session id: 725103584be7a27346f921881f5ac7d8
[2019-06-04 14:17:20] Stratum difficulty set to 1
This "Binding process to cpu mask a5fce0" seems to occur in every machine, no matter how many CPUs it's got: it's always a5fce0.
Also, a quick look at the process affinity in Task Manager and I see all 4 CPUs affined, instead of just the first 2.
I was wondering about that when I saw it but hadn't followed up (too much multitasking).
I think I found the problem, it's day 1. The argument to SetThreadAffinityMask is supposed to be DWORD_PTR,
not a DWORD, so "&affinity_mask" instead of "affinity_mask". It supports 64 CPU by casting the pointer as DWORD64_ptr.
It's all clear now. Thanks for your persistence.
June 04, 2019, 08:21:49 AM
I tried using --cpu-affinity=0x3 in another computer (laptop) without setting affinity externally. Results are similarly problematic:
This "Binding process to cpu mask a5fce0" seems to occur in every machine, no matter how many CPUs it's got: it's always a5fce0.
Also, a quick look at the process affinity in Task Manager and I see all 4 CPUs affined, instead of just the first 2.
Code:
********** cpuminer-opt 3.9.2 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI and AVX2 and SHA extensions.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz.
SW built on Jun 3 2019 with GCC 7.3.0.
CPU features: SSE2 AES SSE4.2 AVX AVX2.
SW features: SSE2 AES SSE4.2 AVX AVX2.
Algo features: SSE2.
Start mining with SSE2.
[2019-06-04 14:17:20] 4 CPU cores available, 2 miner threads selected.
[2019-06-04 14:17:20] Binding process to cpu mask a5fce0
****** [2019-06-04 14:17:20] affine_to_cpu_mask for 4294967295 returned 57 ********
[2019-06-04 14:17:20] 2 miner threads started, using 'yespower' algorithm.
[2019-06-04 14:17:20] Starting Stratum on stratum+tcp://******
[2019-06-04 14:17:20] Binding thread 0 to cpu mask 32cfbe0
[2019-06-04 14:17:20] Binding thread 1 to cpu mask 34cfbe0
[2019-06-04 14:17:20] Stratum session id: 725103584be7a27346f921881f5ac7d8
[2019-06-04 14:17:20] Stratum difficulty set to 1
This "Binding process to cpu mask a5fce0" seems to occur in every machine, no matter how many CPUs it's got: it's always a5fce0.
Also, a quick look at the process affinity in Task Manager and I see all 4 CPUs affined, instead of just the first 2.
June 04, 2019, 04:15:49 AM
Does this help?
Those CPU masks become quite weird with --cpu-affinity. And in the end, it's actually bound to CPUs 0-31.
Those CPU masks become quite weird with --cpu-affinity. And in the end, it's actually bound to CPUs 0-31.
Interesting, the errors occurred even with a default affinity. I looked deeper and discovered the mask
on Windows is only 32 bits as you suspected. I don't know how it's supposed to support 64 CPUs
with only a 32 bit mask.
With groups enabled the mask is of type KAFFINITY and a member of a struct that also include group info.
KAFFINITY was described as a bit mask to set affinity of "one or more" cpus in a group but doesn't specify
a maximum or further define KAFFINITY.
Maybe you should enable CPU-groups, but cpuminer-opt needs a custom build to use it.
Hmmm, that seems to be different between Win32 and Win64: https://stackoverflow.com/questions/10877182/getprocessaffinitymask-returns-processaffinty-and-systemaffinity-as-1-overflow. The parameter seems to be 64 bit under Win64 despite their deceiving name (type DWORD64...).
Code:
typedef unsigned __int64 DWORD64, *PDWORD64;
EDIT: https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/interrupt-affinity-and-priority#about-kaffinity: "The KAFFINITY type is 32 bits on a 32-bit version of Windows and is 64 bits on a 64-bit version of Windows."
June 03, 2019, 09:14:00 PM
Does this help?
Those CPU masks become quite weird with --cpu-affinity. And in the end, it's actually bound to CPUs 0-31.
Those CPU masks become quite weird with --cpu-affinity. And in the end, it's actually bound to CPUs 0-31.
Interesting, the errors occurred even with a default affinity. I looked deeper and discovered the mask
on Windows is only 32 bits as you suspected. I don't know how it's supposed to support 64 CPUs
with only a 32 bit mask.
With groups enabled the mask is of type KAFFINITY and a member of a struct that also include group info.
KAFFINITY was described as a bit mask to set affinity of "one or more" cpus in a group but doesn't specify
a maximum or further define KAFFINITY.
Maybe you should enable CPU-groups, but cpuminer-opt needs a custom build to use it.
June 03, 2019, 08:59:08 PM
cpuminer-opt-3.9.2
https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2
Added sha256q algo.
Yespower now uses openssl SHA256, but no observable hash rate increase
on Ryzen.
Ongoing rearchitecting.
Lyra2z now hashes 8-way on CPUs with AVX2.
Lyra2 (all including phi2) now runs optimized code with SSE2.
https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.2
Added sha256q algo.
Yespower now uses openssl SHA256, but no observable hash rate increase
on Ryzen.
Ongoing rearchitecting.
Lyra2z now hashes 8-way on CPUs with AVX2.
Lyra2 (all including phi2) now runs optimized code with SSE2.
June 03, 2019, 06:34:12 PM
Does this help?
Not specifying --cpu-affinity:
Specifying --cpu-affinity=0xd555555d555555:
Those CPU masks become quite weird with --cpu-affinity. And in the end, it's actually bound to CPUs 0-31.
Not specifying --cpu-affinity:
Code:
[2019-06-04 01:29:03] 56 CPU cores available, 30 miner threads selected.
[2019-06-04 01:29:03] Starting Stratum on stratum+tcp://***
[2019-06-04 01:29:03] Binding thread 0 to cpu 0 (mask 1)
[2019-06-04 01:29:03] Binding thread 14 to cpu 14 (mask 4000)
[2019-06-04 01:29:03] Binding thread 9 to cpu 9 (mask 200)
[2019-06-04 01:29:03] affine_to_cpu_mask for 9 returned 57
[2019-06-04 01:29:03] Binding thread 4 to cpu 4 (mask 10)
[2019-06-04 01:29:03] Binding thread 18 to cpu 18 (mask 40000)
[2019-06-04 01:29:03] Binding thread 7 to cpu 7 (mask 80)
[2019-06-04 01:29:03] affine_to_cpu_mask for 7 returned 57
[2019-06-04 01:29:03] 30 miner threads started, using 'yescrypt' algorithm.
[2019-06-04 01:29:03] Binding thread 22 to cpu 22 (mask 400000)
[2019-06-04 01:29:03] Binding thread 6 to cpu 6 (mask 40)
[2019-06-04 01:29:03] Binding thread 2 to cpu 2 (mask 4)
[2019-06-04 01:29:03] Binding thread 11 to cpu 11 (mask 800)
[2019-06-04 01:29:03] affine_to_cpu_mask for 11 returned 57
[2019-06-04 01:29:03] Binding thread 8 to cpu 8 (mask 100)
[...]
Specifying --cpu-affinity=0xd555555d555555:
Code:
[2019-06-04 01:30:37] 56 CPU cores available, 30 miner threads selected.
[2019-06-04 01:30:37] Starting Stratum on stratum+tcp://***
[2019-06-04 01:30:37] Binding thread 0 to cpu mask 35ffbe0
[2019-06-04 01:30:37] Binding thread 7 to cpu mask 43ffbe0
[2019-06-04 01:30:37] Binding thread 9 to cpu mask 47ffbe0
[2019-06-04 01:30:37] Binding thread 10 to cpu mask 49ffbe0
[2019-06-04 01:30:37] Binding thread 4 to cpu mask 3dffbe0
[2019-06-04 01:30:37] Binding thread 19 to cpu mask 5bffbe0
[2019-06-04 01:30:37] Binding thread 6 to cpu mask 41ffbe0
[2019-06-04 01:30:37] 30 miner threads started, using 'yescrypt' algorithm.
[2019-06-04 01:30:37] Binding thread 1 to cpu mask 37ffbe0
[2019-06-04 01:30:37] Binding thread 8 to cpu mask 45ffbe0
[2019-06-04 01:30:37] Binding thread 2 to cpu mask 39ffbe0
[2019-06-04 01:30:37] Binding thread 11 to cpu mask 4bffbe0
[2019-06-04 01:30:37] Binding thread 12 to cpu mask 4dffbe0
[2019-06-04 01:30:37] Binding thread 13 to cpu mask 4fffbe0
[2019-06-04 01:30:37] Binding thread 3 to cpu mask 3bffbe0
[...]
Those CPU masks become quite weird with --cpu-affinity. And in the end, it's actually bound to CPUs 0-31.
June 03, 2019, 06:10:13 PM
Edit: I took another look at the code changes and there should be no difference if cpu groups
is not enabled. A change in behaviour means it's running different code. But if it was running
the new code the "Binding thread" message would have included the group. I don't know what's
going on.
You can still have cpu groups with fewer than 64 cpus.
If I had groups enabled, I would have a combo box like the one in this page. As I don't have it, I suppose I definitely don't have them enabled.
Thanks for analyzing this anyway. I'll still stick with setting affinity externally and ignore the warning.
The best advice for complex system architectures is probably to run seperate instances of the miner
for differnt CPU groups, NUMAs, whatever other scaling and partitioning features Windows has.
June 03, 2019, 05:58:40 PM
Edit: I took another look at the code changes and there should be no difference if cpu groups
is not enabled. A change in behaviour means it's running different code. But if it was running
the new code the "Binding thread" message would have included the group. I don't know what's
going on.
You can still have cpu groups with fewer than 64 cpus.
If I had groups enabled, I would have a combo box like the one in this page. As I don't have it, I suppose I definitely don't have them enabled.
Thanks for analyzing this anyway. I'll still stick to setting affinity externally and ignore the warning.
June 03, 2019, 04:11:39 PM
What is confusing me is all your changes from the norm. I would like to see how it works
with defaults to get a reference. I also don't know what you mean by truncating to 32,
affinity is 64 bits. and you don't have more than 32 CPUs anyway.
I don't know the case you posted but there were errors
Code:
affine_to_cpu_mask for 1 returned 57
repeated for many CPUs, seems to be all the odd numbered ones.
EDIT:
I can't find what error 57 means.
Some useful tests, you don't have to post the session just whether it worked as expected.
Running less than N threads should be by factors of 2. Anything else is YMMV.
And forcing the process affinity disqualifies everything.
1. All defaults
2. 14 threads default affinity, note wether cpu loads are balanced, ie affinity was properly
distributed.
3. If unbalanced try setting affinity 0x5555555 or 0xaaaaaaa
If everything works as expected I don't see a problem. Windows issues like CPU groups and
NUMA shouldn't be an issue until you get over 64 CPUs.
There are more than 32 CPUs (check the debug above: 56 CPU cores available, 30 miner threads selected.).
If I select all 28 even CPUs for instance, that means an affinity of 0x55555555555555 which is over 32 bits. If I do set --cpu-affinity=0x55555555555555 , I can check in Task Manager that affinities for CPUs above CPU 31 are not set, which led me to think that affinity is truncating to lower 32 bits.
I do think the warning is just that: a warning, but wanted to be sure as v3.8.8 did not issue such warning before.
And yes, there is no warning issued if I use --cpu-affinity (or don't use it at all) as long as I don't set affinity externally beforehand, so that is not an issue.
EDIT: I made a few tests and verified the following:
* With v3.8.8, a cpu affinity works correctly up to 0xffffff; above that, it triggers that exactly the first 32 CPUs are used, no matter the value.
* With v3.9.1.1, a cpu affinity works correctly up to 0xf; above that, it triggers that exactly the first 32 CPUs are used, no matter the value.
I verified this by using the CPU affinity option in Task Manager for the miner process.
So the reason I set affinity externally is because I could never rely on the built-in cpu affinity for most miners. It seems to break in some configurations.
Your still jumping ahead. What about defaults? I need to underestand how it works with defaults
before you throw this other stuff at me.
Your CPU has 14/28 cores/threads but you didn't say you had 4 of them.
So now I have a clue what error 57 means, one more than the number of cpus.
It suggests that it was attempting to affine beyond 56.
The change to support CPU groups in v3.9 resulted in using different Windows functions for
counting the number of CPUs and setting the affinity. This appears to be a Windows
specific problem as Linux affinity works up to 64 CPUs and is ignored with more than 64
CPUs.
Edit: I took another look at the code changes and there should be no difference if cpu groups
is not enabled. A change in behaviour means it's running different code. But if it was running
the new code the "Binding thread" message would have included the group. I don't know what's
going on.
You can still have cpu groups with fewer than 64 cpus.
June 03, 2019, 04:05:46 PM
If they are compiled with MinGW, the performance will be lower. Cross-compile with GCC does a better job optimizing
This statement caught my attention. The binaries are cross-compiled with GCC in a mingw environment
runing on Linux. What are you referring to that is better?
Right, I meant that cross compile is faster than using Cygwin on Windows. Not MinGW... Mixed them up ))
June 03, 2019, 02:40:37 PM
What is confusing me is all your changes from the norm. I would like to see how it works
with defaults to get a reference. I also don't know what you mean by truncating to 32,
affinity is 64 bits. and you don't have more than 32 CPUs anyway.
I don't know the case you posted but there were errors
Code:
affine_to_cpu_mask for 1 returned 57
repeated for many CPUs, seems to be all the odd numbered ones.
EDIT:
I can't find what error 57 means.
Some useful tests, you don't have to post the session just whether it worked as expected.
Running less than N threads should be by factors of 2. Anything else is YMMV.
And forcing the process affinity disqualifies everything.
1. All defaults
2. 14 threads default affinity, note wether cpu loads are balanced, ie affinity was properly
distributed.
3. If unbalanced try setting affinity 0x5555555 or 0xaaaaaaa
If everything works as expected I don't see a problem. Windows issues like CPU groups and
NUMA shouldn't be an issue until you get over 64 CPUs.
There are more than 32 CPUs (check the debug above: 56 CPU cores available, 30 miner threads selected.).
If I select all 28 even CPUs for instance, that means an affinity of 0x55555555555555 which is over 32 bits. If I do set --cpu-affinity=0x55555555555555 , I can check in Task Manager that affinities for CPUs above CPU 31 are not set, which led me to think that affinity is truncating to lower 32 bits.
I do think the warning is just that: a warning, but wanted to be sure as v3.8.8 did not issue such warning before.
And yes, there is no warning issued if I use --cpu-affinity (or don't use it at all) as long as I don't set affinity externally beforehand, so that is not an issue.
EDIT: I made a few tests and verified the following:
* With v3.8.8, a cpu affinity works correctly up to 0xffffff; above that, it triggers that exactly the first 32 CPUs are used, no matter the value.
* With v3.9.1.1, a cpu affinity works correctly up to 0xf; above that, it triggers that exactly the first 32 CPUs are used, no matter the value.
I verified this by using the CPU affinity option in Task Manager for the miner process.
So the reason I set affinity externally is because I could never rely on the built-in cpu affinity for most miners. It seems to break in some configurations.
June 03, 2019, 02:12:40 PM
If they are compiled with MinGW, the performance will be lower. Cross-compile with GCC does a better job optimizing
This statement caught my attention. The binaries are cross-compiled with GCC in a mingw environment
runing on Linux. What are you referring to that is better?
June 03, 2019, 12:37:29 PM
I suggest you not set the process affinity explicitly, it confuses cpuminer. Also please add -D option
and post output.
I'll have to set it explicitely for now because --cpu-affinity truncates to 32 bits, thus not allowing the use of CPUs above 31.
Sorry, I'm not sure on what situation you want me to post the debug.
Is this enough?
What is confusing me is all your changes from the norm. I would like to see how it works
with defaults to get a reference. I also don't know what you mean by truncating to 32,
affinity is 64 bits. and you don't have more than 32 CPUs anyway.
I don't know the case you posted but there were errors
Code:
affine_to_cpu_mask for 1 returned 57
repeated for many CPUs, seems to be all the odd numbered ones.
EDIT:
I can't find what error 57 means.
Some useful tests, you don't have to post the session just whether it worked as expected.
Running less than N threads should be by factors of 2. Anything else is YMMV.
And forcing the process affinity disqualifies everything.
1. All defaults
2. 14 threads default affinity, note wether cpu loads are balanced, ie affinity was properly
distributed.
3. If unbalanced try setting affinity 0x5555555 or 0xaaaaaaa
If everything works as expected I don't see a problem. Windows issues like CPU groups and
NUMA shouldn't be an issue until you get over 64 CPUs.
June 03, 2019, 11:55:39 AM
I suggest you not set the process affinity explicitly, it confuses cpuminer. Also please add -D option
and post output.
I'll have to set it explicitely for now because --cpu-affinity truncates to 32 bits, thus not allowing the use of CPUs above 31.
Sorry, I'm not sure on what situation you want me to post the debug.
Is this enough?
Code:
********** cpuminer-opt 3.9.1.1 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI and AVX2 and SHA extensions.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
CPU: Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz.
SW built on May 31 2019 with GCC 7.3.0.
CPU features: SSE2 AES SSE4.2 AVX AVX2.
SW features: SSE2 AES SSE4.2 AVX AVX2.
Algo features: SSE2.
Start mining with SSE2.
[2019-06-03 17:52:38] 56 CPU cores available, 30 miner threads selected.
[2019-06-03 17:52:38] Starting Stratum on stratum+tcp://*****
[2019-06-03 17:52:38] Binding thread 0 to cpu 0 (mask 1)
[2019-06-03 17:52:38] Binding thread 1 to cpu 1 (mask 2)
[2019-06-03 17:52:38] Binding thread 4 to cpu 4 (mask 10)
[2019-06-03 17:52:38] Binding thread 26 to cpu 26 (mask 4000000)
[2019-06-03 17:52:38] affine_to_cpu_mask for 1 returned 57
[2019-06-03 17:52:38] Binding thread 2 to cpu 2 (mask 4)
[2019-06-03 17:52:38] Binding thread 5 to cpu 5 (mask 20)
[2019-06-03 17:52:38] affine_to_cpu_mask for 5 returned 57
[2019-06-03 17:52:38] Binding thread 7 to cpu 7 (mask 80)
[2019-06-03 17:52:38] affine_to_cpu_mask for 7 returned 57
[2019-06-03 17:52:38] Binding thread 3 to cpu 3 (mask 8)
[2019-06-03 17:52:38] affine_to_cpu_mask for 3 returned 57
[2019-06-03 17:52:38] Binding thread 10 to cpu 10 (mask 400)
[2019-06-03 17:52:38] Binding thread 11 to cpu 11 (mask 800)
[2019-06-03 17:52:38] affine_to_cpu_mask for 11 returned 57
[2019-06-03 17:52:38] Binding thread 13 to cpu 13 (mask 2000)
[2019-06-03 17:52:38] affine_to_cpu_mask for 13 returned 57
[2019-06-03 17:52:38] Binding thread 15 to cpu 15 (mask 8000)
[2019-06-03 17:52:38] affine_to_cpu_mask for 15 returned 57
[2019-06-03 17:52:38] Binding thread 17 to cpu 17 (mask 20000)
[2019-06-03 17:52:38] affine_to_cpu_mask for 17 returned 57
[2019-06-03 17:52:38] Binding thread 6 to cpu 6 (mask 40)
[2019-06-03 17:52:38] Binding thread 19 to cpu 19 (mask 80000)
[2019-06-03 17:52:38] affine_to_cpu_mask for 19 returned 57
[2019-06-03 17:52:38] Binding thread 21 to cpu 21 (mask 200000)
[2019-06-03 17:52:38] affine_to_cpu_mask for 21 returned 57
[2019-06-03 17:52:38] Binding thread 23 to cpu 23 (mask 800000)
[2019-06-03 17:52:38] affine_to_cpu_mask for 23 returned 57
[2019-06-03 17:52:38] 30 miner threads started, using 'yespowerr16' algorithm.
[2019-06-03 17:52:38] Binding thread 25 to cpu 25 (mask 2000000)
[2019-06-03 17:52:38] affine_to_cpu_mask for 25 returned 57
[2019-06-03 17:52:38] Binding thread 27 to cpu 27 (mask 8000000)
[2019-06-03 17:52:38] Binding thread 28 to cpu 28 (mask 10000000)
[2019-06-03 17:52:38] Binding thread 29 to cpu 29 (mask 20000000)
[2019-06-03 17:52:38] affine_to_cpu_mask for 29 returned 57
[2019-06-03 17:52:38] Binding thread 12 to cpu 12 (mask 1000)
[2019-06-03 17:52:38] Binding thread 14 to cpu 14 (mask 4000)
[2019-06-03 17:52:38] Binding thread 16 to cpu 16 (mask 10000)
[2019-06-03 17:52:38] Binding thread 18 to cpu 18 (mask 40000)
[2019-06-03 17:52:38] Binding thread 20 to cpu 20 (mask 100000)
[2019-06-03 17:52:38] Binding thread 22 to cpu 22 (mask 400000)
[2019-06-03 17:52:38] Binding thread 24 to cpu 24 (mask 1000000)
[2019-06-03 17:52:38] Binding thread 8 to cpu 8 (mask 100)
[2019-06-03 17:52:38] Binding thread 9 to cpu 9 (mask 200)
[2019-06-03 17:52:38] affine_to_cpu_mask for 9 returned 57
[2019-06-03 17:52:38] Stratum session id: 2ee7a1bb44758f49710830c357335031
[2019-06-03 17:52:39] Stratum difficulty set to 1
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=00000000 ntime=5cf55048
[2019-06-03 17:52:39] yespowerr16 block 403605, network diff 0.013
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=01000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=02000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=03000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=04000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=05000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=06000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=07000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=08000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=09000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=0a000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=0b000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=0c000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=0d000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=0e000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=0f000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=10000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=11000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=12000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=13000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=14000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=15000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=16000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=17000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=18000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=19000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=1a000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=1b000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=1c000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=1d000000 ntime=5cf55048
[2019-06-03 17:52:39] DEBUG: job_id='690a' extranonce2=1e000000 ntime=5cf55048
[2019-06-03 17:52:46] DEBUG: job_id='690c' extranonce2=00000000 ntime=5cf5505e
[2019-06-03 17:52:54] DEBUG: hash <= target
Hash: 0000758736c194d8a115384dffac8218e7af7a552d235f254016c1c164269128
Target: 0000ffff00000000000000000000000000000000000000000000000000000000
[2019-06-03 17:52:54] Share submitted.
[2019-06-03 17:52:55] Accepted 1/1 (100%), diff 3.32e-005, 2179.22 H/s
[2019-06-03 17:53:07] DEBUG: job_id='690e' extranonce2=00000000 ntime=5cf55073
[2019-06-03 17:53:28] DEBUG: job_id='690f' extranonce2=00000000 ntime=5cf55088
[2019-06-03 17:53:41] DEBUG: hash <= target
Hash: 00000f473fd9fdd57695a4730ccb13bbb31645b08ec9a5fdd6cc0f7c870dd7ef
Target: 0000ffff00000000000000000000000000000000000000000000000000000000
[2019-06-03 17:53:41] Share submitted.
[2019-06-03 17:53:41] Accepted 2/2 (100%), diff 0.000256, 2179.37 H/s
June 03, 2019, 11:40:57 AM
Argh, I'm sorry. I meant yespowerR16 instead of yescryptR16 in my last item! And I was referring to bellflower2015's fork of your miner (you can easily find it on github).
Thanks!
I suggest you not set the process affinity explicitly, it confuses cpuminer. Also please add -D option
and post output.
About yespower, I see the correction you made to your initial post. If I understand, you observed a drop
in yescrypt performance over v3.8.8, but the big difference was with yespower vs bellflower fork.
I can't explain the yescrypt difference, as I said I made no changes but I'll take another look.
I'll also check out Bellflower.
Jump to: