Actually, Robert, I (think) I understand what you're trying to describe, but - in this situation - all that matters is a test case where the issue (stutters) can be reproduced/observed any number of times - as many times as the scenario is run - and will consistently occur at the same moment.
If the randomness you mention caused the stutters to *fail to* appear, it might be a problem. But - while I'm not claiming "total control", it's fairly easy to create a test case in which the issue we're discussing can be duplicated. Unless you're saying the test is somehow causing the stutters, then the test itself shouldn't be at issue, and as long as it presents the stutters then randomness shouldn't be a concern. If they are consistently there without a proposed fix, and not there with a proposed fix, consistently, then I'd say the "proof of the pudding is in the eating" (as the actual original proverb goes).
Again, what's key is the consistency. Once you have a scenario where you *always* see the issue (without fixes), then you can begin testing solutions until you *do not* see the issue.
You have to remember, this was important and significant enough that it was mentioned back on that CFS3 tweak guide thread I mentioned. And I believe the folks involved at the time understood what you've mentioned - which is actually *why* there was specific emphasis put on a repeatable test scenario.
Last edited by kksnowbear; 02/21/19 06:26 PM.