[QUOTE=jasonp;255266]Unless the scripts force a shutdown early, the internal time limit for poly selection is a linear interpolation between the entries of the following table.

Note that there is no consideration for parallel poly selection or for the number of sieving machines that are waiting for the poly selection to complete. Also, if you run with '-np X,Y' to search for a polynomial in a particular range, then there is no limit on the time spent (but a limit on the amount of time given to each of the leading coefficients between X and Y).
[code]
static const poly_deadline_t time_limits[] = {
{MIN_NFS_BITS, 4 * 60},
{304, 8 * 60},
{320, 15 * 60},
{348, 30 * 60},
{365, 1 * 3600},
{383, 2 * 3600},
{399, 4 * 3600},
{416, 8 * 3600},
{433, 16 * 3600},
{449, 32 * 3600},
{466, 64 * 3600},
{482, 100 * 3600},
{498, 200 * 3600},
{514, 300 * 3600},
};
[/code][/QUOTE]

jasonp,

I can't find that code on factmsieve.py. I found this:

[code]
# static global variables

PNUM = 0
LARGEP = 3
LARGEPRIMES = '-' + str(LARGEP) + 'p'
nonPrefDegAdjust = 12
polySelTimeMultiplier = 1.0
[/code]where from factMsieve.pl

[code]# This is for an Athlon 2800+ laptop. If your machine is about half as fast,
# replace this with a 2. 25% as fast, replace with a 4. It controls how long
# the polynomial selection phase will last.
$polySelTimeMultiplier=1.0;
[/code]

Sorry, I should have mentioned that the code I posted is from the msieve source.

Without a script providing guidance, the time limit msieve uses is for an entire poly selection job; it will stop when the time has elapsed, or the range given runs out, whichever comes first. If you run with -np then the time limit is for stage 1 and stage2 together, otherwise it is for stage 1 only (stage 2 cannot be interrupted currently). This means you'd get higher throughput if you ran with two copies of 'msieve -np' on two separate cores, since your pipeline is idle for most of the time waiting on a stage 1 hit to begin stage 2. For a large input you can even run them on the same input range, msieve will randomize the portions of the space that are searched so that overlap is unlikely. Make sure to specify a different argument for the -l, -s and -nf options for each run, to avoid files getting overwritten...

How would I combine the output from several -np runs to find the best poly? If possible I want to do it from a script.

I've halted polynomial selection for the c145 I'm working on. 2 days is probably long enough for a number that'll take about 8 days for sieving and linear algebra etc.

Chris K

If you have unix tools available, try 'grep norm *.p | sort -gk7 | tail -20' to get the 20 highest E-values. Then you have to find the file with a given E-value, and the polynomial that provides that E-value is below the 'norm' line.

Another question I don't know if already asked in this thread.
About "Beginners Guide to NFS factoring using GGNFS and MSIEVE" from Jeff's page I was wondering if more than one number can be added to example.n to be factored, like yafu batch[FONT=Verdana] of [/FONT][FONT=monospace][FONT=Verdana]work option.[/FONT]
[/FONT]

[QUOTE=em99010pepe;256190]Another question I don't know if already asked in this thread.
About "Beginners Guide to NFS factoring using GGNFS and MSIEVE" from Jeff's page I was wondering if more than one number can be added to example.n to be factored, like yafu batch[FONT=Verdana] of [/FONT][FONT=monospace][FONT=Verdana]work option.[/FONT]
[/FONT][/QUOTE]
No, its strictly one number I'm afraid.

Would it be possible to add that to the script?

[QUOTE=smh;256204]Would it be possible to add that to the script?[/QUOTE]
I looked quickly at doing this but it looks anything but easy I'm afraid.

For a C150, under the script, lattice sieving was started with gnfs-lasieve4I13e instead of gnfs-lasieve4I14e, why? The issue is that too few per special-q are being found and the script is in loop. Minimum relations needed estimated was 1.53361e+07 but for this size of number it needs at least 3 times more. What am I doing wrong?

[QUOTE=Carlos Pinho;257946]For a C150, under the script, lattice sieving was started with gnfs-lasieve4I13e instead of gnfs-lasieve4I14e, why? The issue is that too few per special-q are being found and the script is in loop. Minimum relations needed estimated was 1.53361e+07 but for this size of number it needs at least 3 times more. What am I doing wrong?[/QUOTE]
Without knowing your inputs to the script, it is not possible to work out what might have caused this.

For type:SNFS (on example.poly) how do I change the estimated minimum relations in function of the composite size? I want to increase the default settings.