The lowest available tests are in general the dregs. They have either been:
[LIST][*]released several times[*]released after a long period[*]lengthy test on underpowered hardware meaning more likely suspect[*]there have been faulty tests[*]some combination of the above[/LIST]If one of these conditions wasn't met then they would have been completed long ago.

I wouldn't stress Xyzzy. Your machines did exactly what they are supposed to do. Grab a double check candidate, perform LL, get matching residue - profit!

I was doing DC LL on a GTX440 and after the DC the residues were matching only about 80% of the time. I worked out the power to result ratio wasn't worth it. So it's now offline.

-- Craig

Cool dealio, the "system" works!

:tu:

On the GPU72 Available TF Assignments page, there are currently 977 exponents listed in the 57M range at 73 bit factoring level. Does this indicate that it would be desirable to take these to another level?

[QUOTE=kladner;310689]On the GPU72 Available TF Assignments page, there are currently 977 exponents listed in the 57M range at 73 bit factoring level. Does this indicate that it would be desirable to take these to another level?[/QUOTE]

They're being held for P-1.

[QUOTE=flashjh;310691]They're being held for P-1.[/QUOTE]

OK. Thanks, Jerry. This is an opportunity for me to ask another question. I have a 27M DC assignment, taken to 69 bit factoring, with a B1(=B2?)=415000 P-1. It will take longer for my CuLu queue to get to it than it will for my mfaktc queue to take it to 70. I know I won't get GPU72 credit, only PrimeNet, but is it a worthwhile trade-off to run the additional DCTF before it gets into CuLu?

EDIT: I have assumed that because additional P-1 work would take me much longer that it would not be efficient to go that route. I was just thinking that if I could find a fairly quick factor before running a DC that it would save me work. I am influenced by the experience of having found a surprising number of DC factors in the past.

Proxy Errors
 

Even thought the PrimeNet server "seems" to be up and stable again I still am getting regular errors like: Even though the responses are very quick (sub-second).


[CODE][Comm thread Sep 7 23:23] Updating computer information on the server
[Comm thread Sep 7 23:23] Sending expected completion date for M26291281: Sep 08 2012
[Comm thread Sep 7 23:23] Sending expected completion date for M26557199: Sep 20 2012
[Comm thread Sep 7 23:23] Sending expected completion date for M26610263: Oct 01 2012
[Comm thread Sep 7 23:23] Sending expected completion date for M26615227: Oct 12 2012
[Comm thread Sep 7 23:23] Sending expected completion date for M26615609: Oct 23 2012
[Comm thread Sep 7 23:23] PrimeNet error 3: Server busy
[Comm thread Sep 7 23:23] GPU72_Proxy -- Bad response from PrimeNet. Additional: "500 Server closed connection without sending any data back"
[Comm thread Sep 7 23:23] Visit http://mersenneforum.org for help.
[Comm thread Sep 7 23:23] Will try contacting server again in 70 minutes.[/CODE]

Something seems to have messed up today... when I checked my stats it said I completed 11k GHzD today.

[QUOTE=kladner;310692]I am influenced by the experience of having found a surprising number of DC factors in the past.[/QUOTE]

Did it, but no cigar. Running the DC now.

[QUOTE=bcp19;310827]Something seems to have messed up today... when I checked my stats it said I completed 11k GHzD today.[/QUOTE]

Hmmm.... Interesting.

The candidate in question, 58256111, has been "owned" by the system for some time. It was assigned to you on "2012-09-08 12:33:30" to TF from 72 to 73, even though it had already been factored by way of P-1. I'm not sure why -- the system should have picked up that the candidate was cleared.

The reason you were given so much credit is the system thought you had found a 106 bit factor by TFing... I've removed the erroneous record -- your graphs and other stats should be back to being correct.

I'll have to do an audit of the code which should clear candidates in such cases -- although no changes have been made to that code in months. Unfortunately I'm scrambling on another project at the moment -- the big presentation is during a week-long session next week.

Edit: Sorry -- it's late... I forgot to mention that the P-1 factor was found by someone the candidate was not assigned to by GPU72. Probably a recycled candidate which the original assignee submitted the result for months later.

[QUOTE=petrw1;310696]Even thought the PrimeNet server "seems" to be up and stable again I still am getting regular errors like: Even though the responses are very quick (sub-second).[/QUOTE]

Yes, Primenet was having intermediate issues for a large part of the day yesterday.

Just so everyone knows, the error message you saw was the GPU72 proxy telling your client that although it was talking to the proxy OK, the proxy was immediately getting errors when it was talking to Primenet.