[QUOTE=2M215856352p1;539414]Have you received my PM? I am not very sure whether I did that correctly.[/QUOTE]

Yes. And replied. Please reply to that, and I'll be able to fix you up. :smile:

[QUOTE=Chuck;539418]Don't know if this is of any interest, or just a transient problem. This is from a Colab CPU only notebook. ...Evidently a transient problem, the next hourly submission was successful.[/QUOTE]

Interesting. Thanks for reporting that.

This means there was a communications error between the mprime client in the instance and Primenet (through the GPU72 proxy).

I'll take a look at the logs, and see if the client actually reached the proxy or not. But, regardless, the INI file should lower that retry period setting.

P. S. BTW, thanks to everyone who's reporting the timestamps with their "hmmm..." observations. It helps debugging immensely. Geeks really appreciate timestamps. NTP'ed UTC idea! :smile:

Speaking of optimal TF; what % do you guesstimate the current 77 bit work to be "more efficient" (I think the metric is time saved?) than the 73 work the primenet gives out?

Depending on the answer I might (or might not, or in different proportions) also do a bit of those, since they're very quick and I get more results per day - but not if the efficiency is way lower.

Based upon the First Time Check being done on a CPU and the TF work on a GPU, taking the factoring to 77 makes sense. The GPU's are saving the CPU's several percent of work (~4-5.3), above and beyond what is saved by taking everything to 73 bits. That is, ~5% fewer exponents need to get tested, because the GPU's have found a factor.

CPU's doing First time tests (PRP being preferred) or P-1 testing makes the most sense for them. Also, since there are many more of them doing tests, it makes the most sense at the moment to throw every available GPU at TF.

[QUOTE=EugenioBruno;539532].. work to be "more efficient" (I think the metric is time saved?)[/QUOTE]The most "efficient" work in terms of time saved is always the highest exponent and lowest bit depth.

To quote an extreme example, the third-largest exponent I track is [url=https://www.mersenne.ca/exponent/9999999929]M9,999,999,929[/url] and it has a ~40-bit factor. Finding this trivial factor took about 0.0000000000009 GHz-days of effort and saves 275,833 GHz-days of effort to do a single PRP/LL test (double that if you want double-checks, not to mention another 1000 GHd or so for P-1). 600-quadrillion-to-one efficiency, can't beat it. :smile:

At the lower bit depths, e.g. up to what PrimeNet hands out and a few bits above that there is no question but that it all needs to be done. The [I]only[/I] question is, based on the TF resources available vs primality-testing progress is what the final TF bitlevel should be. Right now that question hovers around should it be PrimeNet+4 or PrimeNet+5, and the answer varies according to how far ahead of the primality-testing wavefront the TF effort is and how much TF power is available. A few posts back I believe Chris said we have about a 2-month lead right now and it's shrinking, so we'll likely need to cut back to +4.

See this graph for an illustration: [url]https://mersenne.ca/graphs/factor_bits_1000M/[/url]
The pink curve is PrimeNet TF target, blue is PrimeNet+3, palegreen is PrimeNet+5.
The goal is to get the actual TF (black) up to [I]at least[/I] +3, but really should be +4 and (if we can manage it) +5.

[QUOTE=James Heinrich;539537]A few posts back I believe Chris said we have about a 2-month lead right now and it's shrinking, so we'll likely need to cut back to +4.[/QUOTE]

Yup.

Approximately 700 candidates are FC'ed each day at the moment. We're only averaging ~380 candidates to 77 bits per day over the last month. We do have ~50,000 candidates already TF'ed optionally as a buffer, but we are falling behind.

Part of my motivation for investing the time in the whole Colab thing was to get it sane and scalable. Now we work on getting the concurrent instance count up (and not just in Colab...).

For anyone who has a Gmail account and hasn't tried the Notebook thing, I would encourage you to give it a go. Pretty easy! :smile:

[QUOTE=James Heinrich;539537]The most "efficient" work in terms of time saved is always the highest exponent and lowest bit depth.

To quote an extreme example, the third-largest exponent I track is [URL="https://www.mersenne.ca/exponent/9999999929"]M9,999,999,929[/URL] and it has a ~40-bit factor. Finding this trivial factor took about 0.0000000000009 GHz-days of effort and saves 275,833 GHz-days of effort to do a single PRP/LL test (double that if you want double-checks, not to mention another 1000 GHd or so for P-1). [/QUOTE]But that is irrelevant. And so, useless activity. No one in his right mind is going to attempt P-1 or primality testing on such a large exponent this decade or next or for much longer. I take occasional flak for doing TF or P-1 to proper levels at less than one tenth that exponent value, as a means of exploring the limits of the currently available software. There are reasons why Ernst discourages people from attempting billion-digit primality tests with Mlucas, and why George feels no need to extend prime95's capabilities beyond about p~10[SUP]9[/SUP]. Even Mihai's gpuowl does not (quite) reach the billion-digit range. There is no software to P-1 factor or primality test such large exponents.
Instead of scattered activity on numerous exponents that won't be reached by the wavefront for decades or centuries, those reinforcements are needed at the barricades (wavefront).
[QUOTE=chalsall;539540]Approximately 700 candidates are FC'ed each day at the moment. We're only averaging ~380 candidates to 77 bits per day over the last month. We do have ~50,000 candidates already TF'ed optionally as a buffer, but we are falling behind.[/QUOTE]So 50,000/(700-380) = 156 days; buffer depletion in about 5 months. At or before buffer depletion, drop terminal TF level to 76. (Which is what I'm running to now for production TF.) If TF to 77 is possible for ~380/day, to 76 would be possible for ~780/day.

[QUOTE=EugenioBruno;539532]Depending on the answer I might (or might not, or in different proportions) also do a bit of those, since they're very quick and I get more results per day - but not if the efficiency is way lower.[/QUOTE]

The short answer is: do whatever you enjoy doing! Every "bit" helps -- it all has to be done. And not everyone has a compute farm in their basement!

Heck, I myself am down to only running a single old GTX560 here in Bimshire, and that's mostly just for testing purposes. (I whine when Colab only gives me a K80 for free, until I remember that it's still twice as fast as my own kit.)

[QUOTE=kriesel;539544]So 50,000/(700-380) = 156 days; buffer depletion in about 5 months. At or before buffer depletion, drop terminal TF level to 76. (Which is what I'm running to now for production TF.) If TF to 77 is possible for ~380/day, to 76 would be possible for ~780/day.[/QUOTE]

That ~380/day was over the last month. We've been lower than that more recently (participation ebbs and flows).

And I'm prepared for the situation that we need to "drop" candidates early, although I don't want to. Working some angles on getting some additional firepower...

[QUOTE=kriesel;539544]But that is irrelevant. And so, useless activity.
Instead of scattered activity on numerous exponents that won't be reached by the wavefront for decades or centuries, those reinforcements are needed at the barricades (wavefront)[/QUOTE]It is germane to this discussion in that it provides a dramatic illustration to the posed question of how the "efficiency" scales towards large exponents and small factors.

That said, while I wouldn't call any factor-finding effort outright "useless" in and of itself, as it relates to GIMPS's mission of finding the Next Mersenne Prime then factoring large exponents is not useful. It will all [I]eventually[/I] need to be done, but that could be decades-to-centuries away depending on the exponent.

I have to admit I didn't really understand the argument fully, but tomorrow I will search for explanations, probabilities, arguments and so on, so I can understand without annoying you folks too much.

I'm not even sure if the qualitative gist I get - deeply TFing what's about to be FCd is better because it saves FCs and moves the wavefront faster; TFing exponents far ahead is worse because they wouldn't be tested anyway for a while, and hardware is going to evolve in the meantime - is roughly correct.