This polynomial is not very good; with 4 cores you should spend at least several days on a polynomial search. A good polynomial will sieve ~15% faster than you're managing now, which is important because a single machine will take months to finish sieving for a 512-bit input. Also, with those parameters you will need a little over 50 million relations before the postprocessing can run.

Mini-geek: 154 digits = RSA key. Protecting what, I wonder?

Yes, you right, thats RSA key, which used for signing some MCU code i want to change.

Also, about distributed sieving, i making small utility (client-server based), to help more easy to factor the keys, now i paralleled the script for using multiply cores on small N, now want to understand, which params will be best for the best results.

Really appreciate any help. Tanx.

There is some error i have while processing first stage:

There is much lines with:
[CODE]-> Searching leading coefficients from 115281001 to 115282000.
=> "pol51m0b.exe" -b example.polsel.server.4004 -v -v -p 7 -n 4.86E+023 -a 115281 -A 115282 > example.polsel.server.4004.log
cannot invert 0
[/CODE]

[CODE]cannot invert 0[/CODE]
many-many lines with such error,
N is 154 digits,
ggnfs-0.77.1
Any ideas?

[QUOTE=siew;192504]There is some error i have while processing first stage:

There is much lines with:
[CODE]-> Searching leading coefficients from 115281001 to 115282000.
=> "pol51m0b.exe" -b example.polsel.server.4004 -v -v -p 7 -n 4.86E+023 -a 115281 -A 115282 > example.polsel.server.4004.log
cannot invert 0
[/CODE]

[CODE]cannot invert 0[/CODE]
many-many lines with such error,
N is 154 digits,
ggnfs-0.77.1
Any ideas?[/QUOTE]

Have you checked N? Does N perhaps have a small factor? i.e. one
inside the factor base, or a factor that is not coprime to the lead coefficient
of the polynomial?

[quote=R.D. Silverman;192615]Have you checked N? Does N perhaps have a small factor? i.e. one
inside the factor base, or a factor that is not coprime to the lead coefficient
of the polynomial?[/quote]
i severely doubt it as it is a RSA key

Please, any advice:

c148
sieved from 0...20 000 000, collected the data:

[CODE]skew 284391.86, size 2.065189e-014, alpha -5.969701, combined = 6.398886e-012

commencing relation filtering
estimated available RAM is 3837.6 MB
commencing duplicate removal, pass 1
found 12999126 hash collisions in 41657068 relations
added 370 free relations
commencing duplicate removal, pass 2
found 20870041 duplicates and 20787397 unique relations
memory use: 330.4 MB
reading ideals above 18415616
commencing singleton removal, initial pass
memory use: 753.0 MB
reading all ideals from disk
memory use: 378.0 MB
commencing in-memory singleton removal
begin with 20787397 relations and 29536653 unique ideals
reduce to 525836 relations and 183285 ideals in 15 passes
max relations containing the same ideal: 8
reading ideals above 30000
commencing singleton removal, initial pass
memory use: 47.1 MB
reading all ideals from disk
memory use: 24.0 MB
commencing in-memory singleton removal
begin with 526210 relations and 1725285 unique ideals
reduce to 31 relations and 0 ideals in 4 passes
max relations containing the same ideal: 0
filtering wants 1000000 more relations
[/CODE]

How many relations can it need else?
I plan to collect about 50 000 000, will it enough, what do you think?
tanx!

[QUOTE=siew;193684]Please, any advice:

c148
sieved from 0...20 000 000, collected the data:

[CODE]
found 12999126 hash collisions in 41657068 relations
added 370 free relations
commencing duplicate removal, pass 2
found 20870041 duplicates and 20787397 unique relations
[/CODE]
[/QUOTE]

I think you'll probably want to get to something like 40,000,000 unique relations; the problem with sieving from 0 is that you get quite high duplication rates.

[QUOTE=fivemack;193687]I think you'll probably want to get to something like 40,000,000 unique relations; the problem with sieving from 0 is that you get quite high duplication rates.[/QUOTE]

Yes, but in my experience, the high duplications are [b]MORE[/b] than
compensated because of the very high yield rates per special-q.

:-)
so, seems i done at about 40-50% of total...

think i have to continiue sieving for same period of time

i have 24 cores, and each yields about 750 000 relations per 24 hours, so seems i have to spend 1-2 days more. But how to reduce duplicates rate? is it possible?

I have built new Windows 32bit and 64bit ggnfs binaries based on the SVN 374 version of the ggnfs code. You can download them here: [url]http://gilchrist.ca/jeff/factoring/[/url]

Hopefully this fixes the crashes a few people have been experiencing, it also removes the garbage output in the 64bit sievers, and adds an 11e siever for doing smaller jobs. Andi47 did some benchmarks and found that C85's are about 20% faster with the 11e and about 4% faster at C93 vs the 12e siever. He also provided some changes to factMsieve.pl to access the new 11e siever up to 16e as well. Thanks Andi for the help testing and code.

If you find any problems, please let me know.

Jeff.

Watch out for 10-20% faster sievers
 

In SVN revision 377, I've added some oomph to the 64-bit asm-optimized sievers in the experimental branch. (up to 20% speedup for 15e, 10% for 14e, 16e, a bit less for others, while all retrogression tests hold.) In rev.370, I've also fixed the "mpqs failed" thingy but the effect of this is negligible. Also, I've restored [FONT=Courier New]rint[/FONT]() in redu2.c; [FONT=Courier New]trunc[/FONT]() in redu2.c leads to ~1% loss in found relations and of course, in speed. (notably the KF/CJM source always had [FONT=Courier New]rint[/FONT](), which only had one small problem which has been fixed long ago.)

I wonder if the similar changes ([FONT=Courier New]L1_BITS 16[/FONT] with corrections to the code) will benefit the plain source; I guess it should. I will merge these changes now (watch for revisions 378+). Jeff, could you build and test them on small polynomials on your computer and then possibly rebuild all of them for public use? Let me know if there will be any problems.

<S>