Problem with my tournement setup discovered

[Dann Corbit]

The tournament is on an 8 physical core machine.
Tournament is no ponder.
The original formula fruit engines were set up with 8 threads.
The new stockfish null move pruning version was accidentally set up with 1 thread.
You would think it was a disadvantage, but it appears that with high speed tournaments the overhead of thread management is higher than the benefit of multiple threads.

The thread count was the only difference in the configuration.

[bob]

The tournament is on an 8 physical core machine.
Tournament is no ponder.
The original formula fruit engines were set up with 8 threads.
The new stockfish null move pruning version was accidentally set up with 1 thread.
You would think it was a disadvantage, but it appears that with high speed tournaments the overhead of thread management is higher than the benefit of multiple threads.

The thread count was the only difference in the configuration.

Here's the issue: It seems like 8 one-thread new versions vs 8 8-thread old versions. If you assume that 1/2 of the time 4 or those 8 thread versions are running using all 8 cores, they each get the equivalent of 2 cores each. That poor one thread version gets the equivalent of less than 1/4 or a core (assumption 4x1 core + 4x8core =36 core requirement but only 8 cores available = 8/36 or just under 1/4).

HUGE handicap.

I have done similar however. You do have to watch the testbed like a hawk. My usual cluster somehow did an auto-update to the latest Debian version last week. My results immediately went much more noisy. When investigating, I found a daemon avahi-daemon running amok on every node, burning 100% of one CPU. I schedule games assuming one core per game normally. Throw in a rogue process that steals cpu time randomly from each process, and you see an increase in the randomness of the results. I deleted the thing from this cluster since I don't need it at all. And I am going through all the other crapware as well right now...