I see that on this machine LaptopII, I have two WU's running and two WU'e waiting to run. I see nothing in my queue waiting to start.

I also see that a SETI task is set for 37 more hours to finish 6.26.08.

If having a 37 hours to run WU is the cause of my not getting work for other projects on which I wish to work, SETI is toast.

If that would be true of any WU for any project, that project would be toast.

Any comments will be appreciated.

>>RSM

---

http://sciencesprings.wordpress.com
http://facebook.com/sciencesprings

2 jobs running and 2 waiting to run, thus pre-empted, is no reason for panic yet. If it does go into idling one core, not fetching work to keep that busy, feel free and curse, butter the toast and char it.

Are you still using the connect every....x.days or are you now using the cache/additional buffer function to size the backlog? What happens if you increment the cache temporarily by 1 day steps?

Thanks for the question. I left the default .3 days for the connect days. At that time, there was a bad WU which was hung up, I followed the suggestion in messages to abort it, and everything sprang back to life.

Now, this WU from SETI inexplicably had a computational error, and now my queue looks normal again.

It's not that I need to see a long list of WU's, it is rather that I know what ny machine should look like, and when I see something odd, it makes me question what is going on.

Thanks again.

>>RSM

---

http://sciencesprings.wordpress.com
http://facebook.com/sciencesprings

2 jobs running and 2 waiting to run, thus pre-empted, is no reason for panic yet. If it does go into idling one core, not fetching work to keep that busy, feel free and curse, butter the toast and char it.

Are you still using the connect every....x.days or are you now using the cache/additional buffer function to size the backlog? What happens if you increment the cache temporarily by 1 day steps?

So, further to this issue, in both cases, a WU was idling, and normal function was impeded. It was not the length of the WU from SETI that created the problem, it was the fact that it was idling. SETI was removed automatically as the result of a computational error. The other errant WU, from Spinhenge, I had to intervene and abort.

So, this is just another lesson learned, to check in B OINC Manager more often to see what's happening.

Thanks again.

>>RSM

---

http://sciencesprings.wordpress.com
http://facebook.com/sciencesprings

2 jobs running and 2 waiting to run, thus pre-empted, is no reason for panic yet. If it does go into idling one core, not fetching work to keep that busy, feel free and curse, butter the toast and char it.

Are you still using the connect every....x.days or are you now using the cache/additional buffer function to size the backlog? What happens if you increment the cache temporarily by 1 day steps?

Thanks for the question. I left the default .3 days for the connect days. At that time, there was a bad WU which was hung up, I followed the suggestion in messages to abort it, and everything sprang back to life.

Now, this WU from SETI inexplicably had a computational error, and now my queue looks normal again.

It's not that I need to see a long list of WU's, it is rather that I know what ny machine should look like, and when I see something odd, it makes me question what is going on.

Thanks again.

>>RSM

0.3 days is 7.2 hours.

BOINC works on a debt system. If a project has borrowed some CPU time, it will be blocked from downloading any more until most of that debt has been paid off. If your queue is full (or your CPUs are not idle - depending on the version of BOINC) you will not be getting any new work while a task is in any sort of time trouble. This CPU time borrowed to get out of time trouble will be paid back later.

---

BOINC WIKI