[QUOTE=Prime95;551960]I did not implement GEC for CERT work. I did not think it was worth the bother. What I did implement was shift count. If one CERT fails another is run with a different shift count.[/QUOTE]

Alternativelly to using the shift count you could vary the "random" used to generate the CERT task.

Minor issue. When running a cert, Prime95 appears to not report calculation progress. Have had it running 2 certs with no updates in greater than 14 hours.

[QUOTE=Uncwilly;552075]Minor issue. When running a cert, Prime95 appears to not report calculation progress. Have had it running 2 certs with no updates in greater than 14 hours.[/QUOTE]

What is OutputIterations set to in prime.txt?

OutputIterations=500000

[QUOTE][Jul 29 12:55] Iteration: 1500000 / 8xxxxxx [17.45%], ms/iter: 5.919, ETA: 11:39:47
[Jul 29 13:42] Iteration: 2000000 / 8xxxxxx [23.27%], ms/iter: 5.594, ETA: 10:14:47[/QUOTE]
vs
[QUOTE][Jul 28 07:17] Stopping PRP test of M8xxxxxx/yyyyyyyyy at iteration 3375128 [39.28%]
[Jul 28 07:17] Starting certification of M97xxxxxx using Pentium4 FFT length 5376K, Pass1=896, Pass2=6K, clm=4, 4 threads
[Jul 28 20:32] Stopping certification of M97xxxxxx at iteration 324739 [85.47%]
[Jul 28 20:32] Resuming certification of M97xxxxxx using Pentium4 FFT length 5376K, Pass1=896, Pass2=6K, clm=4, 4 threads
[Jul 28 22:50] M97xxxxxx certification hash value BigLongHexValue[/QUOTE]

[QUOTE=Uncwilly;552089]OutputIterations=500000[/QUOTE]Everything looks normal. You haven't done 500k iterations on the cert yet.

----------------------------------------------------------------

But this reminds me. Can that setting be set to seconds instead of iterations? Say:
OutputIterations=3600s
Iteration times are variable, but seconds ain't, so 3600 seconds (1 hour) means regularly timed updates no matter how large or small the exponent is.

[QUOTE=retina;552090]Everything looks normal. You haven't done 500k iterations on the cert yet.[/QUOTE]

Never will, either, if 324739 iterations is 85.47% done.

I second the idea of being able to produce it in seconds vs iterations.

[QUOTE=retina;552090]Iteration times are variable, but seconds ain't, so 3600 seconds (1 hour) means regularly timed updates no matter how large or small the exponent is.[/QUOTE]Test type can make it variable too.

I realised that the per iteration output was normal as I was composing my previous message. I posted it anyway just so that it was clear that all was normal.

What system are you using that is running Pentium 4 ffts?

It is a laptop. It was a cheap refurb.

The 1.4 GHz days credit is not nearly in proportion to the actual calc invested.
4 cores x 1.6 Ghz x 3/4 days =/= 1.4 Ghz/days

upgraded from version 29 to 301b1 despite having between 2 and 10 days of work in the queue for 4 cores, to see how it was dealing with regular cases.

This was at 04:24 UTC.

Was immediately issued a cert, and it was assigned to core 1 which had about 10 more days of work on it. Even more surprising: a little bit later when prime95 went to communicate to the server, it shut down the threads, started working on the cert, and queued the DC I was doing behind it.

Got a message immediately following the "Starting cert.." message:
MD6 of downloaded residue does not match
At which point I realized that it had pulled through the GPU72 Proxy. Crap.

It finished the cert this morning and then went back to doing the work it had been previously assigned. Another thread was assigned PRP work because it only had 2 days of work left on it. The new PRP work was queued appropriately and will start tommorow.

[QUOTE=Aramis Wyler;552092]
I second the idea of being able to produce it in seconds vs iterations.[/QUOTE]

Buried in undoc.txt is some kind of option that will do roughly that. It is not nearly as elegant as output every N minutes.