Yes I do.

The issue with zoin (lyra2z330) is memory bandwidth. The CPUs are stalled waiting for memory.
You can reduce the number of threads without losing hash.
An added complication in this case is multi CPU. I'm not sure how logical CPUs are mapped to the individual
Xeons. With a single CPU the default affinity works by assigning one thread to each logical CPU before using
hyperthreading. I don't know whether this will carry to the second CPU. When the first CPU has one thread on
each of it's cores wher does the next thread go? Does it start hyperthreading on the first CPU or start assigning
threads to the second CPU?
You could figure this out by monitoring the CPU's temperatures while running 20 threads with default affinity.
20 threads should be distruibuted evenly accross all 20 physical cores on both Xeons and the temperatures
of the CPUs should be the same. If one is hot and the other cool it indicates the default affinity put 20 threads
on one Xeon. If that happens you will have to play with the affinity to get threads assigned to the second CPU.
I'm sorry if I mis-phrased it. I have 1 CPU Xeon E5v3 (12C, 24T, 30M). The CPU is support Hyperthreading. I just tried to use different bat-files. I do not understand how the start line in the bat file should look to get the maximum hash speed.
Don't use affinity with default thread count, it just messes things up.
Try different affinities with 12 threads. The default should be the same as 0xffffff.
Which ones?
12 threads is:
The --cpu-affinity works as a bit mask. The least significant bit is the core 0, the next one is core 1 and so on.
Imagine the cores like:
0 1 2 3 4 5 6 7 8 9 10 11 (extended to 11 to fill a BYTE, 12 bits)
Now the bits for each core are:
1 0 1 0 1 0 1 0 1 0 1 0
This binary value now is encoded with 12th core first, so it becomes =>
010101010101
Converting it to hex values (grouping in fours and converting) becomes => 0101 0101 0101 => 0x555
So i must use --cpu-affinity 0x555 in my case? Or no?