[QUOTE=yoyo;415676]Raise it in this thread if I should instruct my Minions to run thousands of curves.[/QUOTE]

17770 @ 11e7 would be nice and appreciated.

Ok, they will be sent as next to the Minions.

40% done so far: [url]http://www.rechenkraft.net/yoyo//y_status_ecm.php[/url]

C175 @ i5241
 

[B]yoyo[/B] is about to finish t55 (ECM work).

I don’t have much experience with numbers this large. From a previous post
[QUOTE]I use (GNFS digits - 6)/3 rule.[/QUOTE]
So this C175 needs (175-6)/3 or 4/15 the way to t60.
Does 11200 @ 26e7 sound about right?

Another post
[QUOTE]I use 0.31 * digits for GNFS[/QUOTE]
Which calculates to just under t55, which means we have enough ECM.

I have my own rule of thumb for estimating.

A 175-digit number will take about 20,000 thread-hours to sieve.

Once you've done a t55, the probability of finding anything by doing a t60 is about (60-55)/55, so one in eleven or so.

So it's not worth doing more than 2,000 thread-hours of ECM.

The 17700@11e7 is already about 2,000 thread-hours of ECM (one curve at that level takes about ten minutes)

So I would say you've done enough ECM, and start polynomial selection now.

[QUOTE=fivemack;416442]So I would say you've done enough ECM, and start polynomial selection now.[/QUOTE]

I'll start the poly search tonight.
Thanks for the stats. It is the most optimal.
I have no idea how long it take to sieve these large numbers since they are beyond my resources.

My "rule of thumb" is 0.33*ndigits, this (somehow) eliminates the "3 way splitting". If it survives that, it has high chances that it will only split in two by GNFS.

I use that ratio for smaller numbers. I think the ECM work (resources) increase faster than the NFS resources needed for the same equivalent size as the composites grow larger.

But what do I know? :smile:

I think ECM digits = digits * 0.33 was a rule of thumb when poly selection was vastly less powerful than it is now. Modern msieve, particularly with GPU-stage 1, has taken a digit or two away from effective difficulty, resulting in a lower optimal ECM effort.
(digits - 6) / 3 => (digits/3) - 2 => about half the ECM effort of digits/3 looks like it matches up pretty well with Tom's expected-factor-time calculation.

It is also likely that folks used to slightly over-ECM numbers; I certainly did, as ECM is efficient to run on low-spec machines compared to LLR, and convenient to run on such machines compared to NFS.

As for 3-way splits, I consider those a rare treat!

It makes totally sense what you say. You also may consider that gpu's are not doing only poly, but also ecm. Unfortunately I am mostly at "yafu stage", using msieve very seldom (practically never, since yafu does everything for me), and "switching ecm to gpu", and "switching poly selection to gpu", are "high priority" items on my "todo list" since years, but never found the time/resources to play with them (i.e. find the right executables, or build them, learn the tools, find free time on the gpus/machines which most of the time run TF, gpu-LL, and RL-related tasks). It was planned some time ago, then my titan crashed (not yet fixed, bought a new one, the old one had many adventures like I put it in a oven and the capacitors blew, etc, hehe, I may post in the "cooling thread" if I find the time, I have a lot of things to tell you).

I still hope to go "gpu ecm" and "gpu poly" 100%, very soon, and then I will have to re-read all these threads... grrr...

C175 @ i5241
 

Found a good poly.
[CODE]N: 1561248012875604421290997452712948651673429631296532916308406424711670868236536811765897539577054945788349762744593204554580205942062187848423188814351767445694628965970805839
# expecting poly E from 1.73e-13 to > 1.99e-13
R0: -2921485258420054233795687624707655
R1: 11197286481893873
A0: -3648904307721440541363054106517980023512992
A1: -1228544630159808525398670589488439616
A2: -2336973510196735534005200082
A3: 4718033960360448430271
A4: -613255320209996
A5: 7335900
# skew 18500902.09, size 5.225e-17, alpha -9.145, combined = 1.915e-13 rroots = 3[/CODE]