Is LMH > 100M still alive?

TheMawn · 2014-02-04, 04:50

Good evening, folks.

I'm interested in putting a small amount of my resources aside for a pair of exponents in the 332.8M range. You could think of them as "lucky" numbers. They're actually each constructed from a number I see and use every day and conveniently appear in the 100M digits area. Every once in a while, the superstition inside me needs to be let out in a controlled, entertaining and lucrative way. Not bloody likely...

Anyhow, the two numbers themselves are factored to 2⁷² with no factors yet, but currently assigned under "GPU Trial Factoring" with no progress in ten months, so I take it they belong to GPU72? If this is the case, can I just PM Chris or someone to hand them over to me while I do my thing?

What is the ideal TF'ing depth for something in that range? I can't remember where that graph is (or if it works).

Can Prime95 do P-1 that high? If I were to give the program 12 GB or so to work with, what bounds should I give it to maximize the search area?

If I ever took it into my head to try an LL-test, is there a way to save checkpoints instead of overwriting them so I can run two side-by-side and check that they match every 24 hours or so? Would two matching residues by the same computer done at the same time count as a double-check?

For the record, I'll probably just TF to something reasonable and do the P-1 and give up. I don't see myself bothering with a 400-day LL test.

LaurV · 2014-02-04, 05:12

You can directly take them from the "get assignments" page of the GPU72, playing with the limits and the bit depth, or taking a small range and unreserving the other (not recommended, as the gpu72 spider will "alter" your credit if you unreserve work), or you can talk to Chris by PM.

"The ideal TF'ing depth for something in that range" depends on your card. It can be at least 81-82 bits (for a good card as Titan) but it can go as high as 85-86 bits, for a gtx570 (which is same fast to TF but slower to LL, you have to consider the fact that one LL can take 8 months, one year, or so, so spending few more days to TF, can be a good investment...).

retina · 2014-02-04, 05:25

Quote:

Originally Posted by TheMawn

Would two matching residues by the same computer done at the same time count as a double-check?

No. But if you don't have an ECC capable machine then this is a good way to increase your chances of a getting a good LL result.

LaurV · 2014-02-04, 05:37

Quote:

Originally Posted by retina

No. But if you don't have an ECC capable machine then this is a good way to increase your chances of a getting a good LL result.

Yes if they come both from P95, with different shifts. For example one R720 server (dual CPU, 16 physical cores machines) as chalsall has, could use 8 cores to do one LL and another 8 cores to do the other LL, as independent assignments (different shifts). They will both "pass" the primenet filter (i.e. counting as LL+DC), and the user can check the residues on the way (to save precious time by restarting from a previous checkpoint, in case the residues do not match, without waiting till the LL finishes). In this case, turning ECC off should give considerable speedup.

retina · 2014-02-04, 05:45

Quote:

Originally Posted by LaurV

Yes if they come both from P95, with different shifts. For example one R720 server (dual CPU, 16 physical cores machines) as chalsall has, could use 8 cores to do one LL and another 8 cores to do the other LL, as independent assignments (different shifts). They will both "pass" the primenet filter (i.e. counting as LL+DC), and the user can check the residues on the way (to save precious time by restarting from a previous checkpoint, in case the residues do not match, without waiting till the LL finishes). In this case, turning ECC off should give considerable speedup.

Okay, forgive me if I posted incorrect info. But this still has the possibility of the user faking the result so I can't see how this solves that.

No, I am not saying the posters here are faking results, just that primenet should be programmed to ignore DCs from the same user.

LaurV · 2014-02-04, 05:48

Sure, such test will be frown about, from the most of the community (me inclusive!), and considered "unreliable" till a triple check is done, but this does not seems it is not possible. I use do DC and TC my old work ([edit: and I am a "credit whore" as someone said some time ago]), but this does not mean that I am a cheater. Everybody is considered honest till proved otherwise. ~~Why the big scream font?~~ (sorry, you corrected the size)

retina · 2014-02-04, 05:51

Quote:

Originally Posted by LaurV

Why the big scream font?

Sorry, it was a typo value of 9 instead of 1. I corrected it immediately but it seems you were faster than me to see it.

philmoore · 2014-02-04, 05:56

Quote:

Originally Posted by LaurV

Sure, such test will be frown about, from the most of the community (me inclusive!), and considered "unreliable" till a triple check is done, but this does not seems it is not possible. I use do DC and TC my old work, this does not mean that I am a thief. Everybody is considered honest till proved otherwise. Why the big scream font?

Seems like such a result could be marked as needing a "low priority" triple check, not really warranted until a milestone is close.

philmoore · 2014-02-04, 06:06

It seems to me that this type of computation could become the wave of the future, where a simultaneous double-check with checkpoints becomes the only reasonable way to guarantee that the computation is accurate. In such a case, it seems like a waste of effort to require that the triple-check also be done in duplicate, but if periodic 64-bit residues are saved for later comparison, then the eventual triple-checker could use these to be check that their computation is on-track.

retina · 2014-02-04, 06:18

Quote:

Originally Posted by philmoore

It seems to me that this type of computation could become the wave of the future, where a simultaneous double-check with checkpoints becomes the only reasonable way to guarantee that the computation is accurate. In such a case, it seems like a waste of effort to require that the triple-check also be done in duplicate, but if periodic 64-bit residues are saved for later comparison, then the eventual triple-checker could use these to be check that their computation is on-track.

You may be right here. But perhaps better to call the first test something like LL+AC (LL + accuracy check) and then then next test as DC (or VC (verification check)).

I don't know where you intended the partial residues to be stored. On the server? And then compared when the VCer posts partial residue updates during the run?

Uncwilly · 2014-02-04, 07:29

Quote:

Originally Posted by TheMawn

I'm interested in putting a small amount of my resources aside for a pair of exponents in the 332.8M range.
.....
Anyhow, the two numbers themselves are factored to 2⁷² with no factors yet, but currently assigned under "GPU Trial Factoring" with no progress in ten months, so I take it they belong to GPU72?

What you have been told above is correct. Get them as assignments from GPU72. I just picked up some 72->73's today and they were in the 332.68 range.

2014-02-04, 04:50	#1
TheMawn May 2013 East. Always East. 11×157 Posts	Is LMH > 100M still alive? Good evening, folks. I'm interested in putting a small amount of my resources aside for a pair of exponents in the 332.8M range. You could think of them as "lucky" numbers. They're actually each constructed from a number I see and use every day and conveniently appear in the 100M digits area. Every once in a while, the superstition inside me needs to be let out in a controlled, entertaining and lucrative way. Not bloody likely... Anyhow, the two numbers themselves are factored to 2⁷² with no factors yet, but currently assigned under "GPU Trial Factoring" with no progress in ten months, so I take it they belong to GPU72? If this is the case, can I just PM Chris or someone to hand them over to me while I do my thing? What is the ideal TF'ing depth for something in that range? I can't remember where that graph is (or if it works). Can Prime95 do P-1 that high? If I were to give the program 12 GB or so to work with, what bounds should I give it to maximize the search area? If I ever took it into my head to try an LL-test, is there a way to save checkpoints instead of overwriting them so I can run two side-by-side and check that they match every 24 hours or so? Would two matching residues by the same computer done at the same time count as a double-check? For the record, I'll probably just TF to something reasonable and do the P-1 and give up. I don't see myself bothering with a 400-day LL test.

2014-02-04, 05:12	#2
LaurV Romulan Interpreter Jun 2011 Thailand 5²×7×53 Posts	You can directly take them from the "get assignments" page of the GPU72, playing with the limits and the bit depth, or taking a small range and unreserving the other (not recommended, as the gpu72 spider will "alter" your credit if you unreserve work), or you can talk to Chris by PM. "The ideal TF'ing depth for something in that range" depends on your card. It can be at least 81-82 bits (for a good card as Titan) but it can go as high as 85-86 bits, for a gtx570 (which is same fast to TF but slower to LL, you have to consider the fact that one LL can take 8 months, one year, or so, so spending few more days to TF, can be a good investment...). Last fiddled with by LaurV on 2014-02-04 at 05:21

2014-02-04, 05:48	#6
LaurV Romulan Interpreter Jun 2011 Thailand 243B₁₆ Posts	Sure, such test will be frown about, from the most of the community (me inclusive!), and considered "unreliable" till a triple check is done, but this does not seems it is not possible. I use do DC and TC my old work ([edit: and I am a "credit whore" as someone said some time ago]), but this does not mean that I am a cheater. Everybody is considered honest till proved otherwise. ~~Why the big scream font?~~ (sorry, you corrected the size) Last fiddled with by LaurV on 2014-02-04 at 05:55

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
To 100M to 75 Bits	petrw1	GPU to 72	6	2017-04-17 04:03
100m p-1 and tf	aurashift	Software	18	2016-04-14 13:48
Old pentium bug still alive?	ATH	Soap Box	8	2010-04-14 00:48
Anyone working in 79.3M - 100M ??	markr	Lone Mersenne Hunters	21	2008-12-21 16:02
100M madness	stars10250	Hardware	8	2008-10-02 15:21

2014-02-04, 06:06	#9
philmoore "Phil" Sep 2002 Tracktown, U.S.A. 2·13·43 Posts	It seems to me that this type of computation could become the wave of the future, where a simultaneous double-check with checkpoints becomes the only reasonable way to guarantee that the computation is accurate. In such a case, it seems like a waste of effort to require that the triple-check also be done in duplicate, but if periodic 64-bit residues are saved for later comparison, then the eventual triple-checker could use these to be check that their computation is on-track.