mersenneforum.org - Newer milestone thread

mersenneforum.org (https://www.mersenneforum.org/index.php)

- Data (https://www.mersenneforum.org/forumdisplay.php?f=21)

- - Newer milestone thread (https://www.mersenneforum.org/showthread.php?t=13871)

[QUOTE=Prime95;307526]Sorry to disappoint. There is no behind-the-scenes cross-checking. Brian Beesley used to do triple-checking if the 2 LL tests were done by the same user. However, he stopped at somewhere below M2000000.[/QUOTE]

Found 5 under 1M but they are locked in primenet so can't register tripple checks:

[CODE][Mon Aug 13 23:13:01 2012]
Iteration 250000 / 573031
Iteration 500000 / 573031
UID: athath/quad, M573031 is not prime. Res64: 676EAF0D755C0636. We4: A977E8DE,445254,00000000
[Mon Aug 13 23:25:36 2012]
Iteration 250000 / 636043
Iteration 500000 / 636043
UID: athath/quad, M636043 is not prime. Res64: FB90CCA2BE750C44. We4: CCA4AABA,204522,00000000
[Tue Aug 14 00:07:19 2012]
Iteration 250000 / 959969
Iteration 500000 / 959969
Iteration 750000 / 959969
UID: athath/quad, M959969 is not prime. Res64: A2BD93B43EB60304. We4: 6355E209,834202,00000000
[Tue Aug 14 00:13:42 2012]
Iteration 250000 / 991901
Iteration 500000 / 991901
Iteration 750000 / 991901
UID: athath/quad, M991901 is not prime. Res64: 062045C476E4FAAE. We4: 82FA8CC0,877513,00000000
Iteration 250000 / 991909
[Tue Aug 14 00:19:38 2012]
Iteration 500000 / 991909
Iteration 750000 / 991909
UID: athath/quad, M991909 is not prime. Res64: 5C9F4601463B39B1. We4: 5D194C32,451975,00000000
[/CODE]

[QUOTE=ATH;307868]Found 5 under 1M but they are locked in primenet so can't register tripple checks:
[/quote]

I added them for you

[url=http://www.mersenne.org/report_exponent/?exp_lo=50520109&exp_hi=&B1=Get+status]M50520109[/url] should probably be triple-checked as well.

[QUOTE=ixfd64;307925][URL="http://www.mersenne.org/report_exponent/?exp_lo=50520109&exp_hi=&B1=Get+status"]M50520109[/URL] should probably be triple-checked as well.[/QUOTE]
This is "safe", I think it comes from two P95 runs with 2 different shifts. It is quite new, so it can't be fake, in spite of the same date, PrimeNet won't accept two p95 runs with the same shift.

[QUOTE=bcp19;307726]I've been tracking 24-26M assignments for some time, and the two you mention have the following stats:
xx,xxx,801 - 10.90% on 5/9, 11.00% on 8/12
xx,xxx,607 - 61.20% on 4/8, 61.20% on 5/7, reassigned on 5/9, no progress to date.[/QUOTE]

Let's go a little further, because frankly I find this a bit absurd.

[URL="http://www.mersenne.org/assignments/?exp_lo=24212801&exp_hi=&execm=1&extf=1&B1=Get+Assignments"]24212801[/URL] -- Assigned 440 days ago. Currently at 11.00%.

[URL="http://www.mersenne.org/assignments/?exp_lo=24364607&exp_hi=&execm=1&extf=1&B1=Get+Assignments"]24364607[/URL] -- Assigned 99 days ago. Currently at 0.00%

I know people [SUP](tm)[/SUP] who could complete these assignments in less than a day.

My point is, if the GIMPS community (including me) agrees that "poaching" is a bad thing, then Primenet should ensure that only those who will actually complete a "preferred" assignment in a reasonable amount of time is assigned the work. Otherwise poaching is going to happen.

And to identify the elephant in the room, the current Primenet heuristics only looks at the reliability of a client from the standpoint of good results, not timeliness, to be elidgeable for a "preferred" assignment.

[QUOTE=chalsall;307966]Let's go a little further, because frankly I find this a bit absurd.

[URL="http://www.mersenne.org/assignments/?exp_lo=24212801&exp_hi=&execm=1&extf=1&B1=Get+Assignments"]24212801[/URL] -- Assigned 440 days ago. Currently at 11.00%.

[URL="http://www.mersenne.org/assignments/?exp_lo=24364607&exp_hi=&execm=1&extf=1&B1=Get+Assignments"]24364607[/URL] -- Assigned 99 days ago. Currently at 0.00%

I know people [SUP](tm)[/SUP] who could complete these assignments in less than a day.

My point is, if the GIMPS community (including me) agrees that "poaching" is a bad thing, then Primenet should ensure that only those who will actually complete a "preferred" assignment in a reasonable amount of time is assigned the work. Otherwise poaching is going to happen.

And to identify the elephant in the room, the current Primenet heuristics only looks at the reliability of a client from the standpoint of good results, not timeliness, to be elidgeable for a "preferred" assignment.[/QUOTE]

There is much to be discussed openly, honestly, and constructively...

The main goal, I think, is to have GPU72 users do useful work, while treating all GIMPS users fairly and equitably. In my mind, advancing the tail is no more important now than it has been for the last 15 years. [Debate is welcome. George should have the final say. IMHO, one group, no matter how well-intentioned, should not unilaterally make a policy decision such as this.]

While my personal feelings don't quite rise to the level of "resentment", as someone else suggested, I do feel that permitting a bot to obtain the plum assignments is "unfair". In fairness, and in my opinion, those who have done the majority of the work to get GIMPS where it is today should be allowed the majority of the plum assignments, even if that means the tail won't catch up for years.

I seriously believe GPU72 should only claim a percentage of the newly released plum assignments in proportion to the amount of work GPU72 contributes. So, for example, if GPU72 clients put in 600 GHz Days of LL work, and Prime95 clients put in 14400 GHz Days of LL work, the GPU72 clients should be permitted to claim 4% of the next day's plum LL assignments. [A similar principle might apply to DC work, but I don't feel as strongly about that.] There is an unlimited amount of leading edge work (now standing at about the mid- to high-50M range). The more leading-edge work GPU72 clients perform, the more trailing edge (plum) work GPU72 clients will be permitted. I freely admit this proposal will limit the ability of the tail to "catch up" until and unless GPU72 recruits an much bigger army of volunteers. [A thousand more GPU72ers as dedicated as the first hundred would thrill everybody!]

Separately, we can discuss whether or not there is a problem with the Prime95 assignment rules.

In your second assignment, above (99 days old at 0%), I see that as relatively normal. With Prime95, you can ask for a queue of up to 90 days of work. Being 10% overdue on starting an assignment isn't a problem for me. And it's well within both the implicit time limits supported by the Prime95 program and the explicit time limits given on this Web site. It's also normal for the amount of CPU time donated to GIMPS to vary over the life of a computer. Perhaps the user was giving a high number of cycles to GIMPS over the winter, but has cut back during the hot summer. [Even some GPU72 users have stated they cut back when the temps warmed up.] So, 90 days of work, when assigned in early May might be 180 days of work in the dog days of August. Some leeway should be allowed.

The first assignment (small DC at 440 days) is a concern for me. If it has gone from 0 to 11% linearly over the last year, the assignment should be revoked. If it has gone from 0 to 11% over the last three weeks, I think the user might, in principle, be allowed to finish it, as it will be done within about 180 days. [However, if the Prime95 server can't track the *rate* at which a number is being worked, I wouldn't fault it for revoking this long-overdue assignment.]

Let me briefly mention the parms George recently proposed for new Prime95 / Manual assignments. I happen to have one assignment in the 331M range. It's on an alternate operating system that I don't run very often. It is over 6 months old and 4% done. Is it necessary to expire that assignment after 1 year? I think I was acting responsibly to choose an exponent that wouldn't hold up the works. I don't honestly know if I will ever finish it. If you expire my exponent, I won't finish it. But if you don't expire it, I have the opportunity to move the partially-completed assignment to a faster computer several years hence. (Many old-time Prime95 users have moved assignments from one computer to another when they upgraded.)

I also have no problem if the main GIMPS server tightens up the rules on allocating preferred assignments. (E.g., a queue length of 30 days or less, plus the existing rules.) But, if that isn't technologically feasible with the current main GIMPS server, I also don't have a problem if the preferred assignment rules remain the same. Prime95 users should be given ample notice to adjust their queue lengths, or whatever is necessary to allow them to continue to receive plum assignments.

[B]Other ways in which GPU72 might help:[/B] LaurV proposed performing a triple-check on assignments that are suspect in some way. [Such as being performed by the same user.] I think that's a great idea! As George stated earlier, it may be decades before an independent third party can verify the work done by GIMPS. But that caused me to wonder if, in fact, maybe the time is right to TC (triple-check) all exponents below a very small threshold (2M???). While I don't want to take significant time away from the main GIMPS effort, getting an independent test of the small exponents with a totally different piece of software is inevitable. Does CUDALucas fit the bill? [But see below.] Are there other ideas?

[B]Changes to CUDALucas to improve confidence:[/B] As it stands now, nothing prevents a user from faking CUDALucas results, provided they know the residue from a prior LL result (of their own) or from any prior LL/DC pair stored in the GIMPS server. Without getting into complex cryptographic protocols, a very simple change to CUDALucas would be to have it report a little bit more of the residue. Specifically, I would suggest reporting 7 random nibbles of the next-higher 8 bytes of the residue. [E.g., xx3xACxExB5xxx2xD45AC201BF9830E7.] I selected 7 of 16 nibbles, because it permits multiple CUDALucas-style reports without revealing the entire extended residue, while giving a high probability (>99.6%) that a pair of CUDALucas-style reports will have at least one common nibble. (These parameters may not be ideal.) If a user suddenly submits a thousand CUDALucas TC reports, his reports can be spot-checked to confirm their validity. If the main GIMPS server can't handle the extended residues, can GPU72 keep them??? [A technique permitting spot-checks was used on the DESCHALL project. The DESCHALL protocol required the client to return a value, that proved the calculation had been carried out, whenever a "half-match" was found. Statistically, a half-match was present in 1 in 2^32 keys tested. (The size of the keyspace was 2^56.) Any big user who was claiming to have tested large areas of the keyspace could be spot-checked, both by the statistics of how many half-matches they returned and whether or not the half-matches were valid. In practice, I verified *all* half-matches. No client was ever found to have cheated. And no big user reported a suspicious shortage of half-matches.]

[QUOTE=Dubslow;307833]That was Brian-E's point which I :tu:'d. He reminded us that George suggested only applying such rules to "preferred" exponents. Your example of 25.3M would qualify under the preferred or even your own definition of trailing edge. Edit: By your own rules, your 25.3M would be recycled.[/QUOTE]

Yes I realized that when I was writing. When this exponent was reserved it was at the leading edge. Now it is close to the trailing edge. That box though slow, still contributes. Now it is up to the community to decide if they don't want such contributions. A few thousand computers of this type, do add up in the long run.

Fried, scrambled, or ???

[QUOTE=chalsall;307966]
[URL="http://www.mersenne.org/assignments/?exp_lo=24364607&exp_hi=&execm=1&extf=1&B1=Get+Assignments"]24364607[/URL] -- Assigned 99 days ago. Currently at 0.00%
[/QUOTE]

Your egg should be done on Aug 23.

0% Says they just don't care and are putting "NO" effort into it, as opposed to the 11% exponent. If anyone beats me to it, that's fine, it is running on a Pent D 940 3.2GHz 24/7 background.

[QUOTE=garo;308039]Yes I realized that when I was writing. When this exponent was reserved it was at the leading edge. Now it is close to the trailing edge. That box though slow, still contributes. Now it is up to the community to decide if they don't want such contributions. A few thousand computers of this type, do add up in the long run.[/QUOTE]

I think that on pure CO2 grounds it would be wise to make an explicit point of rejecting such contributions. Getting a result for a gigajoule (two months on a 200W machine) is at most half as good as getting the same result for half a gigajoule.

I appreciate that, when you're making that kind of argument, you're open to the counter-argument that nobody should be running prime95 at all. And I think that's probably quite a reasonable counter-argument; the argument about wasted cycles made sense before the introduction of the C-state, but it's difficult to justify buying computers to run Prime95 on them. And I say that as a person who's done precisely that, and who runs 800W of computers 24/7 in quixotic pursuit of the equally useless aliquot sequence.

[QUOTE=fivemack;308046]I think that on pure CO2 grounds it would be wise to make an explicit point of rejecting such contributions. Getting a result for a gigajoule (two months on a 200W machine) is at most half as good as getting the same result for half a gigajoule.

I appreciate that, when you're making that kind of argument, you're open to the counter-argument that nobody should be running prime95 at all. And I think that's probably quite a reasonable counter-argument; the argument about wasted cycles made sense before the introduction of the C-state, but it's difficult to justify buying computers to run Prime95 on them. And I say that as a person who's done precisely that, and who runs 800W of computers 24/7 in quixotic pursuit of the equally useless aliquot sequence.[/QUOTE]
The self-deprecating nature of part of what you say, plus the implicit acknowledgement that the issue is not black-and-white, have not escaped me. (That's if I've understood you of course.)

But to be clear and up-front for the moment: if we're thinking on CO2 grounds, then we should be welcoming participants who run prime95/mprime in the background on a machine which they use for other things, and then turn off their machine when it is not in use. The software was designed to facilitate such background use, using cycles which would otherwise be wasted, after all.

And I have a hunch that slow-but-steady participants in the project are doing just that, in the main.