Intel’s Coffee Lake Core i7-8700K has launched, earning our top CPU recommendation at its price point. But there’s one issue worth being aware of going forward: Intel has declared that it will no longer officially disclose its per-core Turbo frequencies. When we queried Intel why this was being changed, the company told us the following:

[W]e’re no longer disclosing this level of detail as its proprietary to Intel. Intel only specifies processor frequencies for base and single-core Turbo in our processor marketing and technical collateral, such as ARK, and not the multi-core Turbo frequencies. We’re aligning communications to be consistent. All Turbo frequencies are opportunistic given their dependency on system configuration and workloads.

There are several reasons to view this change as a negative. First, not all Intel CPUs are equally aggressive when it comes to their Turbo scaling, even if they have the same or similar Turbo ranges. This is one reason why the gap between chips can be wider than they’d otherwise be. The Core i7-8700K, for example, has a peak all-core frequency of 4.3GHz on six cores, which is fairly close to its peak frequency of 4.7GHz for single-core.

As a general rule, Intel’s higher-end CPUs will boost more aggressively than their lower-end cores, but even this isn’t absolute. You can’t assume that a CPU with a high single-core boost frequency also has an aggressive multi-core boost frequency, and you can’t assume that two CPUs with the same or very similar Turbo ranges have the same multi-core boost frequency distribution–though this is typically more of an issue when comparing between two different product generations as opposed to within the same family. We’d expect more variance between the 6700K and 7700K, for example, than between the Core i7-7700 and the Core i7-7700K.

Second, and arguably more importantly, a lot of motherboards don’t implement Turbo Boost well. We’ve seen motherboards literally reverse the way Turbo Boost is supposed to function, and downclock the CPU when running lightly threaded workloads as opposed to boosting it. We’ve seen boards either push the Turbo frequencies higher than default or lower than expected, even when explicitly ordered to use Intel’s default scaling.

Even more frustrating, this behavior can vary depending on which CPU you’re testing. Our Asus Prime X299-A motherboard displayed very different behavior when we tested the Core i9-7900X as opposed to the Core i9-7980XE. When we tested Broadwell-E on a Gigabyte motherboard earlier this year, we had to manually dial in multipliers, only to discover that the 35x multiplier–and only the 35x multiplier–would produce random clock drops unless every benchmark application was whitelisted in Intel’s Turbo Boost 3.0 app. This didn’t actually implement Turbo Boost 3.0-style scaling; it just kept the CPU clock from flipping back and forth between two different clock speeds while benchmarking. The 34x and 36x multipliers were unaffected.

Finally, motherboard manufacturers have permission from Intel to really boost clock speeds, if you’re loading XMP profiles. One problem we had with the 7980XE is that multiple attempts we made to set Intel stock Turbo settings would instead set an all-core boost frequency of 4.2GHz, vastly higher than Intel’s intended frequency of 3.4GHz. Intel has allowed motherboard manufacturers to make these aggressive changes when XMP is enabled for a number of years. But not every chip can handle them, and enthusiasts can end up destabilizing their own systems as a result if they don’t take note of the different clocking scheme that’s enabled when XMP is activated.

Some of these issues come with the territory. Pre-release hardware is called “pre-release” for a reason, and we almost always go through a UEFI revision or two during the testing process. Motherboard vendors are also pretty responsive to feedback on how Turbo modes are implemented, and are willing to assist with gathering data and making sure problems get resolved. But it’s precisely because Turbo modes are opportunistic and clocks can vary depending on the workload or even the SIMD set the application uses that this information is so valuable to have. If you don’t know what the per-core clock frequencies or AVX offsets are supposed to be, it’s not possible to determine whether you’re seeing appropriate frequencies at any given point. And Intel’s Turbo Boost clocks have always been opportunistic and have always depended on available cooling and thermal headroom. That’s not a justification for keeping the information secret when it’s literally how Turbo Boost has worked since the beginning.

This information can still be gathered via manual testing (assuming none of the issues above apply), and testing multiple motherboards would be the simplest way to make certain there are no issues affecting one specific model. Ultimately, Intel’s decision to restrict this information seems pointless. It makes it harder for end-users to determine whether their platforms are configured properly without actually preventing the specific information from being discovered. It’s a lose-lose for everyone, and it’s a policy we hope Intel reconsiders.