Fully agreed. But remember that you have to follow the logic and also re-instate the DCF code on that project's server.
Say you set work fetch limits of 0.5 days minimum and 0.5 days additional - or a target work buffer: 43200.00 + 43200.00 sec Once TrainWreck@home (eventually) becomes the highest priority project and your client issues a work request, it will request 43200 seconds of work. The *server*, which currently ignores DCF in its calculations, will still use the 1hr 17mn estimation - 4620 seconds. The server will assign 10 jobs to fill the request. Once those 10 jobs arrive at the client, they will be re-estimated by the client using DCF, which by then will be about 19.27 And your client will announce that it has received 10 days 7 hours of new work. And no doubt panic. [I am assuming that TrainWreck@home's previous batch of work for this application was correctly estimated, and that John has volunteered for TrainWreck@home for long enough to have an established and stable APR for HitTheBuffers v1.01] >________________________________ > From: "McLeod, John" <[email protected]> >To: "[email protected]" <[email protected]> >Sent: Wednesday, 3 April 2013, 13:40 >Subject: [boinc_dev] The reason for a local DCF. > >I am currently watching a train wreck that would not be happening if DCF was >turned on for a particular project. > >The initial estimate is a wall time of one hour seventeen minutes. The actual >wall time is twenty four hour 44 minutes. The problem is that work fetch and >the scheduler do not know that the problem exists for tasks #2 through #20 and >are downloading work from other projects, not realizing that the saturated >time is 20 days and not 20 hours. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
