Defenitions:

Wallclock or Elapsed or sometimes Run Time: The time it takes for the system to do the job from start to finish.

CPU time: The actual cycles used by the science application to complete a task. For RICE this has a cut-off of 7:00 hours, plus the time it takes to finish the seed that was running at 6:59:59 hours.

I personally detest the confusing Elapsed column as it can entirely mislead to think a job is running smoothly whilst in fact it may get only a fraction of the CPU time... So I use BOINCTasks which shows both to provide the relative profile view.

World Community Grid 6.17 Nutritious Rice for the World R00576_006015ef68d8f49df61deb1a14e4985e_02_006 07:31:12 (07:00:11) 24-02-2010 09:58 24-02-2010 09:59 Reported: Ok

As seen here, it took 7:00:11 hours to compute and 31 more minutes on the wallclock. This system is set to run at 95% throttle (laptop getting too warm)

Laptops getting hot? Clean Clean Clean those dustbunnies that enter over time.

Caching wisdom... well it's standard deadline 10 days, so with an 83% efficiency, the client will only cache 8.3 days worth. If there's too much to not be able to meet the deadline, the client stops fetching work so it's pointless to pump it up any further... you'd see constantly Running, processing High Priority and even job preempting as the client tries to find the quickest jobs (this is slightly better in client version 6.10 where the client learns run times at application level.)

ZoSo,

the batches do not go out sequentially i.e. after 00627 it might jump back to 00620 or whatever. He's loaded the batch already into the system, so it becomes kind of: Whatever the feeders grab. Momentarily I've got new work, normal 10 day deadline jobs intermingled with HCMD2 577, 574, 586, 575. Some work actually waits on first returns in a batch/quorum to optimize the seed numbers computed.

Uplinger in past gave quasi 3,2,1 last days new work warnings, for those on the squeeze. Those are the posts to watch for.

For my laptop it's rather simple, unscrew the CPU and memory cover and some compressed air. Sitting on a notepal with 3 fans, but on really hot days I open up the DVD player slot and if necessary throttle is down further... hi season it goes to 50-60 percent, using ThreadMaster GUI or TThrottle for the automated temp control.

On Dells you can usually pry up the hinge cover with a plastic screwdriver... the heat pipe and fins typically sit just below that (also, some manufacturers have Service Manuals available for download that show disassembly/reassembly with step-by-step pictures).
I find a 1.5" slash-tip nylon bristle paint brush along with the canned air and/or vacuum cleaner helps knock the buildup off fins and fan blades too (and keeps the fans from spinning too fast, which can harm the bushings/bearings).
There is a fan control program for some Dells, also. i8k is the name, I believe - I first saw it in Fedora's repos, but discovered it had originally been a windows program and was ported over.

As far as the work unit sequence numbers, I was only going by what I have seen. I notice a few jump back 10 or 15 counts, but I figured those were re-issues... generally they march right up the count. I haven't really seen them come in batches grossly out-of-order in the upward direction. Looking back on the Messages tab, Sunday I was running 570-576, Monday I ran 574-579, Tuesday 576-585 and so far today I've been running 576-586. In BOINCview's local cache for 15 cores I see 577-587... I would have to look in Results Status to see what the offsite cores have cached. Still, I'll take your word for it that they can jump forward unexpectedly. :-)