> It doesn't seem sensible to treat a WU processing exe as a WU - I'd expect the
> exe to be downloaded on attaching to a project, and then any WUs download as
> needed.

Makes sense to me.

One of the neat things about BOINC is it's flexibility. It is capable of supplying on demand project .exes. This means the framework isn't locked into any sort of specifics about the task at hand.

As such, when you attach, it is unknown to the CC what the current project app may be. This is the realm of the scheduler. After you attach and the scheduler decides what to give you, then it hands you the .exe du jour along with your WUs. (assuming of course the work splitters even become capable of dealing with the demand)

> I have to disagree with you on this one. I don't think there is any other way
> to do it that will be as effecient without adding some major programing. You
> can't just use first in first out because some projects may need the work
> returned sooner. This may even crop up within a single project where some work
> needs to be done sooner than other work. By working down the deadlines all the
> projects get their work done in as timely a fashion as possible. If the
> deadline is so long as to let the work sit in the queue that just means that
> there isn't the time pressure for that particular workunit and it will be
> there for the client to run if there is a problem getting more work. However
> whatever happens BOINC will get it back to the project by the time it is
> needed. To me that is a benifit for both the client and the project.

The problem with this is on multiple CPU machines that are willing to attach to a long crunch time project that nessecarily has a long deadline to cope with the long crunch time. If the machine has 4 CPUs, and the cache is set to say 1 1/2 weeks, and the WU will take less than 6 weeks, it will be starved until it has no hope of finishing by WUs that have 2 week deadlines. I believe that the projects should be able to set a maximum cache size so that if a user attaches to a project, the cache waould be lowered to the minimum of the allowed cache size, and the requested cache size. This allows F@H to have a 5 day turnaround, and CPDN to have 5+ week crunch times. At this point you could safely use FIFO.

Can anyone tell me why all the unhappy "crunchers" have not gone back to classic SETI? It appears the project managers left it there specefically for that purpose. I made the switch to BOINC and have had the same problems everyone else has had. I know the problems exist and choose to stay on the program until they are fixed. If these unresolved issues caused me as much stress as it does some people, I am pretty sure I'd just go back to what works and not worry about it while other, more patient "crunchers", tolerated the problems until they are fixed.

Ron

Can anyone tell me why all the unhappy "crunchers" have not gone back to classic SETI? It appears the project managers left it there specefically for that purpose. I made the switch to BOINC and have had the same problems everyone else has had. I know the problems exist and choose to stay on the program until they are fixed. If these unresolved issues caused me as much stress as it does some people, I am pretty sure I'd just go back to what works and not worry about it while other, more patient "crunchers", tolerated the problems until they are fixed.

Ron

> Can anyone tell me why all the unhappy "crunchers" have not gone back to
> classic SETI? It appears the project managers left it there specefically for
> that purpose. I made the switch to BOINC and have had the same problems
> everyone else has had. I know the problems exist and choose to stay on the
> program until they are fixed. If these unresolved issues caused me as much
> stress as it does some people, I am pretty sure I'd just go back to what works
> and not worry about it while other, more patient "crunchers", tolerated the
> problems until they are fixed.

Because there's uncertainty over whether or not recognition will be given for processing WUs using SETI classic. The docs say that the classic stat's, as displayed in your account details, won't be updated.

BOINC hit the low-water mark and requested more work from SETI. I thought, "hurray - might actually get to download the exe and process a WU". The SETI scheduler didn't respond so BOINC downloaded several WUs from Predictor@Home instead. Grrrrrrrr. Just when I think I'm getting somewhere, BOINC displays a new "feature". I suppose, on the positive side, BOINC is punishing SETI for failing to respond :P


j

> > I can understand why there
> > might not be any WUs, but I can't understand why the client exe hasn't
> > downloaded. Surely that download and the provision of that download
> should be
> > seperate from that of the WUs??
> >
> > [edit] Simply put - do the mechanisms that provide and control WUs also
> > provide and control project exe downloads? And if so, should they?
>
> Yes they do. A project .exe isn't downloaded until it's needed. If you haven't
> actually received any WUs, you won't have the .exe. When you actually get some
> Wus, it will be downloaded along with them.
>


The BOINC client does not download a project .exe until it gets a work unit from that project because *each* work unit is tagged with the name of the specific project .exe it requires for processing. Prior to getting a work unit from a project, the BOINC client does not know WHICH .exe to get from that project. When the BOINC client notices a work unit is being downloaded which requires a project .exe it does not yet have, it will download it alongside the work unit. This was done to assist in supporting multiple kinds of work units coming from a single project. If your computer is not capable (too slow, etc.) of processing one particular kind of work unit from a project, there is no real need to maintain a current copy of that particular project .exe.

If you are running on windoze, you can see which project .exe each work unit in your cache requires by looking in the 'application' column on the 'work' tab.

Hmmm.... Could have sworn I said this a few posts above. ;-)

> The BOINC client does not download a project .exe until it gets a work unit
> from that project because *each* work unit is tagged with the name of the
> specific project .exe it requires for processing. Prior to getting a work
> unit from a project, the BOINC client does not know WHICH .exe to get from
> that project. When the BOINC client notices a work unit is being downloaded
> which requires a project .exe it does not yet have, it will download it
> alongside the work unit. This was done to assist in supporting multiple kinds
> of work units coming from a single project. If your computer is not capable
> (too slow, etc.) of processing one particular kind of work unit from a
> project, there is no real need to maintain a current copy of that particular
> project .exe.
>
> If you are running on windoze, you can see which project .exe each work unit
> in your cache requires by looking in the 'application' column on the 'work'
> tab.