we were speculating someplace else how this could happen, but without access to the hosts/users in question, it's a tad difficult to debug...

Set BOINC activity to suspend & it will happily continue to request work. I'm not sure if tasks that timeout reduce the value of Max tasks per day.

Care to provide a log snippet to back up that claim?

As far as I'm aware BOINC stops workfetch when suspended.

Too early in the morning (and without coffee) to think through the implications of having the cache time out (iirc boinc does clear out tasks that haven't been started when they go past deadline).

Not quite sure if the limit on tasks in progress makes use of the report in the sceduler request - anybody remember if ghosts count towards your quota?

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

I think one problem is (but not confirmed) is new users to SETI likely have a default cache size of 10 days, so they download a boatload of files, then disappear.

It should be 1 or 2 days default, then change it as you see fit.

The default cache setting for BOINC is 0.25+0 days.
However it is fairly easy for a mid range machines to hit the limits with a setting of 1 day.

These days the default cache is 0.1+0.25 days.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

As far as I'm aware BOINC stops workfetch when suspended.

I can think of a scenario where that might not apply - though feel free to expose the the flaw in this argument (I can think of one of those too, but I leave it as an exercise for the reader).

Modern computer equipment is supplied with energy-saving options active (sleep when inactive, that sort of thing). BOINC also comes with defaults like "only run GPU tasks after computer has been idle for 3 minutes". Couple those two together, and you could - conceivably - come up with a powerful computer, perhaps a gaming spec, which is allowed to download tasks, but only runs them for a few minutes a day.

As far as I'm aware BOINC stops workfetch when suspended.

I can think of a scenario where that might not apply - though feel free to expose the the flaw in this argument (I can think of one of those too, but I leave it as an exercise for the reader).

Modern computer equipment is supplied with energy-saving options active (sleep when inactive, that sort of thing). BOINC also comes with defaults like "only run GPU tasks after computer has been idle for 3 minutes". Couple those two together, and you could - conceivably - come up with a powerful computer, perhaps a gaming spec, which is allowed to download tasks, but only runs them for a few minutes a day.

sure. but boinc has mechnisms for that. it's does keep track of uptime and of active time. and that in turn is used to calculated remaining cache.
it _should_ also be taken in account when fetching work - it certainly is when the work arrives.

if not carrying a large cache but processing it at snail's pace could certinly lead to grabbing large amounts of work that don't get done in time.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

sure. but boinc has mechnisms for that. it's does keep track of uptime and of active time. and that in turn is used to calculated remaining cache.
it _should_ also be taken in account when fetching work - it certainly is when the work arrives.

if not carrying a large cache but processing it at snail's pace could certinly lead to grabbing large amounts of work that don't get done in time.

Like

Fraction of time BOINC is running 76.80%
While BOINC is running, fraction of time computer has an Internet connection 99.08%
While BOINC is running, fraction of time computing is allowed 99.70%
While is BOINC running, fraction of time GPU computing is allowed 99.65%

sure. but boinc has mechnisms for that. it's does keep track of uptime and of active time. and that in turn is used to calculated remaining cache.
it _should_ also be taken in account when fetching work - it certainly is when the work arrives.

if not carrying a large cache but processing it at snail's pace could certinly lead to grabbing large amounts of work that don't get done in time.

Like

Fraction of time BOINC is running 76.80%
While BOINC is running, fraction of time computer has an Internet connection 99.08%
While BOINC is running, fraction of time computing is allowed 99.70%
While is BOINC running, fraction of time GPU computing is allowed 99.65%

that looks like you found a place that prints it out. where's that?
much easier than staring at client_state.xml :D

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

that looks like you found a place that prints it out. where's that?
much easier than staring at client_state.xml :D

Yep, it's in host properties web page.
Example:
http://setiathome.berkeley.edu/show_host_detail.php?hostid=4517643

that looks like you found a place that prints it out. where's that?
much easier than staring at client_state.xml :D

Yep, it's in host properties web page.
Example:
http://setiathome.berkeley.edu/show_host_detail.php?hostid=4517643

indeed. but only for your own hosts. thanks a lot!

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

I think one problem is (but not confirmed) is new users to SETI likely have a default cache size of 10 days, so they download a boatload of files, then disappear.

It should be 1 or 2 days default, then change it as you see fit.

. . I think mine was set quite low at install, but that may have been from an earlier installation where I turned it down.

we were speculating someplace else how this could happen, but without access to the hosts/users in question, it's a tad difficult to debug...

Set BOINC activity to suspend & it will happily continue to request work. I'm not sure if tasks that timeout reduce the value of Max tasks per day.

Care to provide a log snippet to back up that claim?

As far as I'm aware BOINC stops workfetch when suspended.

Too early in the morning (and without coffee) to think through the implications of having the cache time out (iirc boinc does clear out tasks that haven't been started when they go past deadline).

Not quite sure if the limit on tasks in progress makes use of the report in the sceduler request - anybody remember if ghosts count towards your quota?

BOINC does not appear to log when activity is changed. I set it from the GUI & used boinccmd --set_run_mode never. Nothing in the log. The only thing that seems to show up is when network activity is suspended.

4/20/2016 1:11:29 PM		Suspending network activity - user request
4/20/2016 1:11:35 PM		Resuming network activity
4/20/2016 1:17:25 PM		Suspending file transfers - an exclusive app is running
4/20/2016 1:18:10 PM		Resuming network activity

However I have manually suspended BOINC while playing games, or automatically from exclusive app, and then come back to find BOINC had downloaded work to chew on. It's most notable when I had set my system to only run AP GPU work and had no tasks. Then after exiting the game find 10-15 tasks to work on.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

BOINC does not appear to log when activity is changed.

Care to set the <suspend_debug> logging flag before your next gaming session?

BOINC does not appear to log when activity is changed.

Care to set the <suspend_debug> logging flag before your next gaming session?

Sure. I just set it to see what the output would look like & with activity suspended I caught this.

4/20/2016 2:20:20 PM		[suspend] net_susp: no; file_xfer_susp: no; reason: unknown reason
4/20/2016 2:20:20 PM	GoofyxGrid@Home	Sending scheduler request: To report completed tasks.
4/20/2016 2:20:20 PM	GoofyxGrid@Home	Reporting 1 completed tasks
4/20/2016 2:20:20 PM	GoofyxGrid@Home	Not requesting tasks: non CPU intensive
4/20/2016 2:20:20 PM		[suspend] net_susp: no; file_xfer_susp: no; reason: unknown reason
4/20/2016 2:20:21 PM		[suspend] net_susp: no; file_xfer_susp: no; reason: unknown reason
4/20/2016 2:20:21 PM	GoofyxGrid@Home	Scheduler request completed
4/20/2016 2:20:21 PM		[suspend] net_susp: no; file_xfer_susp: no; reason: unknown reason

Maybe NCI projects play by different rules, but the tasks for GoofyxGrid@Home are displayed as suspended.
http://i.imgur.com/cx32nKF.png

Just as I was writing this post http://i.imgur.com/GHIwesZ.png

The only thing that seems to change the debug output is suspending network activity.

4/20/2016 2:21:05 PM		[suspend] net_susp: yes; file_xfer_susp: yes; reason: user request
4/20/2016 2:21:05 PM		Suspending network activity - user request
4/20/2016 2:21:06 PM		[suspend] net_susp: yes; file_xfer_susp: yes; reason: user request
<snip>
4/20/2016 2:21:11 PM		[suspend] net_susp: yes; file_xfer_susp: yes; reason: user request
4/20/2016 2:21:12 PM		[suspend] net_susp: no; file_xfer_susp: no; reason: unknown reason
4/20/2016 2:21:12 PM		Resuming network activity
4/20/2016 2:21:13 PM		[suspend] net_susp: no; file_xfer_susp: no; reason: unknown reason

I don't see the details of processing portion of the debug as indicated in the cc_config.xml notes.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I don't see the details of processing portion of the debug as indicated in the cc_config.xml notes.

I'd parse that at "Show details of (processing and network) suspend/resume.", but I'd agree processing is missing - and that's the one we wanted.

I remember there being some discussion about NCI projects in the mailing lists, and I think that there was an eventual decision that they should continue even if notionally suspended. Not a big deal either way.

Certainly seems like we have some digging to do. For the record, which BOINC version is running on the host you were testing - you have several different ones in play.

I don't see the details of processing portion of the debug as indicated in the cc_config.xml notes.

I'd parse that at "Show details of (processing and network) suspend/resume.", but I'd agree processing is missing - and that's the one we wanted.

I remember there being some discussion about NCI projects in the mailing lists, and I think that there was an eventual decision that they should continue even if notionally suspended. Not a big deal either way.

Certainly seems like we have some digging to do. For the record, which BOINC version is running on the host you were testing - you have several different ones in play.

There isn't a lot to parse from that output. Just [suspend] net_susp: no; file_xfer_susp: no; reason: unknown reason every second.

I could see requesting work while processing activity is suspended in order to fill the cache to be acceptable.

That was done with 7.6.23 on host 5837483. Also, for clarity, it is the boinc_7.6.23_windows_x86_64.exe release on the BOINC dl site rather than Ageless's 7.6.23.r build. Looks like I switched from 7.6.23.r to 7.6.23 on March 5th.

There is a flag <dont_suspend_nci>. Which indicates BOINC should allow NCI tasks to keep running in most cases. However when enabling <dont_suspend_nci> I have not found any of those cases where the NCI tasks continue to run. Since I am only running NCI tasks on one host with 7.6.23 I haven't worried to much about it.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Just a thought, a laptop on wireless that loses connection might be a trigger to throw BOINC into some weird state.

. . Finally getting Guppies of the CUDA23 and CUDA50 families. Looks interesting

. . Finally getting Guppies of the CUDA23 and CUDA50 families. Looks interesting

. . Did I speak too soon? Seems to be that the Guppies of the CUDA variety turn out to be mostly noise bombs, at least the ones with MESSIER in their names. That is, early exit after only seconds with the "SETI@Home Informational message -9 result_overflow " message.

. . Noisy part of the sky ?

. . I haven't noticed this trend with the Guppies of the CPU variety.

CPU Guppies als bomb out on my 2 Linux boxes, 32-bit and 64-bit.
Tullio

---

The Guppies sure suck most of them bomb out on me

---

I came down with a bad case of i don't give a crap

CPU Guppies als bomb out on my 2 Linux boxes, 32-bit and 64-bit.
Tullio

. . After writing that I noticed I was getting the Messier variety on the CPU only box and they were doing it too. :(