While the proposal to give extra credit is attractive it muddies the purity of the current GIMPS credit system. We finally have a system where credit is proportional to the amount of work done - up to processor equivalence - so I would be loath to give it up. Instead we should take the two steps that have been suggested:

1. Do only the last bit of TF after P-1. It may be suboptimal but given the number of P-1s that only have stage 1 performed, the sub-optimality is not as bad.

2. Assign P-1 to some (if not all) "Whatever makes sense" computers that have at least 200MB of memory allocated. If they have allocated that much memory they should not be surprised if Prime95 uses it.

[QUOTE=garo;168958]While the proposal to give extra credit is attractive it muddies the purity of the current GIMPS credit system. We finally have a system where credit is proportional to the amount of work done - up to processor equivalence[/QUOTE]

This assumes that "work" is defined solely by the amount of processor time donated to the project. But P-1 stage 2 testers also donate RAM time which could perhaps be recognised somehow. I'm not suggesting maintaining a separate total for GigaByte-days, but folding it into the processor time somehow.

[QUOTE=davieddy;168904]Is it not something of a remarkable coincidence that P-1 is so
near the borderline of what is worthwhile before LL testing?[/QUOTE]

I'm skeptical that ckdo's result is representative of typical GIMPS participating boxen. If it is, then that suggests there is something seriously wrong with the way bounds are calculated.

But lets go with his figures. If P-1 takes 5 times as long to find 3 times the number of factors as the last 2 bits of TF, then it takes 7.5 times as long to find 6 times the number of factors as the last bit of TF. If it's worth doing the last bit, then it's possibly up to 6 times as worthwhile to do P-1.

[QUOTE=Prime95;168916]The bottleneck to GIMPS' overall progress has been and always will be LL testing (both first time and double-checking).[/QUOTE]

If that's the case, then we should drop the "last two bits" optimisation outright, or else schedule enough un-P-1-ed exponents for the last two bits to keep LL machines from ever doing them.

Modern computers come with more than 1 GB of memory (3 GB seems to be a minimum on portables in the current offer at Dell for instance.) I think therefore that the default memory usage of Prime95 coud be increased. Several possibilities are available : a quarter of physical memory or 200MB or a more ellaborate scheme. On first use the user would have to approve that memory limit. That way the number of machines that could be assigned exponents that still need P-1 would increase substantially. A "standard" LL work unit would be P-1, trial factor for two bits and LL test.

The era of new computers comming with minimal meory is a bygone and Prime95 could reflect this situation.

Jacob

[quote=cheesehead;168951]Yes ... one might speculate that an Intelligent Designer arranged it so!

[/quote]

Very witty Richard:smile:

As an atheist, I presume you mean George.
But I think my "fortunate coincidence" idea still holds,
in as much as without optimizing B1 and B2, P-1 would
be a waste of time.

[quote=davieddy;169002]
As an atheist, I presume you mean George. [/quote]
Sorry, I would like to make it clear I was speaking
for myself, and not you or George.

Based on the latest primenet exponent dist status it would appear that 1 more bit of TF has just been released. This should only leave the last TF bit to follow P-1 and to proceed LL.

I found that one of my computers wasn't getting P-1 work as requested:[code][Main thread Apr 16 08:28] Mersenne number primality test program version 25.9
[Comm thread Apr 16 08:28] Getting assignment from server
[Comm thread Apr 16 08:28] PrimeNet success code with additional info:
[Comm thread Apr 16 08:28] [b]Not enough available memory for P-1 factoring assignments.[/b]
[Comm thread Apr 16 08:28] Got assignment 6858593FFB70E8E4D487E79982B3B18D: Double check M21947801
[Comm thread Apr 16 08:28] Sending expected completion date for M21947801: Apr 24 2009
[Comm thread Apr 16 08:28] Done communicating with server.[/code]My memory allocation is set as follows in [i]local.txt[/i]:[code]Memory=500 during 1-5/5:00-22:00,6-7/6:00-22:00 else 1400
MaxHighMemWorkers=1 during 1-5/5:00-22:00,6-7/6:00-22:00 else 2[/code]But notice in the attached screenshot how the memory appears in the [i]Options... | CPU[/i] screen (500-daytime; 8-nighttime).
Why does Primenet think I don't have the requisite 300MB for P-1?

Prime95 is having trouble converting the general during-else syntax into the more restrictive day_memory/night_memory settings that the server supports.

Try this. Change your local.txt to:

Memory=500 during 5:00-22:00 else 1400

Hopefully, prime95 will read these settings properly and send them to the server.

then change it back to:

Memory=500 during 1-5/5:00-22:00,6-7/6:00-22:00 else 1400

Once it is in this more complicated syntax, prime95 should not update the server anymore (nor accept changes if they are made on the server).

[quote=James Heinrich;169485]My memory allocation is set as follows in [I]local.txt[/I]:[code]Memory=500 during 1-5/5:00-22:00,6-7/6:00-22:00 else 1400
MaxHighMemWorkers=1 during 1-5/5:00-22:00,6-7/6:00-22:00 else 2[/code]But notice in the attached screenshot how the memory appears in the [I]Options... | CPU[/I] screen (500-daytime; 8-nighttime).
Why does Primenet think I don't have the requisite 300MB for P-1?[/quote]In your attached screenshot, daytime is shown as beginning at 1:00 AM and ending at 11:30 PM. That isn't consistent with the 5:00-22:00 and 6:00-22:00 shown in your local.txt.

Might that be related to the problem prime95 has in converting time settings?

I think I've posted previously that I noticed certain settings being stored in both of two different files (local, prime) or something like that, making inconsistency possible. This may be an instance of that.