[QUOTE=chalsall;294261]Now, the question at hand... Where do the curves cross to guide people as to how deep should they TF at a particular candidate level vs. doing a LL run?[/QUOTE]That's my next project. :smile:

[QUOTE=axn;294282]Eyeballing the stats (LL vs TF), I see the TF earning about 9x the credit/day vs LL. Assuming CPUs earn roughly the same credit/day for both LL & TF, this represents 3 additional bits of TF (7x additional effort in TF). No data for 680 -- I suspect it'll be closer to 4 additional bits.[/QUOTE]
Hmmm... Since DC-TF is saving only 1 LL test, that means DC-TF should do only 2 additional bits.
Here are the default values, for reference.
[code]
23390000 65
29690000 66
37800000 67
47450000 68
58520000 69
[/code]

[QUOTE=bcp19;294292]I have a feeling very few of those cards are being used by Gimpsters, seeing as they are GTS 2/3xx, GT 2/3xx and 8/9xxx models. Close to half of them produce less per day than a single core of an I5 2500k.[/QUOTE]

You're probably right -- nonetheless, it is an interesting question. There is no crossing of the lines, since there is only one line. That suggest an infinite number of additional bits :smile:

[QUOTE=axn;294298]Hmmm... Since DC-TF is saving only 1 LL test, that means DC-TF should do only 2 additional bits.
[code]
23390000 65
29690000 66
37800000 67
47450000 68
58520000 69
[/code]



You're probably right -- nonetheless, it is an interesting question. There is no crossing of the lines, since there is only one line. That suggest an infinite number of additional bits :smile:[/QUOTE]

why not use: [url]http://mersenne-aries.sili.net/throughput.php[/url] to create another line with CPU data ?

[QUOTE=chalsall;294246]What "Option" did you choose? If it was the default of "What makes sense" and your pledge was to 72, then you would have received the "Oldest".

I sometimes change "What makes sense" to be what makes sense at the time. There are some old candidates reserved from PrimeNet coming back from P-1 workers who took work at below 72 which I wanted to clear out.

The other options, "Lowest Exponent", etc, always do what they say they'll do.[/QUOTE]

It shouldn't matter what option I chose, if I specified the range 0-51000000, then I shouldn't get any expos >51M regardless of option, unless that's wrong? It hasn't appeared to be wrong before.

[QUOTE=chalsall;293785]We currently hold about 42 days of LL Trial Factoring work.[/QUOTE]

[QUOTE=chalsall;293785] less than 200 days to Trial Factor everything to the new GPU levels up to 60M for every candidate not already LLed.[/QUOTE]

We shouldn't be losing ground should we? unless LL tests are being turned in quicker than we can eliminate candidates.
Today GPU=59.5 and PrimeNet=226

[QUOTE=petrw1;294387]We shouldn't be losing ground should we? unless LL tests are being turned in quicker than we can eliminate candidates.
Today GPU=59.5 and PrimeNet=226[/QUOTE]

Nope. What you're seeing here is two fold...

1. A very large batch of Xyzzy's work scrolled off the 30 day window.

2. Spidy is no longer throwing back candidates it finds at above 55M at 71 bits. This is to ensure that PrimeNet only issues work to LL workers TFed to at least 72.

We continue to release appoximately 2.5 times as many candidates as are being claimed by LL workers.

And remember that the "less than 200 days to TF everything up to 60M" still stands -- the chart is showing to 61M because we hold some. Right now we could do everything up to 60M in 162 days.

How far should we TF in the DC range?
 

Point for discussion.

Now that James has put together his excellent [URL="http://mersenne-aries.sili.net/cudalucas.php?model=13&granularity=1"]mfaktc vs CUDALucas[/URL] analysis, it shows that we actually shouldn't start TFing to 70 in the DC range until about 33.5M, rather than the 29.69M we were doing based on Prime95/mprime's cross-over point.

So my question to everyone is, should we change the GPU72 cross-over point to be 33.5M instead, even though we are currently very far ahead of the wave-front?

This question is largely directed to bcp19, as he's the main person still doing the "to completion" work in the DC range. But I would also like feedback from others who have a strong opinion one way or the other.

Another option, of course is to nominally take things to 69 below 33.5, but keep some just ahead of the wavefront to be available to those who want to go to 70.

Thoughts?

I think the "system" should facilitate what is optimal for GIMPS. Individual user can easily override the system defaults (for those exponents spidy catches). Spidy should only pickup exponents based on the calculated (new) thresholds.

[QUOTE=chalsall;294566]Point for discussion.

Now that James has put together his excellent [URL="http://mersenne-aries.sili.net/cudalucas.php?model=13&granularity=1"]mfaktc vs CUDALucas[/URL] analysis, it shows that we actually shouldn't start TFing to 70 in the DC range until about 33.5M, rather than the 29.69M we were doing based on Prime95/mprime's cross-over point.

So my question to everyone is, should we change the GPU72 cross-over point to be 33.5M instead, even though we are currently very far ahead of the wave-front?

This question is largely directed to bcp19, as he's the main person still doing the "to completion" work in the DC range. But I would also like feedback from others who have a strong opinion one way or the other.

Another option, of course is to nominally take things to 69 below 33.5, but keep some just ahead of the wavefront to be available to those who want to go to 70.

Thoughts?[/QUOTE]

[URL]http://mersenneforum.org/showpost.php?p=294572&postcount=1725[/URL] might answer your question. By my calculations, 2 of my systems are efficient at the current transition points and the other 3 become efficient within 3-4M.

I think we'll all be happy to know that sometime in the last 24hrs or so, one of my P-1 cores that was running low picked up a 56M expo that was already at 72 bits from PrimeNet. The more I think about it, the better it is that we release candidates at 72 bits that we can't handle, 'cause now we're saving the "regulars" some work too :smile:
Edit: Now that I think about it, it's also probably partially due to the fact that Spidey is now keeping expos at 71, thereby removing those from the P-1 pool.


Edit2: Can we have another list of Top 100 factors, except ranked by log2(factor)/exponent? That weights a 95 bit factor for a 48M expo higher than 95 bits for 55M expo. (You might need a scaling factor as well, so that the number isn't ridiculously small :razz:)

[QUOTE=Dubslow;294718]
Edit2: Can we have another list of Top 100 factors, except ranked by log2(factor)/exponent? That weights a 95 bit factor for a 48M expo higher than 95 bits for 55M expo. (You might need a scaling factor as well, so that the number isn't ridiculously small :razz:)[/QUOTE]
This could only make sense for TF, and not too much sense for P-1 or ECM. There is no factor in that list which was found by TF. We could have it sorted in any order we like, if the effort is not big to implement it. But I think the effort is high for the benefit we get.