why DC credit can be so different

[rudi_m]

Hi,

I've notice in the current cat-1 DC Range (about 41.6 - 41.7 mill) that usually I get about 63.x GHz-Days credit but sometimes 61.x GHz Days.

Example:

41715517  C - Verified  2017-10-24 04:11  2.5  EB1DAE6DFFDC3E75  63.6741
41714069  C - Verified  2017-10-23 18:16  2.3  3E613C73FBFDB0B5  61.484
41712071  C - Verified  2017-10-23 17:06  2.6  3129BFD8229F268E  63.6688

How can this happen?

[GP2]

Originally Posted by rudi_m

How can this happen?

Probably different FFT sizes.

The program dynamically adjusts the FFT size if necessary, rather than using fixed boundaries.

[axn]

Are these on the same machines? AVX vs AVX2 (FMA3) can sometimes have different FFTs.

[rudi_m]

Ok thank you both. Seems that the last used implementation has influence on the credits, see the logs below (all from the same machine).

[Work thread Oct 15 22:19] Starting primality test of M41663449 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Work thread Oct 15 23:10] Resuming primality test of M41663449 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Work thread Oct 16 20:10] Resuming primality test of M41663449 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Comm thread Oct 17 13:34] CPU credit is 61.4102 GHz-days.

[Work thread Oct 17 13:34] Starting primality test of M41689003 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Work thread Oct 17 13:44] Resuming primality test of M41689003 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Work thread Oct 18 05:48] Resuming primality test of M41689003 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads
[Work thread Oct 19 02:48] Resuming primality test of M41689003 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Comm thread Oct 19 03:06] CPU credit is 61.4479 GHz-days.

[Work thread Oct 19 03:06] Starting primality test of M41699461 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Work thread Oct 19 12:27] Resuming primality test of M41699461 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Work thread Oct 20 05:31] Resuming primality test of M41699461 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads
[Comm thread Oct 20 17:38] CPU credit is 63.6496 GHz-days.

[Work thread Oct 20 17:38] Starting primality test of M41706887 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads
[Work thread Oct 21 02:31] Resuming primality test of M41706887 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Work thread Oct 21 23:31] Resuming primality test of M41706887 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads
[Comm thread Oct 22 07:20] CPU credit is 63.6609 GHz-days.

[Work thread Oct 22 07:20] Starting primality test of M41714069 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads
[Work thread Oct 22 20:31] Resuming primality test of M41714069 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads
[Work thread Oct 23 17:31] Resuming primality test of M41714069 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads
[Comm thread Oct 23 20:16] CPU credit is 61.4848 GHz-days.

If "Pass1=384, Pass2=6K" was last used then I get more credits than "Pass1=448, Pass2=5". This does not make much sense to me.

Also Pass1=384 is also always about 3-4% faster than Pass1=448 for this machine. So it seems that the new benchmark mechanism does not really help to improve things in my case. In summary, It happens that I need 3-4% more time to finish an exponent and I will also get another penalty of 3.5% less credits. :(

[Prime95]

Originally Posted by rudi_m

If "Pass1=384, Pass2=6K" was last used then I get more credits than "Pass1=448, Pass2=5". This does not make much sense to me.

Longer FFT lengths always get more CPU credit than shorter FFT lengths.

Also Pass1=384 is also always about 3-4% faster than Pass1=448 for this machine. So it seems that the new benchmark mechanism does not really help to improve things in my case.

That prime95 is switching back and forth means the auto-benchmark code thinks the throughtput of the two FFT sizes is nearly identical.

You might be able to edit the gwnum.txt file so that the 2240K FFT is never selected.

[retina]

Originally Posted by Prime95

Longer FFT lengths always get more CPU credit than shorter FFT lengths.

To my mind, regardless of the FFT length, when testing the same number we have done the same amount of useful work, and thus should be credited with the same amount of shagging rights. Note that I said "useful work", not simply "work". I could set myself a 32M FFT length and work on a 42M exponent. I'd get a lot more credit (if I had an account) than someone using a 2240K FFT length but most of the work is redundant/wasted. Do we really want to reward wasted effort?

[Madpoo]

Originally Posted by retina

To my mind, regardless of the FFT length, when testing the same number we have done the same amount of useful work, and thus should be credited with the same amount of shagging rights. Note that I said "useful work", not simply "work". I could set myself a 32M FFT length and work on a 42M exponent. I'd get a lot more credit (if I had an account) than someone using a 2240K FFT length but most of the work is redundant/wasted. Do we really want to reward wasted effort?

I thought it was just a reflection of the time taken for the test. Sure, you *could* run something using a ridiculously high FFT and get more credit, but it'll take you longer too.

I'm just guessing that the credit difference takes into account the difference in per-iteration times for the different FFT sizes so that it essentially makes it a "time taken" credit?

[retina]

Originally Posted by Madpoo

I thought it was just a reflection of the time taken for the test. Sure, you *could* run something using a ridiculously high FFT and get more credit, but it'll take you longer too.

In the OPs case above, the two FFTs (2304k and 2240k) have similar run times, and do the same amount of useful work, but the OP sees different credit.

[axn]

Originally Posted by retina

the two FFTs (2304k and 2240k) have similar run times

And similar credits. 63 vs 61 isn't a significant difference.

[rudi_m]

Originally Posted by axn

And similar credits. 63 vs 61 isn't a significant difference.

It's 3% less credits plus 3% longer run time. Maybe the most interesting part is that the larger FFT length can be the faster one at all. I've never seen that before.

Originally Posted by Prime95

That prime95 is switching back and forth means the auto-benchmark code thinks the throughtput of the two FFT sizes is nearly identical.

I did now a bit more analysis of all my log files and see that it's not really a big problem, because on most machines mprime finally uses the right FFT size continuously, once it has finished enough benchmarks. The most problematic machines were the ones which are often otherwise loaded by non-mprime jobs. I have only one out of 14 machines which is still using the wrong FFT length after having 10 auto-benchmarks finished.

To make this a bit better I've set now gwnum.txt to
BenchWorkers=1
BenchCores=3

.. as this is what I'm also using in practice in local.txt:
WorkerThreads=1
CoresPerTest=3

I would have expected that the default BenchCores should be the same like CoresPerTest.

Originally Posted by Prime95

You might be able to edit the gwnum.txt file so that the 2240K FFT is never selected.

Good Idea, actually I could merge all my gwnum.txt files from all similar machines. This would even save some benchmark time.

[science_man_88]

Originally Posted by rudi_m

It's 3% less credits plus 3% longer run time.

so 94+% the credit per unit time.