Thanks for the update, if you're out of pocket at all for the VPS (assuming it was online of course) then I for one don't mind helping you out with a few dollars. Will this be an on going solution, or a one off fix?
The problem seems to be a current insufficient of staking chunks. More CBX would need to stake in order to stabilize the network. |
|
|
|
If we can get the chain going again, I can get at least 2 more nodes up.
This chain needs need staking nodes, not just regular ones. It is worth to have some coins on those nodes, preferably divides into several inputs. I'll try to move the chain today. I suppose you had no luck there. I believe your suggestion is mostly right: after 6 hours, all wallets consider themselves out-of-sync, at least when restarted. I also made a similar hack to try to move things around but unfortunately this time none of my current coin chunks meet the necessary criteria to stake: being still for 1 hour is not enough, although in practice it usually is. There is a flag called "stake-modifier". Your chunks can only stake if there is a block with this flag at least an hour in the future since your chunk was last moved/staked. And this is exactly my problem: most of my chunks are within an hour of that last block, so not eligible at all. I have 2 other chunks that are older than the current last block, just over an hour, but unfortunately the last 2 blocks in the chain (those over an hour for me) do not have the necessary "stake-modifier" flag so I cannot make them stake. The solution seems to be someone with eligible chunks to try to stake hacking the wallet code and bypassing that 6-hour sync limit.. |
|
|
|
Nah, don't worry about that. I'm glad to help. Btw, in Vault v3 there's an option accessible from the menu for an automated bootstrap load in case you prefer that over the manual, somewhat cumbersome, procedure. Cheers. |
|
|
|
Please upload Bootstrap.zip I want to keep this online . Also if possible upload latest version. I see real potential in this project. 6 years seems to long to update. Don't let me down  my Bootstrap got broken. Br, paavo This is the most recent bootstrap for Vault v3: http://data.bullion.one/v30/bootstrap.zipIt's a bit old, I know... |
|
|
|
|
This may be nonsense but please bear with me:
Blake2b seems to be optimized for AVX2. Power2b just supports SSE2.
Assuming that power2b uses blake2b internally, and the latter is/may be optimized with AVX2, my question is couldn't power2b use blake2b's already existing AVX2 optimizations, and not fall back as a whole to SSE2?
|
|
|
|
X12 for AVX2 is broken again, or should I say, still. I thought I fixed it in v3.11.3 but now I can't find a working version for AVX2.
I'm investigating.
Thanks. Please also add to your list that phi is crashing in AVX2 immediately upon start. |
|
|
|
|
Hi.
I was just wondering: in the current periodic share/speed report, is there the raw hash rate, the one the machine can actually compute? Not sure if the value in parenthesis is this number as it seems quite smaller than the value I got from older versions. Does --benchmark still output this value reliably?
Thanks.
|
|
|
|
There's another downside to specifying a custom cpu affinity. Whe using the default
each thread is affined to a precise cpu, the one matching the thread number.
With a custom affinity mask it's more complicated so the thread is afffined to the "mask"
which means any of the allowable cpus.
I don't feel like doing the additional coding to do one to one matching of each thread
to a unique allowable cpu.
Affinity should only be needed if there is a good reason to run fewer threads and if the CPU
is an AMD. That's small set.
The almost-alternating masks on Windows was found by trial and error to yield the best performance with all the Intel CPUs I've experimented with (correction: for a few older ones, it doesn't make any difference in which case I don't set affinity). I just know that Linux uses a different numbering convention and that rules are different, but an alternating mask always seemed best on Windows. Or perhaps the numbering convention in cpuminer is not the same as in Windows Power Shell. I will try to incorporate the info you posted along with the new release and see if it makes any difference. One thing seems for sure: many times, using all CPUs is worse than using just a subset (memory/L cache ceiling somewhere? Maybe with more CPUs it's even worse), and using a specific affinity seems to always work better than using default one with a subset of CPUs. Thanks and let's move on. |
|
|
|
I've made some more tweaks and this is what I get with -t 8 --cpu-affinity=0x5555
on Linux. I'l wait for your test results on Windows before I commit the change.
Also what is your goal? Why are you going to all this trouble with odd thread counts and
complex affinity masks?
I will do what you ask when I have the chance. I thought the problem was already clear that it would never set affinity to CPU# > 31. What do you mean by "complex" masks? Why do I have to choose submultiples of the number of processors and why would it be better? In this last example, I set half minus 3. Changing some 5s to 4s in the mask shouldn't be considered "complex". Nor should 8 threads with a mask of 0x40404040404041 (8 throw better performance than 7  ). Shouldn't they all work? I'm sure that when "simple" masks work the "complex" ones will follow. Question: "half threads (28), default affinity": what is a pass in this test? Default affinity always works in that all CPUs are allocated to the process. I'll send my results back to you by PM in order not to pollute this thread. Cheers. |
|
|
|
This CPU affinity crap is starting to piss me off. That's not what I came back for.
It's taking way too much of my time.
This all started with a request to support CPU groups on Windows. Windows is a
commercial product: it costs money to use it and takes even more money to
develop on it and for it. Enterprise level development (multi-socket, large thread
counts, NUMA, CPU groups, etc) costs even more.
Yet I don't get paid a penny.
From now on any requests for features specific to Windows must be accompanied
by a nominal non-refundable donation. I will do an assessment and determine if I can
do it with my skill level and resources and how much work may be involved. I will
then set a fee payable on completion. The fee will be scaled based on whether the
feature is for consumers or enterprises.
CPU groups is an enterprise feature. I will make one more attempt to fix the current
issues. If that fails I wlll remove the CPU Groups support and revert to v3.8.8.1 affinity..
I got you. As a side note, I have no problem with CPU affinity not working. Like I said before, I set it externally exactly because it never seemed to be reliable. The only reason I'm doing all this troubleshooting is because you asked why I was was doing that (setting affinity externally) instead of using the built-in feature. I don't need it fixed. It works for me as is. I just thought you actually wanted to fix it. And again, I'm not using CPU groups. That said I definitely would prefer efforts to be directed to something more useful, such as performance improvements as well as new algos. So I think we're on the same wavelength. Cheers.
CPU affinity still does not set correctly in v3.9.2.3. In Task Manager, it seems it still can't affine CPUs above CPU31. Also, some CPUs not specified in the mask are set.
Setting --cpu-affinity=0x55555545555544 with 56 CPUs:
Enough with the overly complex test cases. I've said it before DEFAULTS! What are the defaults? Not setting affinity? The performance drop is significant in that case. With default (not set) affinity (all CPUs involved): ********** cpuminer-opt 3.9.2.3 ***********
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 Jun 5 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-07 17:40:40] 56 CPU cores available, 8 miner threads selected.
[2019-06-07 17:40:40] 8 miner threads started, using 'yespowerr16' algorithm.
[2019-06-07 17:40:40] Starting Stratum on stratum+tcp://***
[2019-06-07 17:40:40] Stratum difficulty set to 1
[2019-06-07 17:41:01] yespowerr16 block 406437, network diff 0.014
[2019-06-07 17:41:53] Share submitted.
[2019-06-07 17:41:53] Accepted 1/1 (100%), diff 0.000167, 1273.16 H/s
[2019-06-07 17:42:14] Share submitted.
[2019-06-07 17:42:14] Accepted 2/2 (100%), diff 1.82e-005, 1275.10 H/s
[2019-06-07 17:42:15] Share submitted.
[2019-06-07 17:42:16] Accepted 3/3 (100%), diff 4.15e-005, 1264.21 H/s
With affinity set externally to some specific CPUs: ********** cpuminer-opt 3.9.2.3 ***********
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 Jun 5 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-07 17:36:34] 56 CPU cores available, 8 miner threads selected.
[2019-06-07 17:36:34] affine_to_cpu_mask for 1 returned 57
[2019-06-07 17:36:34] 8 miner threads started, using 'yespowerr16' algorithm.
[2019-06-07 17:36:34] affine_to_cpu_mask for 0 returned 57
[2019-06-07 17:36:34] Starting Stratum on stratum+tcp://***
[2019-06-07 17:36:34] affine_to_cpu_mask for 2 returned 57
[2019-06-07 17:36:34] affine_to_cpu_mask for 3 returned 57
[2019-06-07 17:36:34] affine_to_cpu_mask for 4 returned 57
[2019-06-07 17:36:34] affine_to_cpu_mask for 5 returned 57
[2019-06-07 17:36:34] affine_to_cpu_mask for 6 returned 57
[2019-06-07 17:36:34] affine_to_cpu_mask for 7 returned 57
[2019-06-07 17:36:35] Stratum difficulty set to 1
[2019-06-07 17:36:35] yespowerr16 block 406435, network diff 0.013
[2019-06-07 17:36:52] yespowerr16 block 406436, network diff 0.013
[2019-06-07 17:36:55] Share submitted.
[2019-06-07 17:36:55] Accepted 1/1 (100%), diff 2.72e-005, 1423.16 H/s
[2019-06-07 17:37:05] Share submitted.
[2019-06-07 17:37:05] Accepted 2/2 (100%), diff 6.46e-005, 1422.13 H/s
|
|
|
|
CPU affinity still does not set correctly in v3.9.2.3. In Task Manager, it seems it still can't affine CPUs above CPU31. Also, some CPUs not specified in the mask are set. Setting --cpu-affinity=0x55555545555544 with 56 CPUs: ********** cpuminer-opt 3.9.2.3 ***********
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 Jun 5 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-07 10:02:58] 56 CPU cores available, 25 miner threads selected.
[2019-06-07 10:02:58] Starting Stratum on stratum+tcp://***
[2019-06-07 10:02:58] Binding thread 0 to cpu mask ffffffffffffffff ffffffffffffffff
[2019-06-07 10:02:58] affine_to_cpu_mask for 0 returned 57
[2019-06-07 10:02:58] Binding thread 9 to cpu mask ffffffffffffffff fffffffffffffe00
[2019-06-07 10:02:58] affine_to_cpu_mask for 9 returned 57
[2019-06-07 10:02:58] Binding thread 12 to cpu mask ffffffffffffffff fffffffffffff000
[2019-06-07 10:02:58] affine_to_cpu_mask for 12 returned 57
[2019-06-07 10:02:58] Binding thread 18 to cpu mask ffffffffffffffff fffffffffffc0000
[2019-06-07 10:02:58] affine_to_cpu_mask for 18 returned 57
[2019-06-07 10:02:58] Binding thread 20 to cpu mask ffffffffffffffff fffffffffff00000
[2019-06-07 10:02:58] Binding thread 7 to cpu mask ffffffffffffffff ffffffffffffff80
[2019-06-07 10:02:58] affine_to_cpu_mask for 7 returned 57
[2019-06-07 10:02:58] Binding thread 1 to cpu mask ffffffffffffffff fffffffffffffffe
[2019-06-07 10:02:58] affine_to_cpu_mask for 1 returned 57
[2019-06-07 10:02:58] Binding thread 10 to cpu mask ffffffffffffffff fffffffffffffc00
[2019-06-07 10:02:58] affine_to_cpu_mask for 10 returned 57
[2019-06-07 10:02:58] Binding thread 3 to cpu mask ffffffffffffffff fffffffffffffff8
[2019-06-07 10:02:58] affine_to_cpu_mask for 3 returned 57
[2019-06-07 10:02:58] Binding thread 13 to cpu mask ffffffffffffffff ffffffffffffe000
[2019-06-07 10:02:58] affine_to_cpu_mask for 13 returned 57
[2019-06-07 10:02:58] Binding thread 15 to cpu mask ffffffffffffffff ffffffffffff8000
[2019-06-07 10:02:58] affine_to_cpu_mask for 15 returned 57
[2019-06-07 10:02:58] Binding thread 17 to cpu mask ffffffffffffffff fffffffffffe0000
[2019-06-07 10:02:58] affine_to_cpu_mask for 17 returned 57
[2019-06-07 10:02:58] Binding thread 5 to cpu mask ffffffffffffffff ffffffffffffffe0
[2019-06-07 10:02:58] affine_to_cpu_mask for 5 returned 57
[2019-06-07 10:02:58] 25 miner threads started, using 'yespower' algorithm.
[2019-06-07 10:02:58] Binding thread 21 to cpu mask ffffffffffffffff ffffffffffe00000
[2019-06-07 10:02:58] affine_to_cpu_mask for 21 returned 57
[2019-06-07 10:02:58] affine_to_cpu_mask for 20 returned 57
[2019-06-07 10:02:58] Binding thread 8 to cpu mask ffffffffffffffff ffffffffffffff00
[2019-06-07 10:02:58] affine_to_cpu_mask for 8 returned 57
[2019-06-07 10:02:58] Binding thread 23 to cpu mask ffffffffffffffff ffffffffff800000
[2019-06-07 10:02:58] affine_to_cpu_mask for 23 returned 57
[2019-06-07 10:02:58] Binding thread 11 to cpu mask ffffffffffffffff fffffffffffff800
[2019-06-07 10:02:58] affine_to_cpu_mask for 11 returned 57
[2019-06-07 10:02:58] Binding thread 14 to cpu mask ffffffffffffffff ffffffffffffc000
[2019-06-07 10:02:58] affine_to_cpu_mask for 14 returned 57
[2019-06-07 10:02:58] Binding thread 6 to cpu mask ffffffffffffffff ffffffffffffffc0
[2019-06-07 10:02:58] affine_to_cpu_mask for 6 returned 57
[2019-06-07 10:02:58] Binding thread 22 to cpu mask ffffffffffffffff ffffffffffc00000
[2019-06-07 10:02:58] affine_to_cpu_mask for 22 returned 57
[2019-06-07 10:02:58] Binding thread 2 to cpu mask ffffffffffffffff fffffffffffffffc
[2019-06-07 10:02:58] affine_to_cpu_mask for 2 returned 57
[2019-06-07 10:02:58] Binding thread 16 to cpu mask ffffffffffffffff ffffffffffff0000
[2019-06-07 10:02:58] affine_to_cpu_mask for 16 returned 57
[2019-06-07 10:02:58] Binding thread 24 to cpu mask ffffffffffffffff ffffffffff000000
[2019-06-07 10:02:58] affine_to_cpu_mask for 24 returned 57
[2019-06-07 10:02:58] Binding thread 19 to cpu mask ffffffffffffffff fffffffffff80000
[2019-06-07 10:02:58] affine_to_cpu_mask for 19 returned 57
[2019-06-07 10:02:58] Binding thread 4 to cpu mask ffffffffffffffff fffffffffffffff0
[2019-06-07 10:02:58] affine_to_cpu_mask for 4 returned 57
[2019-06-07 10:02:59] Stratum session id: 2cd01d0b28be7edd72b3b4e03ce04797
|
|
|
|
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. |
|
|
|
I tried using --cpu-affinity=0x3 in another computer (laptop) without setting affinity externally. Results are similarly problematic: ********** 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. |
|
|
|
Does this help?
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...). 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." |
|
|
|
Does this help? Not specifying --cpu-affinity: [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: [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. |
|
|
|
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. |
|
|
|
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 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. |
|
|
|
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? ********** 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 |
|
|
|
A few points. and questions:
What's your CPU and OS?
[...]
Do you use CPU groups? Which version of Windows? You said you affine the process seperately and that
causes problems. That could be related to CPU groups if the process is in a different group from the miner
threads.
Tested on Intel(R) Xeon CPU E5-266O v4 @ 2.OOGHz CPUs, on Windows Servr 2016. I do not use CPU groups (not sure what those are: will look into that) and I tested with 20 CPUs. [EDIT: I checked and CPU groups are applicable to machines with more than 64 CPUs so I only have one group here] I open a command prompt and prior to launching cpuminer-opt I set the command prompt's affinity to the one desired (set to 20 CPUs). The miner then runs with the desired processors already affined. v3.9.1.1 now complains that it can't affine to all CPUs (obviously, because I removed some from the parent process). I'm supposing that's just a benign warning and nothing will really change. You probably made the miner explicitely affine to all CPUs by default on startup hence the warnings. Yescrypt performance:
There were no changes to the yescrypt code. I added yespower and tinkered with using that code for
yescrypt without success so I left yescrypt as is. If you are aware of a better performing miner
please point me to it and I'll have a look.
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'm consistently getting about 5% less hashrate for yescrypt than with older v3.8.8 for the exact same configuration. I didn't take more metrics but I think some other algos have slightly less performance as well.
If they are compiled with MinGW, the performance will be lower. Cross-compile with GCC does a better job optimizing If it's not the case, it might be something in the recent changes In both cases, I'm using the official Windows binaries. |
|
|
|
|
Show Posts
