David Anderson wrote on 17/07/2009 20:24: > Thanks - I figured out why yesterday's attempt didn't work, > and checked in a new attempt:
That seems to have fixed the CPU work fetch problems David (no CUDA on any of my systems). > - client: 2nd try on my last checkin. > We need to estimate 2 different delays for each resource type: > 1) "saturated time": the time the resource will be fully utilized > (new name for the old "estimated delay"). > This is used to compute work requests. > 2) "busy time": the time a new job would have to wait > to start using this resource. > This is passed to the scheduler and used for a crude deadline > check. > Note: this is ill-defined; a single number doesn't suffice. > But as a very rough estimate, I'll use the sum of > (J.duration * J.ninstances)/ninstances > over all jobs that miss their deadline under RR sim. > > Ian Hay wrote: >> David Anderson wrote on 16/07/2009 22:24: >>> I checked in the following change, >>> which may solve the problem described below. >> >> Afraid that didn't work David. I patched your change into my 6.6.37 >> build and a scheduler request for 0 seconds CPU and CUDA work was sent >> to CPDN on every work fetch cycle (RSC_WORK_FETCH::choose_project() >> decides that the project is in CPU major shortfall; see attached debug). >> >> When I disabled work fetch for CPDN the same 0 second work request >> cycle started happening for CPDN Beta and WCG. >> > _______________________________________________ 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.
