Add bullet-point about disabling "Turbo-modes"

Elaborate on this point a bit how and why they interfere with
microbenchmarking.

PR:	262646

1 files changed, 3 insertions, 1 deletions

diff --git a/documentation/content/en/books/developers-handbook/testing/_index.adoc b/documentation/content/en/books/developers-handbook/testing/_index.adoc
index 4aae09a4ad..508268d60b 100644
--- a/documentation/content/en/books/developers-handbook/testing/_index.adoc
+++ b/documentation/content/en/books/developers-handbook/testing/_index.adoc
@@ -72,7 +72,9 @@ It is not possible to use all of the suggestions below every single time, but th
 * Remove all non-essential device drivers from the kernel. For instance if USB is not needed for the test, do not put USB in the kernel. Drivers which attach often have timeouts ticking away.
 * Unconfigure hardware that are not in use. Detach disks with man:atacontrol[8] and man:camcontrol[8] if the disks are not used for the test.
 * Do not configure the network unless it is being tested, or wait until after the test has been performed to ship the results off to another computer.
-+
+* Disable "Turbo-modes" because they make the clock frequency explicitly depend on the environment. This means that benchmark runs on 100% identical
+  code, may depend on time of day, coffee vs. soda or even how many other people are in the office.
+
 If the system must be connected to a public network, watch out for spikes of broadcast traffic. Even though it is hardly noticeable, it will take up CPU cycles. Multicast has similar caveats.
 * Put each file system on its own disk. This minimizes jitter from head-seek optimizations.
 * Minimize output to serial or VGA consoles. Running output into files gives less jitter. (Serial consoles easily become a bottleneck.) Do not touch keyboard while the test is running, even kbd:[space] or kbd:[back-space] shows up in the numbers.