Hi Sekerob,

I do not have checkpoint debugging enabled, so I've been looking at the checkpoint files in the slot directory for the unit. Here's the current stats:

CPU time: 1 day, 8 hours, 38 minutes, 11 seconds.
Progress: 4.402%
Current time: 07:26
All checkpoint files show a time of 03:47 earlier this morning.

Last night, when I made the original post, the two checkpoint files (00 and 01) had different times showing, which is how I was able to track when the last checkpoint occurred. If memory serves, I checked the progress around 19:33, and the checkpoint 01 file was showing a time of 15:20, give or take a few minutes.

Incidentally, it's not like this system is underpowered. It's a 1.4GHz P3S, with the double cache. What's more, there's two of those CPUs, both running at 97-99% utilization for BOINC, with 4GB of RAM for them to play with. Benchmarking indicates that it has better floating point performance than all three of my P4s, and better integer performance than two of them. I know benchmarks can be misleading, and I've heard that BOINC's benchmarking in particular has been a little wacky. However, all of these machines are running the same version, so I'd think the wackiness would even itself out, unless it was a flat-out bias towards older machines.

EDIT: I have now activated checkpoint debugging on the machine in question. I'll report back as things develop (or don't).

But I'm not looking at P3s at this stage. They crashed out on 611, so all machines then were P4 and upwards. If my P4 takes 21 hours for one position, then the average time for an average P4-and-above looks like 15 hours. Yes, a fast P3 might be around 40 hours, but even 15 hours is kinda long.

It'll be interesting to see what will happen to this WU and to TXR13's. Even if our machines run the distance, will we ever get validation? It'll be pretty disappointing if they hit boinc's cpu time limit and abort.

I'd expect for a position always being allowed to finish no matter what, not a an exact 4 or 8 hour, or dead close as what RICE is programmed to do, with very short seeds.

TXR13, I think it's a choice. When you've checked in the quorum detail if the wingman finished the task and how, your job still making progress, you could decide to abort and let some other power horse try the run.

My clients now done many hundreds and yet to come across a monster, touch wood, thus they must be more rare than the discussions suggests.

If only the techs could predict this it would have been a whole lot easier to size the jobs. Let it run as the tasks are allowed to overrun 100x their original predicted runtime.

See my previous post above and find <rsc_fpops_est> in the client_state.xml (DON'T meddle with that file or you'll be served the penalty of a corrupted client!)

Just checking, if you find a task, say FLU and it has
<rsc_fpops_est>11145059248785.000000</rsc_fpops_est> all other jobs in the queue of the same date/project will have the same value. The servers compute this projected run time daily from actual returned work which is then used for new work send out. Somewhere there's a formula which allows the calculation back into seconds. The current benchmark values are part of that formula. My crawler currently computed 8:59 hours from that fpop value and 8:54 after forcing a new benchmark, hurray.