1 files changed, 5 insertions, 2 deletions
diff --git a/documentation/content/en/books/developers-handbook/testing/_index.adoc b/documentation/content/en/books/developers-handbook/testing/_index.adoc
index 72d039d239..0d1420a722 100644
--- a/documentation/content/en/books/developers-handbook/testing/_index.adoc
+++ b/documentation/content/en/books/developers-handbook/testing/_index.adoc
@@ -7,7 +7,8 @@ description: Regression and Performance Testing
 tags: ["Regression", "Performance Testing", "Testing", "Tinderbox"]
 showBookMenu: true
 weight: 7
-path: "/books/developers-handbook/"
+params:
+  path: "/books/developers-handbook/testing/"
 ---
 
 [[testing]]
@@ -72,7 +73,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.