On Thu, Mar 06, 2003 at 08:12:31PM -0800, Chris Marble wrote:
> Daran wrote:
> >
> > Whichever machine you choose for P-1, always give it absolutely as much
> > memory as you can without thrashing. There is an upper limit to how much it
> > will use, but this is probably in the gigabytes for exponents in even the
> > current DC range.
>
> So I should use the PIII with 1 3/4 GB of RAM to do nothing but P-1.
This depends upon what it is you want to maximise. If it's your effective
contribution to the project, then yes. Absolutely! This is what I do on my
Duron 800 with a 'mere' 1/2GB. The idea is that the deep and efficient P-1
you do replaces the probably much less effective effort that the final
recipient of the exponent would otherwise have made (or not made, in the
case of a few very old clients that might still be running). I've not done
any testing, but I'm pretty sure that it would be worthwhile to put any
machine with more than about 250MB available to exclusive P-1 use.
On the other hand, you will do your ranking in the producer tables no
favours if you go down this route.
> It's an
> older Xeon with 2MB cache. Will that help too?
You'll have to ask George if there is a codepath optimised for this
processor. But whether there is or there isn't, should affect only the
absolute speed, not the trade-off between P-1 and LL testing.
I can't see how a 2MB cache can do any harm, though.
> How would I do this? I see the following in undoc.txt:
>
> You can do P-1 factoring by adding lines to worktodo.ini:
> Pfactor=exponent,how_far_factored,has_been_LL_tested_once
> For example, Pfactor=10000157,64,0
Unfortunately, pure P-1 work is not supported by the Primenet server, so
requires a lot of ongoing administration by the user. First you need to
decide which range of exponents is optimal for your system(s). (I'll
discuss this below). Then you need to obtain *a lot* of exponents in that
range to test. I do roughly eighty P-1s on DC exponents in the ten days or
so it would take me to do a single LL.
The easiest way to get your exponents is probably to email George and tell
him what you want. Alternatively, if the server is currently making
assignments in your desired range, then you could obtain them by setting
'Always have this many days of work queued up' to 90 days - manual
communication to get some exponents - cut and past from worktodo.ini to a
worktodo.saved file - manual communication to get some more - cut and past -
etc. This is what I do.
The result of this will be a worktodo.saved file with a lot of entries that
look like this
DoubleCheck=8744819,64,0
DoubleCheck=8774009,64,1
...
(or 'Test=...' etc.) Now copy some of these back to your worktodo.ini file,
delete every entry ending in a 1 (These ones are already P-1 complete),
change 'DoubleCheck=' or 'Test=' into 'Pfactor=', and change the 0 at the
end to a 1 if the assignment was a 'DoubleCheck'.
When you next contact the server, any completed work will be reported, but
the assignments will not be unreserved, unless you act to make this happen.
The easiest way to do this is to set 'Always have this many days of work
queued up' to 1 day, and copy your completed exponents from your
worktodo.saved file back to your worktodo.ini (not forgetting any that were
complete when you got them). You do not need to unreserve exponents
obtained directly from George.
Like I said, It's *a lot* of user administration. It's not nearly as
complicated as it sounds, once you get into the routine, but it's definitely
not something you can set up, then forget about.
If you're willing to do all this, then there's another optimisation you
might consider. Since it's only stage 2 that requires the memory, you could
devote your best machine(s) to this task, using your other boxes to feed
them by doing stage 1. This is assuming that they're networked together.
Moving multimegabyte date files via Floppy Disk Transfer Protocol is not
recommended.
[...]
> > If you are testing an exponent which is greater than an entry in the fifth
> > column, but less than the corresponding entry int the third column, then
> > avoid using a P4. This applies to all types of work.
Actually it's worse than this. The limits are soft, so if you are testing
an exponent *slightly* less than an entry in column 5, or *slightly*
greater than one in column 3, then you should avoid a P4.
Choice of exponent range
------------------------
Stage two's memory requirements are not continuous. This remark is probably
best illustrated with an example: on my system, when stage 2-ing an exponent
in the range 7770000 through 9071000, the program uses 448MB. If that much
memory isn't available, then it uses 241MB. If that's out of range, then
the next level down is 199MB, and so on. There are certainly usage levels
higher than I can give it.
The benefits of using the higher memory levels are threefold.
1. The algorithm runs faster.
2. The program responds by deepening the search, increasing the chance of
finding a factor.
3. If there is sufficient memory - corresponding to the 241MB level in the
above example, or greater - then an enhancement to the algorithm kicks
in, which occasionally finds additional factors. You can verify if this
is the case by examining your results.txt file. If you see 'E=4,' in a
'completed P-1' line, then the enhancement is in effect.
Clearly you are making better use of your resources by choosing an exponent
range with a memory level just below your available memory, assuming, of
course, that there are any unassigned P-1 ready exponents within that range.
I suggest trial and error to find the range most suitable for you.
A couple of other points: You are limited in the CPU menu option to
90% of physical memory, but this may be overridden by editing local.ini,
where you can set available memory to physical memory less 8MB. Also the
program is conservative. If I set available memory to 459MB (the maximum I
can via the menu option) then the actual memory used is 241MB I have to go
up to 465MB available before it will use the 448MB level.
> Useful info. I've got 2 DCs in one of the ranges but one computer's a PIII
> and the other's a Dec Alpha running Mlucas-2.7b-gen-5x.
Everything I have said pertains to Prime95/Mprime. I know nothing of
Mlucas.
HTH
> --
> [EMAIL PROTECTED] - HMC UNIX Systems Manager
Daran G.
_________________________________________________________________________
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
