We had a report earlier this week about this that was similar.
But we don't know the cause at the moment.
Here is what we do know.
For a certain CPU model (any CPU) there are a range of different performance level. The differences are explained by overclocking, different memory speeds, single or dual channel setups, BIOS timing configs, background software running on the machine, single rank RAM or dual rank, ECC RAM or not, buffered RAM or not, etc... etc....
So the distribution of results for the database test typically looks like this (around 1200 different machines with the Intel 13600K CPU for this example graph).
There are a few machines (a couple of percent of all machines tested) at both extremes. A few are really really messed up and a few are highly optimised. The vast majority sit somewhere in the middle.
However for a small number of high core count CPUs we see an excess of machines at the low end. Instead of seeing maybe 3% of machines being in a bad messed up state, we are seeing more around 10% to 15%.
This 10% number seems to be too high to be explained by just bad settings however. On the other hand these high core count CPUs are much more difficult to setup in an optimal fashion. For example they tend to have lots of RAM slots, use multiple memory busses and have NUMA issues. So it is much easier, for example, to end up in single channel mode accidentally. But bad setup should affect more than just the database test and in at some cases we don't see that. Just the database test is affected.
Here is a graph of the Intel 13900K results for the database test and the Threaded memory test.
There is good correlation (as expected) between the database test and the multi-threaded test. Both tests should be pushing the RAM and CPU's memory controller to the limit.
But there is significant de-correlation for the slow database results for this 13900K CPU that we don't see for CPUs with smaller core counts.
2nd post to follow with some suggestions.
Leave a comment: