On 9/9/25 21:34, Leon Woestenberg wrote: > Basically, you are reverse-tuning a multicore CPU system, > that is heavily optimized for time-sharing and overall > system throughput, back to act like bare-metal single-application. > You can get close, but you will never reach the determinism > of say, an Cortex-R(ealtime) Core. This ignores the fact that I've been testing 2 programs: - P1, toy code that just calls dec 3 times in a tight loop - P2, a few memory accesses, everything fits in L1 I then loop P1 & P2 2^16 times to compute their average run-time. Over thousands of runs, RUNTIME_P1 is ALWAYS the same (within 30 ppm) Over thousands of runs, RUNTIME_P2 varies by up to 12 PERCENT (!!) = 122k ppm Since P1 runs fine without ANY jitter, the problem cannot be something inherent to the system itself, such as - SMM - IRQs firing randomly - drifting, jittery, jumping time source The problem appears to be something inherent to P2. (Either the whole core is slowed down perhaps by thermal throttling, or something is causing huge pipeline stalls.) Regards
