[QUOTE=airsquirrels;408421]...for practical purposes and until we advance the state of the theory there we can treat it as a truly random number between 1 and 2^p-2.[/QUOTE]
Correct. For this reason, the top 20 bits will be all-zeros once in a million iterations; is that good savings? Not at all.
[QUOTE=airsquirrels;408421]but there will be points in the sequence where the residue is much closer to 1[/QUOTE]
The top 64 bits will be zeros ...never (for practical purposes). And even that - is it 'much closer to 1'? No.

This data is also obviously incompressible (because it is truly random).

[QUOTE=Batalov;408423]Correct. For this reason, the top 20 bits will be all-zeros once in a million iterations; is that good savings? Not at all.

The top 64 bits will be zeros ...never (for practical purposes). And even that - is it 'much closer to 1'? No.

This data is also obviously incompressible (because it is truly random).[/QUOTE]

I will concede to that irrefutable logic, I am far too used to dealing with much smaller residues (2048 bit moduli). It would still be possible to have frequent hash-based validity checks without much storage/bandwidth cost and less frequent full residue check points for resuming.

[QUOTE=airsquirrels;408411]I imagine it would also be easier to quickly flag and quarantine bad actors in that case[/QUOTE]

Just so you know, Aaron (AKA madpoo) has been working on this problem space. Please see [URL="http://mersenneforum.org/showthread.php?t=20372"]this thread[/URL] for details.

At the end of the day, it probably makes more sense for trusted users / machines to double / triple check candidates who were initially LL'ed by suspect machines than try to do a major overall off the client and server code-base.

Separately, as George mentioned, an untrusted machine might taint the results of a trusted machine.

Further, there's the whole question about "credit": who gets to claim (or at least be named in) the find? The machine/user who did the last iterations, the machine/user who did the majority, or everyone who did a few? (Hint: if the latter was the case, some would do a few iterations on many candidates!)

Dear airsquirrels,

Your machines are well appreciated on sieving for NFS@Home at [url]http://escatter11.fullerton.edu/nfs/[/url].

Kind Regards,

Carlos

[QUOTE=Batalov;408309]Something like the Lonestar cluster (I think Lonestar has by now been retired; there are other resources at XSEDE.)

Cf. [url]https://eprint.iacr.org/2012/444.pdf[/url] (Section 5).
This job is only slightly larger. GNFS-218 is like a SNFS-335 (which is 1115 bits < 1285 so GNFS is clearly appropriate; M1061 was a 1061-bit job)[/QUOTE]

That specifies the memory usage for the matrix to be 40GB. The system mentioned above has 128GB. It also mentions 35 CPU years for the linear algebra. That is presumably including the inefficiency that is gained by running more cores on multiple machines. I still would be surprised it the system mentioned above couldn't finish this job in less than a year.
As far as I am aware a lot of the reason a cluster is used is because people don't usually want to commit an expensive machine(that amount of memory isn't cheap) to one job for 6 months+.
As memory gets cheaper with DDR4 I imagine that larger jobs will be done on home pcs again.

[QUOTE=VBCurtis;408248]I second Henry's suggestion, as there are tasks to be done that require 32 or even 64GB RAM, a spec in short supply. There are tasks that require even more memory, but as he said those also take months to complete (and a partial solution is not easy to transfer to someone else, since "nobody" else has 128GB or more with which to finish it). NFS post-processing is nicely parallelized for your 16 cores, so you'd do these tasks at least twice as fast as those of us with mere 6-core i7s.

Within the mersenne project, GMP-ECM is indeed a potent use of massive memory. Madpoo is likely to have info for you about how many LL tests will nearly saturate your memory, while the rest of the cores can be spent on ECM. GMP-ECM uses massive memory but is massively more efficient at finding factors; again, Madpoo experimented with it, and can give you some info if you don't find his thread about ECM.

LL testing is fine for any Intel-based machine, but your server has unique capabilities due to memory capacity, whilst the CPU cycles for LL are no more potent than a similar number of cores spread over simple desktops.[/QUOTE]

I did testing to see how best I could use my dual chip boxes for LL testing, and "aurashift" did some as well on his systems with up to 18 cores per CPU (I think). Mine were only 10-core chips.

See this thread for the gory details... I think it's where we discussed most of it:
[URL="http://www.mersenneforum.org/showthread.php?t=13185"]http://www.mersenneforum.org/showthread.php?t=13185[/URL]

In short, on a good Xeon chip you can continue to add all of the cores on one CPU (and even 1 core on the other CPU) with decreasing gains in LL performance, but still slightly faster with each core. It's only when you start adding additional cores on the other CPU (past the first one) where performance actually starts to get worse, as you flood the QPI channel.

That thread was specifically about larger exponents, but the same holds true for smaller ones as well. It wasn't until I got down to some really tiny exponents (like sub 5M) before I noticed that cores were waiting on memory, which was weird. If I'm testing a 50M exponent, all of the cores would be 100%, but on a 5M exponent, the first core is 100% and the rest might be between 70-90% utilized. Oh well... they finish really fast at any rate. :smile:

For GMP-ECM doing ECM work, you can get one-per-core running and if you have sufficient free RAM, set the parameters of each instance to use as much as it needs. Depending on the exponent in question you may be looking at a pretty large chunk when it's doing stage 2. I was running curves on small exponents like M1277 and some pretty large bounds... stage 2 could take 25-30 GB per instance (I think that was k=2) so obviously if you wanted to do that on 32 cores, you'd want a LOT of RAM. :) But doing ECM on "normal" exponents using "normal" bounds wouldn't use as much as that. I just had this thing about 1277 since it's the lowest one without a known factor yet.

Some other thread has my gory details about getting GMP-ECM working well with having Prime95 doing stage 1 and feeding that to GMP-ECM. It's not the easiest process but if that's something you're interested in, then it'll work. Depending on your OS (Windows or Linux), the actual process of launching multiple gmp-ecm instances and setting affinity for each one would vary. I think I went into enough detail on how I did it with Windows to get you started, should you go down that path.

For now I'm still devoting resources to triple-checking exponents where the first two didn't match, so I'm not currently doing any ECM work... I may go back to it at some point.

[QUOTE=chalsall;408391]...One fear I've always had in the back of my mind is when the next MP is found and announced -- there is always a surge of new users who don't appreciate just how much work is involved. The last time this happened we had to release for LL'ing candidates not yet optimally TF'ed. Fortunately (?) most of these were never actually completed and were subsequently TF'ed appropriately.[/QUOTE]

Personally I think I'd force new accounts to do one or two double-checks first before they could do any first-time checks.
[LIST=1][*]DC is way behind first time, so the help would be appreciated[*]they're unproven[*]bad machines from newcomers might not be discovered as bad for years (I'm seeing that now, for machines that were "alive" 3+ years ago and we're just now discovering that nearly all of their tests were bad)[/LIST]
Of course people who climb aboard the GIMPS train after a new discovery are probably doing so in hopes of finding another new one, as if another one would be found in the next few days... so DC work on their first assignment or two would be a buzz kill.

[QUOTE=airsquirrels;408409]Hmm, well one problem at a time I suppose. It would also add a pretty significant benefit in that double checks could fail as soon as they don't match a checkpoint instead of needing a complete run. Last I heard a significant percentage still fail, so that's a not so insignificant amount of resources. Ideally that would lead to less DC backlog and also the ability for those 'slower' computers to contribute to the LL by advancing exponents the same way we do with TF, one iteration level at a time.

I know I'm new here so I don't want to overreach, but I'm just as happy to contribute code and storage when the time comes.[/QUOTE]

It's an interesting point... my current "best guess" based in historical data is that 3-4% of first time tests are bad.

Primenet saves the final residue (or the last 64 bits of it anyway). Maybe George or someone could see some benefit in saving the partial residue at the 50% point as well, so that a double-checker would have some idea at the halfway point of whether or not they match that first check.

I'm not entirely sure if that would be useful or not... it will either match by that point or not. If it matches, it could still be different at the end, but you'd complete the test to know. If it mismatches, the first one may be the bad one, so you'd still need to complete the test to know. Either way you would do the full test but maybe there'd be some interest in knowing way ahead of time if a mismatch had occurred.

Unfortunately there's probably zero way to know at what point a bad result went off the rails... it could have been in the first hundred iterations, or it could have been the final one. So I'm just arbitrarily saying "50%".

Maybe the rare people that save their residues and do simultaneous runs of the same work and have had mismatches occur could shed some light on "at what % did the results diverge?"

[QUOTE=Madpoo;408530]Personally I think I'd force new accounts to do one or two double-checks first before they could do any first-time checks.
[LIST=1][*]DC is way behind first time, so the help would be appreciated[*]they're unproven[*]bad machines from newcomers might not be discovered as bad for years (I'm seeing that now, for machines that were "alive" 3+ years ago and we're just now discovering that nearly all of their tests were bad)[/LIST]
[B]Of course people who climb aboard the GIMPS train after a new discovery are probably doing so in hopes of finding another new one, as if another one would be found in the next few days... so DC work on their first assignment or two would be a buzz kill.[/B][/QUOTE]

I imagine Davieddy rubbing his hands and muttering, "Fools! I told you so!" This, and related issues were always favorite hobby horses of his. :davieddy:

[QUOTE=kladner;408532]I imagine Davieddy rubbing his hands and muttering, "Fools! I told you so!" This, and related issues were always favorite hobby horses of his. :davieddy:[/QUOTE]
:ttu:
Richardson approves!

[QUOTE=Madpoo;408531]It's an interesting point... my current "best guess" based in historical data is that 3-4% of first time tests are bad.

Primenet saves the final residue (or the last 64 bits of it anyway). Maybe George or someone could see some benefit in saving the partial residue at the 50% point as well, so that a double-checker would have some idea at the halfway point of whether or not they match that first check.

I'm not entirely sure if that would be useful or not... it will either match by that point or not. If it matches, it could still be different at the end, but you'd complete the test to know. If it mismatches, the first one may be the bad one, so you'd still need to complete the test to know. Either way you would do the full test but maybe there'd be some interest in knowing way ahead of time if a mismatch had occurred.

Unfortunately there's probably zero way to know at what point a bad result went off the rails... it could have been in the first hundred iterations, or it could have been the final one. So I'm just arbitrarily saying "50%".

Maybe the rare people that save their residues and do simultaneous runs of the same work and have had mismatches occur could shed some light on "at what % did the results diverge?"[/QUOTE]

My thought with checkpoints would be that you don't need to complete or redo the entire test. If there are a few checkpoints at the point the double checking machine discovers a mismatch it would simply revert to the last checkpoint that matched, change the shift values around, and proceed to the mismatched checkpoint. The rest of that much smaller check would tell you with pretty good certainty if the original was wrong or if your machine is inconsistent with itself.

Having DC so far behind is the real problem I am looking at here, either lots of resources are spent on low chance of learning anything new or we spend very little resources on double checks and a mistake somewhere along the line 'misses' an important Mersenne. What is the current stat for how many double checks are started and never completed? I'm not sure credit would be as important for DC and the whole project would benefit from all the work of churners who abandon the current low granularity work units.