Slower mprime iteration times after running needed benchmarks?

[PhilF]

I have a i3-9100 machine that recently started running mprime, so it has never run any benchmarks in the past. For its first exponent it is running a LL double-check of M58994843 (3200K FFT). The iteration time has been a steady 4.462 ms. since it started. But now that it has stopped, ran its needed benchmarks, and restarted, I'm getting a steady 4.517 ms. per iteration.

Is this normal?

[MattL]

Originally Posted by PhilF

I have a i3-9100 machine that recently started running mprime, so it has never run any benchmarks in the past. For its first exponent it is running a LL double-check of M58994843 (3200K FFT). The iteration time has been a steady 4.462 ms. since it started. But now that it has stopped, ran its needed benchmarks, and restarted, I'm getting a steady 4.517 ms. per iteration.

Is this normal?

I have a 32 core, 64 thread 3970X and saw similar behavior from benchmarks and cert work. Sometimes the falloff was dramatic when it restarted PRP work. I finally stopped doing cert work since my 24-cores dedicated to PRP could from from 2.1ms to 2.8ms and add lots of time to PRP completion.

For me though, even stopping and restarting from the dropdown menu would see huge time differences. Even when all the same 24 of 32 cores were used. So I'd end up doing a bunch of starts/stops until I got as low a time as possible and let it run. Something happens and the PRP gets stuck going slower. It doesn't fix itself either. You have to do the start/stop trick and hope for the best.

I also tried locking the same cores to the program via the OS and it still behaved the same way.

[moebius]

Originally Posted by PhilF

Is this normal?

Carry out a throughput benchmark from 2048K to 8192 K (estimate 2 hours).Terminate all processes that would otherwise be running on the PC. Add AutoBench = 0 in prime.txt. Delete all other benchmarks from results.bench. You should then get the best performance for the respective FFT size. The cooling of the processors is probably not sufficient, or it is memory-related. Dual Rank should be better than single rank for higher FFT-sizes, a memoryclock up to 4000 Mhz as far as I know for Ryzen 7 is possible.

[PhilF]

It turns out that for some reason, on this machine at least, the iteration times increase slightly when the monitor, mouse, and keyboard are connected. I use an electronic switch to switch those 3 accessories to several different computers, and as long as I keep them connected to a different system the iteration times are normal. The monitor is connected via VGA, the keyboard and mouse are USB. The operation system is Debian Buster.

I have not dug any deeper to determine which accessory when connected is causing the minor slow down (I suspect it is the monitor), or why stopping and restarting mprime triggers it.

[Viliam Furik]

I have Ryzen 9 3900X, 12C/24T, and I experience the same thing sometimes. Whenever I restart the worker(s), the iteration times are different. I think it may be due to silicon being not the same in each core, meaning the performance is different after the reshuffling of the core assignments.

[slandrum]

When I started up my computer doing it's first LL DC assignment, it had terrible ms/iter. After the first time it ran benchmarks there was a huge improvement, after the 2nd time running benchmarks a smaller, but noticeable improvement. Now, there's a slight decrease in performance after each time it runs the benchmarks. It's about 5% slower now than it was during its fastest period.