Quote from: malafaya on June 03, 2019, 07:40:37 PM

Quote from: joblo on June 03, 2019, 05:37:29 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.