I've finally changed to work estimates to include autocorrelation. For the short term, the change means that the server and your client will overestimate run times until it has averaged the new estimates into your run time stats.

No action on your part is necessary, but let me know if you get totally outrageous run time estimates.

---

Presumably this will apply to newly-split work only.

Do we have any way of knowing how many of the 5,857 tasks ready to send are MB, and how many AP? That would help us to know when to start watching for the new estimates.

Most all of them are SETI@home results. I've been filling the SETI@home send queue up to 4096 then letting it drain to 1024 before starting again. It just finished a fill a couple hours ago.

---

For the ~0.42 AR of the tasks the estimate adjustment is just over a 14% increase, as specified in the code change and as seen on my host 10490. For that 1.4 GHz Pentium-M the estimate change was from 8:36 to 9:49. That's hr:min, but a GPU which is 60 times faster would have similar min:sec change.

With duration correction factor (DCF) being much quicker to react than the server averages, any host which has done 10 or more of the tasks with new rsc_fpops_est probably already has displayed estimates close to real run times. But because the servers ignore DCF the amount of work sent for a request will be somewhat less, perhaps leading to an additional request. Because the servers on average send an extra 1/2 task beyond the request, that effect may be hard to see.

                                                                    Joe

if you get totally outrageous run time estimates.


what constitutes this?

if you get totally outrageous run time estimates.


what constitutes this?

Your host hasn't completed it's 10 non-outlier tasks yet for the CPU MBv7 6.98 app, or the OpenCL Astropulse apps, once it does, the estimates will be close,

Claggy