I had a SETI WU stuck on around 50%. CPU /and/ Time To Completion both kept increasing but the 50% has only increased by about 5% all day. A WU normally takes 20 hrs at the most. I detached the SETI project because there's no way to manage WUs (delete, restart), which would be nice, and reattached it. No new WUs have been downloaded and BOINC is now processing a WU for another project but that seems to be doing a similar thing. What happened?

j

> I had a SETI WU stuck on around 50%. CPU /and/ Time To Completion both kept
> increasing but the 50% has only increased by about 5% all day. A WU normally
> takes 20 hrs at the most. I detached the SETI project because there's no way
> to manage WUs (delete, restart), which would be nice, and reattached it. No
> new WUs have been downloaded and BOINC is now processing a WU for another
> project but that seems to be doing a similar thing. What happened?
>
> j
>
>

It's called "how this stuff (crap) works". Seems the first part of a WU may process very fast, and then slow down. You'll have bad numbers in "to completion" until the WU is really complete (100% + 5 minutes is what I've seen)

They've known about this in beta for months (6?) but didn't put it on the list to fix for the launch...
[/url]

Yeap thats right
The first 40 odd % goes really fast, then the rest is the long part :)

> Yeap thats right
> The first 40 odd % goes really fast, then the rest is the long part :)
>

Yeah I noticed that but over the course of a day progress should have advanced more than 5%.

Despite detaching and reattaching the SETI@Home project three times, I can't get it to download any WUs. The project directory under the main BOINC directory is empty, so it hasn't even downloaded the client. I don't know whether to give up on BOINC, go back to the old recognitionless SETI@Home, or forget the whole thing. I tried the command line BOINC client and it trashed three of my Predictor@Home WUs and crashed. It doesn't look like anything made it past Alpha stage let alone Beta.


j

When it's running, is it using 100% cpu usage?

> When it's running, is it using 100% cpu usage?
>

Well it's not running (SETI that is) at the mo but when it does it's usually around 75%. A WU should take no more than 20 hrs.

I'm guessing that the ongoing problems are preventing BOINC from downloading the SETI project client properly.


j

Worse than getting no work units is the problem I have been seeing where you attempt to look at the various "tabs" and the GUI seems like it does not want to change. I am not sure yet what causes this but it is annoying.

My first suspicion was/is that the log-file is getting too long and this causes problems.

I also started running Predictor because of the problems getting SETI WU, I have the settings set for 95% SETI and 5% predictor and it seems that all I get are predictor WU.

Its a shame that project is still in "alpha" state, I would feel a lot better if it was "released" and I knew that my work was not going to waste.

> Worse than getting no work units is the problem I have been seeing where you
> attempt to look at the various "tabs" and the GUI seems like it does not want
> to change. I am not sure yet what causes this but it is annoying.
>
> My first suspicion was/is that the log-file is getting too long and this
> causes problems.
>
> I also started running Predictor because of the problems getting SETI WU, I
> have the settings set for 95% SETI and 5% predictor and it seems that all I
> get are predictor WU.
>
> Its a shame that project is still in "alpha" state, I would feel a lot better
> if it was "released" and I knew that my work was not going to waste.
>

I got the feeling that there are issues with BOINC and multiple projects. I wonder if and how well BOINC was tested with multiple projects. At the moment I'm still without the SETI client - I have a project entry but no client to crunch WUs and no WUs neither. So BOINC is just working on Predictor@Home. I have BOINC set to 50/50 SETI/Predictor - I've no idea what "Resouce Share" refers to, since only one WU can be processed at a time (on a single CPU machine) and disk space usuage is controlled on a per-project basis.


j

> I got the feeling that there are issues with BOINC and multiple projects. I
> wonder if and how well BOINC was tested with multiple projects. At the moment
> I'm still without the SETI client - I have a project entry but no client to
> crunch WUs and no WUs neither. So BOINC is just working on Predictor@Home. I
> have BOINC set to 50/50 SETI/Predictor - I've no idea what "Resouce Share"
> refers to, since only one WU can be processed at a time (on a single CPU
> machine) and disk space usuage is controlled on a per-project basis.

It was tested and seemed to work for those that were sharing between alpha and beta projects. I am having a similar problem but am planning to see if it works out of the hole naturally. Theory says it should. :)

Yuo can read more about it in these:

As part of an "unofficial" effort to document the SETI@Home Powered by BOINC, the following documents have been written to aid you in the use of SETI@Home Powered by BOINC:

Documentation Menu (pdb)
Release Notes =

Thanks! Paul ...

Look in the glossary for resource share and it will tell you all about it... I am still racing madly to get the links updated and the new pictures in ... so it is a little awkward at the moment, I am posting about 150 changes, usually twice a day... anyway ...

> I got the feeling that there are issues with BOINC and multiple projects. I
> wonder if and how well BOINC was tested with multiple projects. At the moment
> I'm still without the SETI client - I have a project entry but no client to
> crunch WUs and no WUs neither. So BOINC is just working on Predictor@Home. I
> have BOINC set to 50/50 SETI/Predictor - I've no idea what "Resouce Share"
> refers to, since only one WU can be processed at a time (on a single CPU
> machine) and disk space usuage is controlled on a per-project basis.

As Paul mentioned, the multi-project ability was only something that the alpha team got to play with. Beta only got a very limited exposure before the project went "live".

As for the resource share, that is how the CPU time is divided between projects. After a queue is completed, the scheduler decides what project it should feed you next, reflected by your resource share. In a low watermark situation, it is not uncommon to have queues from more than one project on your machine, although the entire queue from the current project will be completed before moving to the next queue.

> As for the resource share, that is how the CPU time is divided between
> projects. After a queue is completed, the scheduler decides what project it
> should feed you next, reflected by your resource share. In a low watermark
> situation, it is not uncommon to have queues from more than one project on
> your machine, although the entire queue from the current project will be
> completed before moving to the next queue.
>
Close, but not quite on the queue. WUs in the queue are crunched in the order of the deadline. Since most of the projects to date have 2 week deadlines, it is true that for these, the queues will empty in the order that they were added. Predictor had for a while WUs with very long deadlines, and these sorted to the end of the queue until something happened to empty the queue.

> > As for the resource share, that is how the CPU time is divided between
> > projects. After a queue is completed, the scheduler decides what project
> it
> > should feed you next, reflected by your resource share. In a low
> watermark
> > situation, it is not uncommon to have queues from more than one project
> on
> > your machine, although the entire queue from the current project will be
> > completed before moving to the next queue.
> >
> Close, but not quite on the queue. WUs in the queue are crunched in the order
> of the deadline. Since most of the projects to date have 2 week deadlines, it
> is true that for these, the queues will empty in the order that they were
> added. Predictor had for a while WUs with very long deadlines, and these
> sorted to the end of the queue until something happened to empty the queue.
>

Just read the explanation in Paul's glossary - God help lay users is all I can say :) So the reason why I have no SETI client at the moment could be due to the way the resource system works? Or does the system only apply to work units? I know the scheduler is down but I'm now not certain that that's the reason why there's no client.

j

> Close, but not quite on the queue. WUs in the queue are crunched in the order
> of the deadline. Since most of the projects to date have 2 week deadlines, it
> is true that for these, the queues will empty in the order that they were
> added. Predictor had for a while WUs with very long deadlines, and these
> sorted to the end of the queue until something happened to empty the queue.

I was speaking in regards to multiple projects. If a queue from another project is downloaded (say from Predictor) while you are running (say S@H) you will complete the S@H queue before moving to the Predictor queue. I believe this will be the case regardless of what the WU deadlines for the next project in the queue may be.

Are you saying you've seen otherwise John?

> Just read the explanation in Paul's glossary - God help lay users is all I can
> say :) So the reason why I have no SETI client at the moment could be due to
> the way the resource system works? Or does the system only apply to work
> units? I know the scheduler is down but I'm now not certain that that's the
> reason why there's no client.

That depends...

If you had been running a project for several months then attached to a new project, the new project is expected to more or less comandeer BOINC for a week or two until it (very roughly) makes up for the resource share.

However, if you haven't done any processing for S@H at all, I do not believe this to be the reason you aren't getting work.

> > Just read the explanation in Paul's glossary - God help lay users is all
> I can
> > say :) So the reason why I have no SETI client at the moment could be due
> to
> > the way the resource system works? Or does the system only apply to work
> > units? I know the scheduler is down but I'm now not certain that that's
> the
> > reason why there's no client.
>
> That depends...
>
> If you had been running a project for several months then attached to a new
> project, the new project is expected to more or less comandeer BOINC for a
> week or two until it (very roughly) makes up for the resource share.
>
> However, if you haven't done any processing for S@H at all, I do not believe
> this to be the reason you aren't getting work.
>

Well like I said in my original post - SETI was working fine (I even managed to get some credit), then it seemed to get stuck. I detached and reattached the project and nothing happened. I've tried about 3 or 4 times now and each time, nothing. C:[slash]Program Files[slash]BOINC[slash]projects[slash]setiathome.berkeley.edu is empty - there's no client exe for SETI. Given that the scheduler is down and also taking into account the way resources are handled, 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?


j

> I was speaking in regards to multiple projects. If a queue from another
> project is downloaded (say from Predictor) while you are running (say S@H) you
> will complete the S@H queue before moving to the Predictor queue. I believe
> this will be the case regardless of what the WU deadlines for the next project
> in the queue may be.
>
> Are you saying you've seen otherwise John?
>
I haven't seen it yet, but only because I haven't gotten any S@H WUs on that machine for a week or so. I was also speaking of multiple projects. There is only one queue. A short crunch time WU with a long deadline can hang out in your queue until it nears its deadline. A long crunch time WU will tend to fill the queue, so tht everything in front of it gets processed, and then it gets crunched.

> 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.

> I haven't seen it yet, but only because I haven't gotten any S@H WUs on that
> machine for a week or so. I was also speaking of multiple projects. There is
> only one queue. A short crunch time WU with a long deadline can hang out in
> your queue until it nears its deadline. A long crunch time WU will tend to
> fill the queue, so tht everything in front of it gets processed, and then it
> gets crunched.

This is pretty illogical operation...

What then is the point of sending out a WU that will only (at least has the potential to) sit in a hosts queue for a couple weeks? (other than adding database entries that the project must maintain, (using precious resources) and placing a doorstop on the hosts HD)

This "feature" appears useful to no one. Doesn't benefit the host or the project...

Parts of this project appear brilliant, other parts, (to be blunt) are *$&%#! (much like the fact that "reset" doesn't expire sent WUs, and they must wait until the deadline is met to be added to the pool)

> > I haven't seen it yet, but only because I haven't gotten any S@H WUs on
> that
> > machine for a week or so. I was also speaking of multiple projects.
> There is
> > only one queue. A short crunch time WU with a long deadline can hang out
> in
> > your queue until it nears its deadline. A long crunch time WU will tend
> to
> > fill the queue, so tht everything in front of it gets processed, and then
> it
> > gets crunched.
>
> This is pretty illogical operation...
>
> What then is the point of sending out a WU that will only (at least has the
> potential to) sit in a hosts queue for a couple weeks? (other than adding
> database entries that the project must maintain, (using precious resources)
> and placing a doorstop on the hosts HD)
>
> This "feature" appears useful to no one. Doesn't benefit the host or
> the project...
>
> Parts of this project appear brilliant, other parts, (to be blunt) are
> *$&%#! (much like the fact that "reset" doesn't expire sent WUs, and they
> must wait until the deadline is met to be added to the pool)
>
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.

John Keck
BOINCing since 2002/12/08

When I got up this morning I checked BOINC and it was doing nothing - said that a WU was running but the CPU time was --- Restarted BOINC and the WU started running. It's high maintenance is this BOINC :)

So from what's been said, there are interdependancies between supposedly separate projects in that the speed at which average credit is calculated, the availability of WUs and the deadline given to a WU all affect the management of the BOINC queue, regardless of where the WUs in the queue originate from. This means that one project can negatively impact on another project?

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.


j