What are the most exciting things that can happen in order of likelihood?

[kriesel]

Originally Posted by EugenioBruno

Is my interpretation of that sentence correct: "the people doing LL are going fast, so we're starting to fall behind in TFs that might avoid those LL checks from being done"?

This is confusing to me. What is a DC wavefront in relation to TFs? If my understanding is correct, TFs are done *before* any LL (or DC) test is done. I don't unrestand, what do TFs have to do at all with DCs?

First, all, please stop referring to LL as if PRP primality testing doesn't exist. PRP is the preferred primality test for new first-test assignments.

DC can be either LL or PRP. There is a several year backlog of LL DC and growing. There is a need for more PRP DC on which to base an estimate of PRP in the wild total error rate.

Before gpu TF, factoring depth was less by default for the same exponent than it is now. One can make a case for additional bit levels of factoring that may eliminate the need for a double check, in those cases. Before first time primality testing, finding a factor saves the first primality test and the double check primality test (and the occasional third and fourth or more). After first time primality testing, further trial factoring if any is weighed against the double check and occasional third or higher check.

When the state of the trial factoring software art or hardware efficiency changes, the optimal tradeoff of trial factoring versus double checking effort shifts.
There is a several year backlog of LL double check, and some of PRP double check.
The introduction of GPU TF raised the ideal TF bit level by about 4.
The RTX20xx and GTX16xx are enough more efficient at TF that they raise the ideal TF bit level one more.
To put it another way, the ratio of TF to primality or P-1 Ghd/day ratings is typically about 0.7 to 1.4 on cpus. On gpus, it's 10. to 40. or so, with ~16. being pretty common.
So as a result of all that history, a lot of DC candidates are still at the TF level that was determined optimal and applied many years ago, which became suboptimal.
These are being revisited and taken further in TF. See for example this detailed exponent report, on one I have reserved for DC: https://www.mersenne.org/report_expo...exp_hi=&full=1

Also, my question about DC/LL percentage was in reference to my CPU worker.

Thanks! As you can see, I can contribute with cycles. Brain, not so much. :P

If you run about 20% DC, 80% first-test by cpu time, that is equivalent to about a 53M DC and a 103M first test in the same time frame, so is consistent with the current 8 year backlog. I encourage you to contribute more DC than that, to help keep the backlog from growing further. I've suggested that the project as a whole could refrain from issuing first-test assignments for one or two months of the year, to address the growing backlog. (Sort of spring and fall cleaning.) That idea is not very popular, although it doesn't reduce the rate of completed first tests much (8 or 17%), yet increases the rate of completed double checks a lot (60% or more).

Be patient with yourself. There's a big learning curve. One step at a time.
Contribute how you can and in the ways you enjoy.

Your choice of a GTX1650 is a good one. It's about as good a TF throughput per watt as can be found at reasonable price.

[EugenioBruno]

First of all, again, thanks for the in-depth replies!

(sorry, I've rearranged your post a bit for ease of replying)

Originally Posted by kriesel

First, all, please stop referring to LL as if PRP primality testing doesn't exist. PRP is the preferred primality test for new first-test assignments.

Yep, I think I referred to it as PRP in my first post about this, but I was trying to see if I understood the sentence I was quoting.

Originally Posted by kriesel

DC can be either LL or PRP. There is a several year backlog of LL DC and growing. There is a need for more PRP DC on which to base an estimate of PRP in the wild total error rate.

Originally Posted by kriesel

If you run about 20% DC, 80% first-test by cpu time, that is equivalent to about a 53M DC and a 103M first test in the same time frame, so is consistent with the current 8 year backlog. I encourage you to contribute more DC than that, to help keep the backlog from growing further. I've suggested that the project as a whole could refrain from issuing first-test assignments for one or two months of the year, to address the growing backlog. (Sort of spring and fall cleaning.) That idea is not very popular, although it doesn't reduce the rate of completed first tests much (8 or 17%), yet increases the rate of completed double checks a lot (60% or more).

I'll switch to 100% DC for now. I like shorter jobs anyway, and the idea of working on this backlog appeals a lot to me. I'll also be able to keep monitoring my hardware this way. If my error rates on DCs are unexpectedly high, I know something's wrong.

Originally Posted by kriesel

Before gpu TF, factoring depth was less by default for the same exponent than it is now. One can make a case for additional bit levels of factoring that may eliminate the need for a double check, in those cases.

Before first time primality testing, finding a factor saves the first primality test and the double check primality test (and the occasional third and fourth or more). After first time primality testing, further trial factoring if any is weighed against the double check and occasional third or higher check.

[...]

To put it another way, the ratio of TF to primality or P-1 Ghd/day ratings is typically about 0.7 to 1.4 on cpus. On gpus, it's 10. to 40. or so, with ~16. being pretty common.
So as a result of all that history, a lot of DC candidates are still at the TF level that was determined optimal and applied many years ago, which became suboptimal.
These are being revisited and taken further in TF. See for example this detailed exponent report, on one I have reserved for DC: https://www.mersenne.org/report_expo...exp_hi=&full=1

Ah, that makes a lot of sense. I understand.

Originally Posted by kriesel

The RTX20xx and GTX16xx are enough more efficient at TF that they raise the ideal TF bit level one more.

Originally Posted by kriesel

Your choice of a GTX1650 is a good one. It's about as good a TF throughput per watt as can be found at reasonable price.

Sigh of relief. I actually chose the 1650 based on a benchmark table for mfaktc but I was afraid I misunderstood it. Looks like I didn't!

Originally Posted by kriesel

Be patient with yourself. There's a big learning curve. One step at a time.
Contribute how you can and in the ways you enjoy.

Yep, it's a really fun project to follow and contribute to.

Eventually I'd like to get some math chops so I can also understand the discussions on number theory and software development, but I'm in no hurry.

[chalsall]

Originally Posted by EugenioBruno

Yep, I think I referred to it as PRP in my first post about this, but I was trying to see if I understood the sentence I was quoting.

Sorry... That was my bad. Using incorrect nomenclature. Hasn't really come up before; common shorthand, but technically incorrect.

Rather than LL, we should instead use something like "First Test" ("FT"), which might be an LL or (better) a PRP. DC is a similar meta term.

[kriesel]

Originally Posted by chalsall

Sorry... That was my bad. Using incorrect nomenclature. Hasn't really come up before; common shorthand, but technically incorrect.

Rather than LL, we should instead use something like "First Test" ("FT"), which might be an LL or (better) a PRP. DC is a similar meta term.

Maybe FC. More distinct from TF or fft, harder as a typo to get there.

FC or 1C, DC, TC, 4C & 5C if we're really unlucky.

[chalsall]

Originally Posted by kriesel

Maybe FC. More distinct from TF or fft, harder as a typo to get there.

Yeah, I like it. Symmetrical with DC.

[EugenioBruno]

Something interesting seemed to happen. I enabled in my BIOS "eco mode" for my 3700X in order to run my fan slowly and keep low temps with the stock cooler (doesn't even reach 70C now).

I clearly remember ms/iter on the current exponent to be about 2.1 to 2.2 before enabling eco mode, on stock settings.

But now, with a way lower clock of ~3300MHz vs ~4200MHz on all cores - ms/iter is consistently below 2, going all the way down to 1.9.

I really don't get it. It wasn't thermal throttling before, and is now limited to 60W total (35W reported for "CPU power").
Is there a reasonable explanation for this? If it doesn't make sense to you folks either, I might try digging deeper and doing benchmarks in both default and eco modes, though that's a bit of a hassle...

PS: is it ok if I occasionally use this thread to ask these kind of "dumb questions"? Should be tidier and not clutter the forum.

[LaurV]

Originally Posted by EugenioBruno

Is my interpretation of that sentence correct: "the people doing LL are going fast, so we're starting to fall behind in TFs that might avoid those LL checks from being done"?

Yes, except that "avoid" is "delay". If you get a LL/PRP assignment which is not TF-ed enough, you have two options, either do TF to optimum level by yourself, or proceed with LL/PRP ignoring the fapt that TF was not properly done. Both cases, on long term, will result in delays, compared with the case when somebody with specialized hardware (like me) makes the TF. In the first case, my hardware ca do TF faster than yours, and in the second case, you may work weeks to LL/PRP one exponent for which a factor could have been found much faster.

This is confusing to me. What is a DC wavefront in relation to TFs? If my understanding is correct, TFs are done *before* any LL (or DC) test is done. I don't unrestand, what do TFs have to do at all with DCs?

Here you forget hardware progress and Moore's Law. Imagine we do TF for 45M range to 68 bits, because that was optimum at that time, with the CPU, when FC front was at 45M and DC front was much behind (say 37M). Meantime, 10 years passed, and we are at 65M first test front, and 45M DC front, but some clever guy invented a toy called GPU which can TF about 200 times faster. Beside of raising the front-line TF for 65M from former 70 bits to 72 bits (that's where the "gpu_to_72" came), we also can see that we could clear exponents faster at DC front, if we first TF them to 70 (from 68). But this lasts as long as we still have to clear exponents between 45M and 65M (because over 65M already are benefiting from the GPUs). That's the idea. Take all numbers within this paragraph with a grain of salt (they are just for illustrative purpose, but fit with right numbers, this is how the things were).

[EugenioBruno]

Extremely clear answer, thanks.

[EugenioBruno]

Dang, I was looking forward to Cat 0, but looks like this disqualifies me, right? Or maybe if the triple check comes back agreeing with mine, I'm not disqualified?

https://www.mersenne.org/report_expo...0434247&full=1

[Uncwilly]

Originally Posted by EugenioBruno

Dang, I was looking forward to Cat 0, but looks like this disqualifies me, right? Or maybe if the triple check comes back agreeing with mine, I'm not disqualified?

https://www.mersenne.org/report_expo...0434247&full=1

If the TC agrees with you, you are good. If it doesn't, continue to run DC's. It may have just been a random cosmic ray or other transient thing.

[EugenioBruno]

Yay! Won the coin flip. TC agrees!

https://www.mersenne.org/report_expo...0434247&full=1