Report deadline too short
Anonymous
26 Feb 2005 11:33:36 UTC
Topic 12729
(moderation:
> > Maybe it is really a Boinc problem, for example in my case if the
> resource
> > share is say 16.6% and the cache is 2 (days) it should only download
> enough
> > workunits to terminate them in 8 hours at 100% or less than one unit
> (and
> > maybe a spare), instead it loads 3 units. The third unit will probably
> not be
> > done before the deadline... Of course as the cache size approaches the
> number
> > of days before the deadline it will begin to fail anyway, unless Boinc
> also
> > considers time until deadline when calculating how much to download.
> >
>
> Again, this has been discussed, and I think I saw somewhere that the
> developers were working on it. Right now, the Core Client is the only place
> that knows that you are running multiple projects. The individual project
> schedulers ASSUME (and we both know what that means) tha you are only running
> their project.
Not true. The scheduler gets the 'resource share fraction' associated with the E@H project. Please see the FAQ on the E@H front page.
> The solution, especially if CPDN is one of your projects is to set a connect
> time of .1 or .5 days, and let the multiple projects act as your cache of
> work, rather than caching multiple WUs from each project.
This is reasonable.
Cheers,
Bruce
Report deadline too short
)
> > > Again, this has been discussed, and I think I saw somewhere that
> the
> > > developers were working on it. Right now, the Core Client is the
> only
> > place
> > > that knows that you are running multiple projects. The individual
> > project
> > > schedulers ASSUME (and we both know what that means) tha you are
> only
> > running
> > > their project.
> >
> > Not true. The scheduler gets the 'resource share fraction' associated
> with the
> > E@H project. Please see the FAQ on the E@H front page.
> >
> The resource share is completely insufficient. If all of the other projects
> are down, and Einstein has only 1% of the CPU, it should download a WU and
> start working on it.
If there is NO E@H work queued on a machine, and it is not doing any E@H work, then a request for work will be met with at least one WU, provided that the memory and disk space are available.
> Even though if the shares were carried out strictly,
> that WU would not complete on time. The CLIENT should be intelligent enough
> to be able to schedule the work that it has so that it completes on time, not
> download any more work if it is getting into time trouble, and not download
> work from a project that has been crunching too much recently. BOINC is
> supposed to be a multi project application, but the download and CPU
> schedulers do not handle multi project settings very gracefully.
John, I agree that the Client could be more intelligent in how it requests work, particularly in the situation where not all projects are providing work all the time.
> The client assumes that it can request a full queue from each project. If you
> have 10 projects and ask for a 1 day, your queue will end up with more than 10
> days of work in it. The project server assumes that all projects will be
> providing work all the time. This is also a bad assumption as some projects
> will have work sporadically.
This may be true for the schedulers of other projects. But it is NOT true of the E@H scheduler. If you read the relevant code in sched_send.C (search for estimate_wallclock_time() and read the function calling it) you'll see that the E@H scheduler estimates the wallclock time it will take to complete a job taking into account the resource share. If that's 10% then E@H will only issue 10,000 CPU seconds of work if 100,000 seconds is available. This is a reasonably recent addition to the BOINC generic scheduling code and I don't know which other projects are using it, though I assume that S@H is.
Bruce
> Einstein@Home and SETI@Home
)
> Einstein@Home and SETI@Home are having performance problems with the database.
E@H is not having any performance problems with the database. However we ARE seeing some bugs in BOINC, which cause some WU sent to clients to be lost (meaning that they are sent out of the server, over the network, but never arrive at the host machine).
Bruce