[QUOTE=chalsall;289787]Just so everyone knows, Dubslow has once again beaten me (:smile:) to announcing that I've added an overall GHz Days per Day of Work Saved graph, and a Linear Regression Trend line to many of the graphs, on the [URL="http://www.gpu72.com/reports/overall/graph/month/"]Overall System Progress Graphs[/URL] page.
[/QUOTE]

That graph looks highly suspicious... Just roughly adding the DC saved in the graph would give about 30,000 GD in the last 30 days, but if we look at the overall report it shows we have only saved about 16,925 GD for DC since the project started.

[QUOTE=Xyzzy;289655]The new "Saved" metric is exactly what we were hoping for. After our current run of DCTF work is done we will tackle this challenge aggressively!

:mike:[/QUOTE]

Ok, if you go back to LL TF, I guess I will as well.

-- Craig

On optimizing for metrics, here's what I've found:

To optimize for:
1) Done GHZ-days/day:
Do LL TF, with x,y bit levels with the "Stages=0" command in mfaktc.ini, with x being the lowest bit level you can get your hands on, and y being the highest bit level you're prepared to work on. For me generally, it's been bit levels 70 to 72.

2) Factors found
Do the lowest single bit level on DCTF. Generally I've been doing 68 to 70 (or 67 to 70 if I can get them). Mainly I go the 'to 70' method as if I did single bit level, the managment overhead is too much.

3) Saved GHZ-days/day
Do the lowest single bit level on LLTF generally that will be 70-71.

These are incompatible strategies.

Before I embark on (3), can I confirm that's what is in the best interests of the project. Or do I keep going with (1)? The difference between (1) and doing (3) as 70-71 then 71-72 is only a few percent. But that adds up on a farm my size.

-- Craig

[QUOTE=nucleon;289880]These are incompatible strategies.

Before I embark on (3), can I confirm that's what is in the best interests of the project. Or do I keep going with (1)? The difference between (1) and doing (3) as 70-71 then 71-72 is only a few percent. But that adds up on a farm my size.[/QUOTE]

The best thing for [I][U]GIMPS[/U][/I] (which is what the project was created to help) is to do as much TFing (and P-1ing) as we're going to do, and then get candidates back into the PrimeNet pool as quickly as possible. Thus, in the LL range, TFing to 72 is the best thing.

Having said that, TFing from 71 to 72 takes twice as long as TFing from 70 to 71, with approximately the same chance of finding a factor. This is why many people are doing lower bit-levels; and I have no problem with that -- some enjoy finding factors and the work has to be done.

For people like you Craig, I'd recommend you use the "Lowest TF Level" option in the Get Assignments pages, but (if you would be so kind) take them up to 72 bits (with the "Stages=0" option which as you point out is more efficient).

As an aside, there is really no reason to do DC TF work at the moment, although I know some people enjoy doing so. We are so far ahead of the "wave" that we could do no DC TF work for several months, and there would still be no DC assignments from PrimeNet which were not already at at least 69 bits.

Quote chalsall: " (with the "Stages=0" option which as you point out is more efficient)."

Craig- What is your setting for StopAfterFactor? It seems that it has to be 0 or 2. Are you letting them run all the way (0) on the chance of finding another factor?

[QUOTE=James Heinrich;289597]I think that is the more interesting number. Would it be possible to present the average line in the graph as a 30-day moving average rather than start-to-now average?[/QUOTE]

This has been done on the GHz Days of Work Done graphs. I'll do it on the GHz Days of Work Saved graphs shortly.

[QUOTE=diamonddave;289869]That graph looks highly suspicious... Just roughly adding the DC saved in the graph would give about 30,000 GD in the last 30 days, but if we look at the overall report it shows we have only saved about 16,925 GD for DC since the project started.[/QUOTE]

I think he's counting an LLTF factor saves like 90 GHz days LL, and 90 GHz days DC.

[QUOTE=James Heinrich;289861]Parsing data from PrimeNet I don't know what bounds were used to find a P-1 factor, or even that P-1 was used at all. If you can submit you results.txt to the site then you'll get the pretty P-1 graph that clearly shows the factor outside the used P-1 bounds.[/QUOTE]
It was P-1, but I'm not at my desktop for the weekend, and can submit the file when I get back Sunday night. (I usually submit P95 results files every month or two.) The bounds would be whatever MPrime chose at the given TF level, assuming "up to 10000 MB" of memory. (I think in this case B1 is either 505K or 510K.)

[QUOTE=Dubslow;289889]I think he's counting an LLTF factor saves like 90 GHz days LL, and 90 GHz days DC.[/QUOTE]

That's correct. But I'm going to do an audit of that data shortly just to make sure it's sane.

I just noticed the URL for the "GPU to 72" team in PrimeNet is still [url]http://gpu.mersenne.info/[/url]
You may want to change that to [url]http://www.gpu72.com/[/url] ?

[QUOTE=James Heinrich;289895]I just noticed the URL for the "GPU to 72" team in PrimeNet is still [url]http://gpu.mersenne.info/[/url]
You may want to change that to [url]http://www.gpu72.com/[/url] ?[/QUOTE]

Thanks James. Had totally missed that.

And was that your subtle way of letting me announce that the GPU to 72 team is now #1 for Trial Factoring, and #3 for P-1 Factoring??? :smile:

Thanks for all the cycles everyone! :cool:

[QUOTE=chalsall;289898]Thanks James. Had totally missed that.

And was that your subtle way of letting me announce that the GPU to 72 team is now #1 for Trial Factoring, and #3 for P-1 Factoring??? :smile:

Thanks for all the cycles everyone! :cool:[/QUOTE]
I didn't say anything because it was kinda cool that the last-modified date was the same as the created date :P

Oh well. Awesome!