[QUOTE=kladner;289883]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]

StopAfterFactor=2

Once I've found a factor - I'm outta here.

-- Craig

[QUOTE=chalsall;289882]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]

Basically you said what I was thinking of anyhow. I'll finish what I have allocated (as it's a pain to return 5000+ candidates across 18 instances :)

I'll move onto 'x to 72' after the current allocation is finished.

-- Craig

[QUOTE=chalsall;289882](with the "Stages=0" option which as you point out is more efficient).
[/QUOTE]
Man, how did I miss this one?

I just picked up some speed. :smile:

[QUOTE=nucleon;289911]StopAfterFactor=2

Once I've found a factor - I'm outta here.

-- Craig[/QUOTE]

Thanks!

[QUOTE=oswald;289918]Man, how did I miss this one?

I just picked up some speed. :smile:[/QUOTE]

I just made this change also.

[QUOTE=chalsall;289882]with the "Stages=0" option which as you point out is more efficient[/QUOTE]Assuming an assignment of 69-71 (for example) then I can see that being potentially more efficient. But if you have an assignment like 70-72, wouldn't you also [i]lose[/i] some efficiency by having to use the 79-bit core on the 70-71 segment instead of the 71-bit core?

[QUOTE=James Heinrich;289935]Assuming an assignment of 69-71 (for example) then I can see that being potentially more efficient. But if you have an assignment like 70-72, wouldn't you also [i]lose[/i] some efficiency by having to use the 79-bit core on the 70-71 segment instead of the 71-bit core?[/QUOTE]

It's something I played with in testing. I don't understand the how/why mechanics on why it's faster.

There maybe certain combinations where it's not faster. I'm not sure what combos these are. As a general rule, it's something I've been doing.

-- Craig

[QUOTE=James Heinrich;289935]Assuming an assignment of 69-71 (for example) then I can see that being potentially more efficient. But if you have an assignment like 70-72, wouldn't you also [i]lose[/i] some efficiency by having to use the 79-bit core on the 70-71 segment instead of the 71-bit core?[/QUOTE]

On CC 2.0+ cards, I think the barret79_mul32 kernel is used regardless of the bit level. But this could be a concern for people with older cards (GTX 2xx and older) which a different kernel for < 72 bit tests.

[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]

[url]http://mersenne-aries.sili.net/exponent.php?factordetails=35555090100297483645409[/url]

Weekend activities...
 

Hey all. Just so people know, over the weekend I:

- Added a "Released Trend" (Linear Regression) line to the Trial Factoring Depth per Day graphs on the [URL="http://www.gpu72.com/reports/overall/graph/month/"]Overall System Progress Graphs[/URL].

- Tweeked the LR lines on the other graphs so the current day is not including in the linear regression. This is to prevent the trend line varying during the day, and tending to be a lower slope than it should be.

- Made both of the daily GHz Days graphs on the [URL="http://www.gpu72.com/reports/worker/4d89b8ff781e27a0fe80450cd4cd74b6/"]Individual Stats[/URL] pages have a 30 day moving average rather than an overall running average.

- Added a conditional for the Individual graphs so the X-axis date labels don't bunch up / overwrite for those who have been with the project for while.

- Fell off a Segway at 15 km/h onto coral stone. Three times... Semi-serious abrasions on both arms, and possibly a broken toe... Boy was it fun!!! :smile:

[QUOTE=chalsall;290079]Hey all. Just so people know, over the weekend I:

- Added a "Released Trend" (Linear Regression) line to the Trial Factoring Depth per Day graphs on the [URL="http://www.gpu72.com/reports/overall/graph/month/"]Overall System Progress Graphs[/URL].

- Tweeked the LR lines on the other graphs so the current day is not including in the linear regression. This is to prevent the trend line varying during the day, and tending to be a lower slope than it should be.

- Made both of the daily GHz Days graphs on the [URL="http://www.gpu72.com/reports/worker/4d89b8ff781e27a0fe80450cd4cd74b6/"]Individual Stats[/URL] pages have a 30 day moving average rather than an overall running average.

- Added a conditional for the Individual graphs so the X-axis date labels don't bunch up / overwrite for those who have been with the project for while.

- Fell off a Segway at 15 km/h onto coral stone. Three times... Semi-serious abrasions on both arms, and possibly a broken toe... Boy was it fun!!! :smile:[/QUOTE]
While I really appreciate what you're doing, I think the last item could have been done a bit differently ...