Suggestion: Alternate exponent distribution

[Knappo]

Hello folks,

today i've written a really bad test at the university and because my knowledge in some cases showed some "holes", I used the time to think about the current expo-distribution of GIMPS.

Currently a exponent is given out to LLing and some time after (months? years?) the exponent get's a doublechecking...

Now the way I thought of is a bit different... What about giving one exponent to two computers at the same time? The one who reports at first has done the first time and the second reporter did the doublechekcing in nearly the same time. With this way of distribution the checking would be slower but more acurate.

[Xyzzy]

I'd like to see an option for one LL and then one DC, or maybe a ratio... (I'm talking about on the same box!)

I like to have a box verified periodically just to be safe... I can do it manually, but it is a bit of work...

http://www.teamprimerib.com/rr1/bin/...er.php?u=Xyzzy

See how some of my boxes returned bad work? Had I not checked them, they'd probably still be returning bad work...

Or maybe the default should be a few DC, until the box returns a correct result? I suppose that would require some server-side programming, though...

Above all, I fear wasted cycles...

[ColdFury]

Sending out an exponent twice at the same time makes it easier to cheat the system.

By "time-shifting" the double check, it makes it highly unlikely two people can collude to fake results.

[cheesehead]

Originally Posted by Knappo

With this way of distribution the checking would be slower but more acurate.

It's really no slower (or faster) than the current system of assignment. Basically, there's a certain amount of (P90) CPU-years required to do the L-Ling of a given set of exponents, for both the first run and the doublecheck run. That total time requirement does not depend on whether both runs are near-simultaneous or are years apart.

(For those of you thinking, "What about improvements in program speed over time?" - That doesn't really matter if the improvement is in L-L speed, because that applies to both first and D-C runs. At any given time, GIMPS has a potential contribution of xxx CPU-years per day and the project's overall progress doesn't depend on how that's divided between first-time and D-C.

And don't quibble about differences in rate of adoption of new software versions between first-time and D-C systems! That's negligible.)

As for accuracy: no, again the assignment algorithm makes no significant difference.

Remember when considering whether a change in assignment method helps or hurts overall GIMPS throughput: If we shift the balance of computing power from one type of work to another, it slows down progress on the former by the same amount it speeds up the latter.

- - -

Besides, having a lag between first-time and D-C makes it easier for "slow" systems to contribute. (Not because of computer considerations, but because of psychological factors)

[Knappo]

The point I think about is that with the current system, the fast machines do the first LL and the slow machines do the doublechecking. Because of that the first time LLs are faster and ckeck more numbers than the doublecheckers. so there ist already a huge gap between both checks. And this gap will grow further...

[garo]

The gap had been growing for some time but it has finally started to narrow. The vast majority of Prime95/mprime users leave their exponent selection to default. Hence the preset limits chosen by George overwhelmingly decide what machine gets what. These limits have been revised for v24. So as more people download v24 more middling machines (900MHz-1200MHz) get doublechecks instead of LL tests. Moreover, Team_Prime_Rib which is ranked second in the project has recently moved a lot of their machines to Factoring instead of LL testing so this has also slowed the progress of LL testing somewhat.

Looking back at old summary files I see that at one time over 72000 first-time exponents were assigned and the number of doublechecks assigned at that time was a shade over 12000. These numbers have steadily improved and now the number of first-time LL tests assigned is around 57000 while DCs are at about 19000.

Hence the gap is now narrowing.

[Mystwalker]

For GIMPS, I'd say that a quick double-check is not really needed. Sure, it's good to find a prime, but there are no real differences between now and later.
For SoB, it would be a different story, of course, because a found prime eliminates all further tests for the corresponding k. While we're at it, the creators of SoB (or were it some active forum members? I don't remember...) approximated that with their current error rate, the probabilities-optimal situation would be when double-checks are at half the n value as first-time tests. The higher the error rate, the more time should be spend on double-checking, of course...

[cheesehead]

Originally Posted by Knappo

a huge gap between both checks.

So what?

Can you describe any actual harm to the project that's caused by the size of that gap? If not, why do you think it would cause any harm in the future?

Originally Posted by Knappo

And this gap will grow further...

As garo pointed out, the gap is not doomed to grow further. It can shrink, too.

Again, one needs to analyze the situation carefully. Just knowing that fast machines do one type of work and slow machines do another does not give us enough information to decide anything about the changes, size, or even the very existence of any gap between the ranges of exponents the two classes of machines are working on. More important, for instance, are a) the ratio of total CPU-years per day of work accomplished by the two classes of computers, and b) the ratio of CPU-years required per exponent in the two ranges. Other factors include the rates at which machines enter and leave the fast and slow categories, the boundary between "fast" and "slow", the extent to which the ranges of assignments in progress overlap between the fast and slow classes, and the distribution curves of assignments in progress [though that's really a subheading under b) above].

Originally Posted by Knappo

The point I think about is

Relax. :-)

GIMPS can take care of itself.

There are several adjustments that the folks in charge of the project can make. In fact, each of the four factors I listed in my "Other factors include ..." sentence above is partially or wholly adjustable by project administrators and participants.

[garo]

Originally Posted by cheesehead

So what?

Can you describe any actual harm to the project that's caused by the size of that gap? If not, why do you think it would cause any harm in the future?

Cheesehead, I agree with everything else you say, especially the part where you agree with me ;) But there is something to be said about milestones like "No more Mersenne primes to be found below 2^10M". George has stated in the past that first-time checking milestones are rather useless.

That said as a 4 year GIMPS participant I would totally agree that things tend to level out in the long-run. First-timers in GIMPS have been around twice as large as double-checks for all this time and George tweaks the limits as necessary once every year or two.

PS: As a private aside I am up to $265M. I am catching up to you in HSX!!

[lycorn]

I agree that the really important point is to get work done, be it LL or DC. In the end, both are needed to move forward.
But I can´t help insisting again on the benefits of having DCs assigned to new machines until they check in a good result:
- It would uncover defective machines sooner.
- It would increase the motivation of many folks, as the first results would take less time to appear.

My 2 cents...

[cheesehead]

Originally Posted by lycorn

But I can´t help insisting again on the benefits of having DCs assigned to new machines until they check in a good result:
- It would uncover defective machines sooner.
- It would increase the motivation of many folks, as the first results would take less time to appear.

Right. Different assignment algorithms can have different benefits -- just not because they directly speed up or slow down the overall project's progress.

For example, I almost wrote that using DCs to screen new machines can help progress by minimizing the fraction of assignments' work that will turn out bad. But then I realized that the "good" machines will just keep on churning out good results at the same pace either way, even in triple-checking the "bad" results (because eventually we need two matching "good" results no matter how many "bad" results there are for any given exponent!).

Now, if DC screening allows some "bad" machines to be fixed (e.g., upgrading cooling or memory) sooner than they would have been if they'd been assigned first-time LLs, then it's possible that that might allow them to join the ranks of "good" machines sooner and then start "good" contributions sooner. But that's an indirect speedup, not a direct one.