When will GIMPS's first prime...

[NBtarheel_33]

Originally Posted by Christenson

We have < 100K participants, so that's only 3.2TB...assuming ALL of us abandoned an exponent mid-way, which isn't going to happen....

3.2TB (or double that, for a hot backup) isn't out of reach of Primenet, if P95 and Scott ask for the donations -- look what MET did to the forum budget, and I think you'd only need about $200, not $500. But I'd start out at M(100M), not M(332M).
[So says the man that's working on billion digit primes. P95? Scott?]

I'd say do it for every exponent out there (...OK, maybe above 50M). I have been mulling this idea over a lot recently, and yes, with GIMPS about to enter its largest gap between primes, and the assignments getting longer and longer, it is something that is definitely worthwhile to be thinking about.

I would also like to go one further, and personally volunteer time and bandwidth to help this get off the ground if it is at all feasible. I can see GIMPS participants eventually exchanging partially completed assignments, and even receiving partial credit for their work (and partial credit in the event of a Mersenne prime discovery). It would be a new era of collaboration for the project.

[davieddy]

Originally Posted by Brain

Prime95 save file size is about 6.5MB for 3M exponent. Maybe already compressed?

??

The residue for a 3M exponent needs 375 KB.
What am I missing?

David

[Christenson]

Originally Posted by davieddy

??

The residue for a 3M exponent needs 375 KB.
What am I missing?

David

Brain is using CudaLucas....which is doing something less than efficient.

Let's do 300M-sized exponents....I need a 75M file, assuming the hex form gets stored as text, which isn't terribly efficient, but is reasonably robust.

100K CPUs * 75M/exponent = 7500G = 7.5TB...definitely in reach.

[retina]

Originally Posted by aketilander

... lets say for every 25.000.000 iteration when this region (above 332.000.000) ...

That would take me 2.82 years to reach the first check point of 25M iterations. Perhaps it would be better to state your save point as a time period instead?

Also, with all this saving intermediate residues and sharing the work remember that the server has to keep track of all the different contributors if you want to properly assign credit for everyone.

Plus, I find it unlikely that you would ever get a valid result unless everyone in the chain has really good hardware that computes everything without errors. Would you be happy to find that you contributed to an invalid result because someone before you, and/or after you, had some lousy hardware and corrupted it for everyone else?

[davieddy]

Originally Posted by Christenson

Brain is using CudaLucas

Religious Knowledge was not my favourite subject.
But at least I went to Sunday Skool, where I was initiated into
several sacred rites.

David

[davieddy]

Originally Posted by retina

I find it unlikely that you would ever get a valid result unless everyone in the chain has really good hardware that computes everything without errors. Would you be happy to find that you contributed to an invalid result because someone before you, and/or after you, had some lousy hardware and corrupted it for everyone else?

Barring Overclocking/Stress testing etc I would be as happy as a pig in shit.

David

[xilman]

Originally Posted by Christenson

100K CPUs * 75M/exponent = 7500G = 7.5TB...definitely in reach.

The storage is dirt cheap, so that's clearly not a limitation. Uploading 7.5TB over the net might be a limitiation, if the upload has to take place in a fairly short time.


Paul

[davieddy]

Originally Posted by xilman

The storage is dirt cheap, so that's clearly not a limitation. Uploading 7.5TB over the net might be a limitiation, if the upload has to take place in a fairly short time.


Paul

Don't call me me fairly short

David

(But I like it)

[NBtarheel_33]

Originally Posted by davieddy

??

The residue for a 3M exponent needs 375 KB.
What am I missing?

David

Yeah, I don't know what they are talking about either. Not sure why we would be doing tests on 3M exponents, let alone needing to save their intermediate residues. And P-1 on such an exponent is generally a pet project of the user doing such, and combined with the short nature of such assignments, is likely to result in very few, if any, partial completions.

Figure that an LL residue is calculated (mod 2^p-1). That means that the value stored in the LL save file is, at most, 2^p-2 in magnitude. That requires, what, p bits? So there are p/8 bytes, and p/(8*1048576) MB at most in a typical LL save file. For p = 55 million, that is a save file of 6.56MB. For p = 335 million, that is a save file of just under 40 MB. The latter is a bit of a stretch (but not impossible) to upload, but the former is no bigger than the size of e-mail attachments that I send out on a regular basis.

[NBtarheel_33]

Originally Posted by retina

That would take me 2.82 years to reach the first check point of 25M iterations. Perhaps it would be better to state your save point as a time period instead?

I would recommend saving residues no less than every five million iterations, and perhaps giving the user the choice to upload more frequently (e.g. every one million iterations). The user should also be able to upload a residue on demand, or whenever stopping work and returning an exponent to the assignment pool.

Originally Posted by retina

Also, with all this saving intermediate residues and sharing the work remember that the server has to keep track of all the different contributors if you want to properly assign credit for everyone.

This really is no different than the way PrimeNet works now. Just replace "completed LL assignment" with "completed block of an LL assignment". Since the inauguration of v5, I can have a look-see and tell you who was the first person to TF my exponent to 64, who P-1'ed it, who checked it first, etc. etc. Adding lines for "xxx completed iterations 0-10M" or "xxx completed iterations 95M-96.3M", etc. should therefore be no serious imposition on the server.

Plus, I find it unlikely that you would ever get a valid result unless everyone in the chain has really good hardware that computes everything without errors. Would you be happy to find that you contributed to an invalid result because someone before you, and/or after you, had some lousy hardware and corrupted it for everyone else?

Use the Reliability/Confidence system that is in place now. Ostensibly, we want an LL assignment to be completed in as few chunks, by as few different users as possible (very similar to how we treat "preferred" milestone-blocking exponents now). Minimize errors/delays by only allowing preferred users with proven hardware to work on partially completed tests. Also, with each intermediate result, upload the running error tally. If the error tally has a good chance of being harmful to the result, either throw out and re-run that portion of the test, or re-run the bad portion of the test - if it matches, you're on the way to a double check; if not, a triple check will be required...but only of the part in question!

Basically, the whole GIMPS paradigm would shift from viewing a "workunit" as an entire LL assignment to viewing a workunit as a *portion* of an entire LL assignment (and for most users, portion might well mean 100%). This is how the BOINC Mersenne@Home project is running, BTW.

[Brian-E]

Could saving intermediate residues potentially cause an issue with less certain integrity of double-checking? While the PrimeNet server could and should keep the intermediate residues non-accessible to general users, the very existence of the extra information might lead to questions about whether people were still somehow getting access to it and thereby fraudulently performing a double-check from a point somewhere during the LL test (like towards the end) instead of starting at the beginning.