[QUOTE=Andi47;229332]:tu:

can you please run one of this "-B2scale 2" curves with ecm -v -v -v and post the output here, to get an estimation how much of these curves are needed for t55?[/QUOTE]
Sure


With -B2scale 2 (B1=11e7, B2=1589211473866):
[code]Expected number of curves to find a factor of n digits:
20 25 30 35 40 45 50 55 60 65
2 4 9 31 123 553 2810 [b][color=red]15947[/color][/b] 98800 665287
[/code]


For comparison, the default B2 is (B1=11e7, B2=776278396540):
[code]Expected number of curves to find a factor of n digits:
20 25 30 35 40 45 50 55 60 65
2 4 10 34 135 613 3133 [b][color=red]17769[/color][/b] 111196 751771
[/code]


So I guess it counts as about 1.11x of a default curve (if that's why you're asking), and so 1000 of these curves is about 0.0627 of a t55.

I posted the four from above to the db:

4 curves: B1=26e7, B2=3178559884520

I'll post on Sunday (if estimate is correct) how the 100 curves at 11e7 turn out.

Oh I saw the 26e7 from the save lines you posted, so I thought you were running 26e7 curves when I posted. Nevermind then.

[QUOTE=EdH;229365]I'll post on Sunday (if estimate is correct) how the 100 curves at 11e7 turn out.[/QUOTE]
Note that, if a factor is found it'll be printed in standard output, not in the save file you posted. The save file isn't necessary for reporting the curves. So be sure you are keeping the standard output in case you find a factor, otherwise you will miss it.

[quote=jrk;229366]. . . Note that, if a factor is found it'll be printed in standard output, not in the save file you posted. The save file isn't necessary for reporting the curves. So be sure you are keeping the standard output in case you find a factor, otherwise you will miss it.[/quote]
Hmm.. I didn't know that part. I guess I'll need to pipe it to another file. I've restarted with "tee" to send the console output to a file as well.

Thanks.

[QUOTE=jrk;229351]
So I guess it counts as about 1.11x of a default curve (if that's why you're asking), and so 1000 of these curves is about 0.0627 of a t55.[/QUOTE]

thanks, that was exactly why I was asking. So we currently have 44.49% of t55.

[quote]Would RSALS be interested in sieving this C170? I see they are doing other Aliquot numbers.[/quote]Well, I haven't participated in this topic lately because the 14e siever isn't too happy with GNFS tasks of difficulty 170. It's better at 165 digits and below (RSALS currently holds the record for GNFS factoring of the near-repdigit-related project, at 165 digits). In post #954, I think that you were correct to advise using the 15e siever :smile:

Nevertheless, I have just tested the polynomial that you posted in post #954, in a range of q values starting at alim/2 (factMsieve.pl default):
* 1998 q values yielded 1493 relations at ~0.915 sec/rel on one core of my usual sieving benchmarking computer, a Core 2 Duo T7200 (2 GHz);
* letting it run to 8026 q values yielded 5174 relations at ~0.895 sec/rel.
Only our hardest SNFS tasks ever, difficulty 245-250, ever needed ~0.8-1 second per relation...

Unless we can optimize the sieving somewhat (a "white swan" polynomial, 3LP sieving, or whatever), I'm not sure the RSALS grid is the best way to factor this number... We could bring relations to a team sieving, but with a yield about twice lower than 15e.


EDIT: sieving with the polynomial of post #954 modified thusly for 3LP sieving:
[code]mfba: 89
alambda: 3.6[/code]
yields 2236 relations over a range of 1998 q values starting at alim/2, at 0.84600 sec/rel... good :smile:
That alone could make it a candidate for RSALS, and I guess that further optimization of the parameters (I'll let you experts do that, I'm very far from being an expert :smile: ) could make it even better.

[QUOTE=debrouxl;229467]EDIT: sieving with the polynomial of post #954 modified thusly for 3LP sieving:
[code]mfba: 89
alambda: 3.6[/code]
yields 2236 relations over a range of 1998 q values starting at alim/2, at 0.84600 sec/rel... good :smile:
That alone could make it a candidate for RSALS, and I guess that further optimization of the parameters (I'll let you experts do that, I'm very far from being an expert :smile: ) could make it even better.[/QUOTE]
Try the 3LP params I suggested in #960:

[code]rlim: 33554431
alim: 33554431
lpbr: 30
lpba: 30
mfbr: 60
mfba: 87
rlambda: 2.6
alambda: 3.6[/code]
The mfba can be 2 or 3 bits smaller than 3*lpba, because the closer you get to 3*lpba the less likely a cofactor is to split nicely. So lowering the mfba is a compromise which improves speed a bit but does not sacrifice too much yield. Lowering the alim,rlim is also a way to take advantage of the improvement of 3LP sieving without killing a lot of yield (i.e. the yield is still higher with half the fb on both sides).

Oops, I forgot about your 3LP polynomial :blush:
It has the same yield as my unoptimized one over the range of 8K q values at alim/2 (-10% over the first 2K q values), but is more than 30% faster... good tradeoff indeed :smile:

Well, if the number survives ECM a bit further than the current amount of work, I'll be able to queue some sieving work on it to the RSALS grid, since 3LP sieving enables 14e to tackle GNFS-170 :smile:
I'm OK with a team sieving, because I know that some seasoned number factoring folks may not be able to install BOINC clients on some of their computers.

[QUOTE=debrouxl;229490]Well, if the number survives ECM a bit further than the current amount of work, I'll be able to queue some sieving work on it to the RSALS grid, since 3LP sieving enables 14e to tackle GNFS-170 :smile:[/QUOTE]
Allow me to ask, why do you not allow the 15e siever?

Sieving with 14e is perfectly acceptable of course (it's better than nothing!) but it will be slower, require a lot more Q, and thus generate a greater rate of redundancy than 15e.

[QUOTE=debrouxl;229490]I'm OK with a team sieving, because I know that some seasoned number factoring folks may not be able to install BOINC clients on some of their computers.[/QUOTE]
Even just doing part of the sieving on RSALS would be welcome.

[QUOTE=debrouxl;229490]Oops, I forgot about your 3LP polynomial :blush:
It has the same yield as my unoptimized one over the range of 8K q values at alim/2 (-10% over the first 2K q values), but is more than 30% faster... good tradeoff indeed :smile:

Well, if the number survives ECM a bit further than the current amount of work, I'll be able to queue some sieving work on it to the RSALS grid, since 3LP sieving enables 14e to tackle GNFS-170 :smile:
I'm OK with a team sieving, because I know that some seasoned number factoring folks may not be able to install BOINC clients on some of their computers.[/QUOTE]Time for me to 'fess up. I've been sieving with jrk's second (3LP) poly since 8/28. Unfortunately, I didn't catch his pointer to start sieving at 20M so I started at ~1/2 the factorbase (16M). I'm sieving on 4 cores (a Pentium Dual Core E2220 2.4GHz & an AMD Athlon 64 X2 5000+ 2.6GHz). So far the yield has been right around 22k relations per 10k block. The speed on the AMD is near .60 secs/rel with the Pentium running a little faster (<3.5 hours per 10k).

Last time I ran a check with msieve, this was the result:[code]begin with 7895978 relations and 24590797 unique ideals
reduce to 127 relations and 0 ideals in 4 passes
max relations containing the same ideal: 0[/code]The duplicate rate is very low, running about 5% (by this point in a regular job, I'm getting 15-20%)

Contact me before you start sieving so I can let you know how far I've gotten.....

[QUOTE=schickel;229524]Time for me to 'fess up. I've been sieving with jrk's second (3LP) poly since 8/28.[/QUOTE]
It's fine, as long as you don't mind being blown out of the water by a nice ECM factor!

[QUOTE=schickel;229524]Unfortunately, I didn't catch his pointer to start sieving at 20M so I started at ~1/2 the factorbase (16M).[/QUOTE]
It's perfectly fine to start with whatever Q you want, and there's little difference between 16M and 20M, so that's OK. But I wouldn't go any lower.

[QUOTE=schickel;229524]The duplicate rate is very low, running about 5% (by this point in a regular job, I'm getting 15-20%)[/QUOTE]
Uh, whoa. Really? That sounds bad. 5% duplication seems high for what amounts to less than 1/10 of the needed work done... remember, duplication rate goes up as you sieve more Q. 15-25% duplication would be expected for the entire job.