I've been running SETI and ClimatePrediction for quite a while now, but recently I've noticed my computer is sluggish when I stop the (non-BOINC) screensaver and enter my password. I often have to manually stop a task called "astropulse...", which is running at over 50% on my twin-core system. This never happens with the other project. I've checked the options locally and on the servers for both projects, and all should pause.

I'm running 7.0.28 on Vista 32-bit. The first part of my log is:

28/12/2012 17:51:55 |  | No config file found - using defaults
28/12/2012 17:51:56 |  | Starting BOINC client version 7.0.28 for windows_intelx86
28/12/2012 17:51:56 |  | log flags: file_xfer, sched_ops, task
28/12/2012 17:51:56 |  | Libraries: libcurl/7.25.0 OpenSSL/1.0.1 zlib/1.2.6
28/12/2012 17:51:56 |  | Data directory: C:\ProgramData\BOINC
28/12/2012 17:51:56 |  | Running under account Charlie
28/12/2012 17:51:56 |  | Processor: 2 GenuineIntel Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz [Family 6 Model 15 Stepping 13]
28/12/2012 17:51:56 |  | Processor: 2.00 MB cache
28/12/2012 17:51:56 |  | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 nx lm tm2 pbe
28/12/2012 17:51:56 |  | OS: Microsoft Windows Vista: Home Premium x86 Edition, Service Pack 2, (06.00.6002.00)
28/12/2012 17:51:56 |  | Memory: 3.00 GB physical, 9.50 GB virtual
28/12/2012 17:51:56 |  | Disk: 325.05 GB total, 65.15 GB free
28/12/2012 17:51:56 |  | Local time is UTC +0 hours
28/12/2012 17:51:56 |  | NVIDIA GPU 0: GeForce 8400 (driver version 306.97, CUDA version 5.0, compute capability 1.1, 256MB, 152MB available, 31 GFLOPS peak)
28/12/2012 17:51:56 |  | OpenCL: NVIDIA GPU 0: GeForce 8400 (driver version 306.97, device version OpenCL 1.0 CUDA, 256MB, 152MB available)
28/12/2012 17:51:56 | climateprediction.net | URL http://climateprediction.net/; Computer ID 891802; resource share 10
28/12/2012 17:51:56 | SETI@home | URL http://setiathome.berkeley.edu/; Computer ID 4499642; resource share 10
28/12/2012 17:51:56 | SETI@home | General prefs: from SETI@home (last modified 29-Sep-2012 10:35:15)
28/12/2012 17:51:56 | SETI@home | Computer location: home
28/12/2012 17:51:56 | SETI@home | General prefs: no separate prefs for home; using your defaults
28/12/2012 17:51:56 |  | Reading preferences override file
28/12/2012 17:51:56 |  | Preferences:
28/12/2012 17:51:56 |  | max memory usage when active: 1535.26MB
28/12/2012 17:51:56 |  | max memory usage when idle: 1535.26MB
28/12/2012 17:51:56 |  | max disk usage: 20.00GB
28/12/2012 17:51:56 |  | don't compute while active
28/12/2012 17:51:56 |  | don't use GPU while active
28/12/2012 17:51:56 |  | suspend work if non-BOINC CPU load exceeds 30 %
28/12/2012 17:51:56 |  | (to change preferences, visit the web site of an attached project, or select Preferences in the Manager)
28/12/2012 17:51:56 |  | Not using a proxy
28/12/2012 17:52:13 |  | Suspending computation - computer is in use
28/12/2012 17:52:13 |  | Suspending network activity - computer is in use
28/12/2012 17:54:58 |  | Resuming network activity
28/12/2012 17:54:58 | climateprediction.net | Restarting task hadcm3n_3juh_1940_40_008259612_0 using hadcm3n version 607 in slot 2

Any help would be appreciated
Thanks
YJ

You're saying the climateprediction app always suspends when it should but the astropulse app does not? Interesting. That would suggest SETI has given over to the dark side and is now a rogue project along with T4T and Milkyway.

I've been running seti@home since last century without problem. This has only started in the past few months. If I'm the only one reporting this, it looks like it might be an issue with my BOINC settings rather than the project. Just wish I knew what...

Show us a part of the log where both a CPDN model and an AP run and then you go active on the computer. Now we don't see anything about that. If need be, check for past logs in the stdoutdae.txt log file in your data directory.

Apropos, there have been fixes to BOINC lately to make sure applications really get exited when BOINC gives either a kill or suspend command. But these fixes are in versions after 7.0.28, so unless you want to test the latest available alpha version, you won't see any fixes towards this.

To get the latest alpha, see the development version at http://boinc.berkeley.edu/download_all.php

---

Best to set the set the <cpu_sched> debug logging flag while testing this, so that you can see explicit messages like

08/01/2013 13:32:46 | GPUGRID | [cpu_sched] Preempting 34px4-NOELIA_hfXA-21-30-RND8601_0 (removed from memory)

when they do - or don't - happen.

BOINC has been running since 28/12, but I can't easily find a CPDN pause. This is the log from this morning from either side of the time when I killed the astropulse task sometime after midday local and posted the question on here:

08/01/2013 07:57:29 | SETI@home | Started download of ap_25oc12ab_B3_P0_00285_20130107_25263.wu
08/01/2013 08:01:02 | SETI@home | Finished download of ap_25oc12ab_B3_P0_00285_20130107_25263.wu
08/01/2013 08:01:02 | SETI@home | Starting task ap_25oc12ab_B3_P0_00285_20130107_25263.wu_0 using astropulse_v6 version 604 (opencl_nvidia_100) in slot 1
08/01/2013 08:01:38 |  | Suspending computation - CPU is busy
08/01/2013 08:01:48 |  | Resuming computation
......
Lots of these
...
08/01/2013 12:01:39 |  | Suspending computation - CPU is busy
08/01/2013 12:01:49 |  | Resuming computation
08/01/2013 12:01:59 |  | Suspending computation - CPU is busy
08/01/2013 12:02:02 |  | Suspending network activity - computer is in use
08/01/2013 12:06:42 | SETI@home | Computation for task ap_25oc12ab_B3_P0_00285_20130107_25263.wu_0 finished
08/01/2013 12:54:48 |  | Resuming network activity
08/01/2013 12:54:48 | SETI@home | Started upload of ap_25oc12ab_B3_P0_00285_20130107_25263.wu_0_0
08/01/2013 12:54:52 | SETI@home | Finished upload of ap_25oc12ab_B3_P0_00285_20130107_25263.wu_0_0
08/01/2013 12:55:13 |  | Resuming computation

There appears to be nothing in the log for the time I killed it - do the tasks cache log entries? Reading the log (for the first time in ages!) I also notice several days of errors in CPDN, so I've reset the project as suggested. I don't really know what to look for in a regular "pause", so am struggling to find one for CPDN...

Best to set the set the <cpu_sched> debug logging flag while testing this, so that you can see explicit messages like

08/01/2013 13:32:46 | GPUGRID | [cpu_sched] Preempting 34px4-NOELIA_hfXA-21-30-RND8601_0 (removed from memory)

when they do - or don't - happen.

Sorry, just noticed your post - too busy working through the earlier one. I didn't have a cc_config.xml file, so I've created one in ProgramData/BOINC and just populated it with:

<cc_config>
   <log_flags>
       <cpu_sched>1</cpu_sched>
       <cpu_sched_debug>1</cpu_sched_debug>
   </log_flags>
</cc_config>

Does that look right? I wasn't sure if you meant cpu_sched or cpu_sched_debug, so I put them both in.

---

YJ
You may have speed, but I have momentum

Does that look right? I wasn't sure if you meant cpu_sched or cpu_sched_debug, so I put them both in.

That looks fine (without full proof-reading)

I just meant <cpu_sched>.

That should be enough for this hunt, and doesn't flood the log too much. Many moons (and many versions) ago, preempting would be reported at the default logging level, but that was taken out in one of the dumbing-down cycles - now it has to be invoked specifically.

<cpu_sched_debug> - as you've probably found by now - is more verbose, and probably more than you need at the moment.

I've been running seti@home since last century without problem. This has only started in the past few months. If I'm the only one reporting this, it looks like it might be an issue with my BOINC settings rather than the project. Just wish I knew what...

And if your BOINC settings haven't changed in months? And if nobody else has noticed but you? Or they have noticed but haven't cared enough to report? Or they have reported but the Emperor's dacoits silenced them and their posts?

I say dark side but I'll STFU for now. The right man is on the job, part blood-hound part Holmes he is. Bar your doors and shutter your windows for mischief is loosed.

debug certainly does add to the log! I'll turn it off now.

Found my PC had restarted this morning due to MS updates, but after logging in and leaving it for a few minutes, I found an astropulse task left running. Here's the log from a few minutes before until I killed it. I looked at the log before killing it, and the last entry was 8:52. I killed it at 8:54

09/01/2013 08:47:50 |  | Resuming computation
09/01/2013 08:47:50 | SETI@home | [cpu_sched] Resuming 24oc12ac.25785.305539.12.10.78_1
09/01/2013 08:47:50 | SETI@home | [cpu_sched] Resuming 24oc12ae.24511.22664.5.10.109_1
09/01/2013 08:47:50 | SETI@home | [cpu_sched] Resuming ap_25oc12ac_B4_P1_00169_20130108_03182.wu_1
09/01/2013 08:47:50 |  | [cpu_sched_debug] Request CPU reschedule: Resuming computation
09/01/2013 08:47:50 |  | [cpu_sched_debug] Request CPU reschedule: periodic CPU scheduling
09/01/2013 08:47:50 |  | [cpu_sched_debug] schedule_cpus(): start
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] scheduling ap_25oc12ac_B4_P1_00169_20130108_03182.wu_1 (coprocessor job, FIFO) (prio -1.000000)
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] reserving 1.000000 of coproc NVIDIA
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] scheduling 24oc12ac.25785.305539.12.10.78_1 (CPU job, priority order) (prio -1.024652)
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] scheduling 24oc12ae.24511.22664.5.10.109_1 (CPU job, priority order) (prio -1.033244)
09/01/2013 08:47:50 |  | [cpu_sched_debug] enforce_schedule(): start
09/01/2013 08:47:50 |  | [cpu_sched_debug] preliminary job list:
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] 0: ap_25oc12ac_B4_P1_00169_20130108_03182.wu_1 (MD: no; UTS: yes)
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] 1: 24oc12ac.25785.305539.12.10.78_1 (MD: no; UTS: yes)
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] 2: 24oc12ae.24511.22664.5.10.109_1 (MD: no; UTS: yes)
09/01/2013 08:47:50 |  | [cpu_sched_debug] final job list:
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] 0: ap_25oc12ac_B4_P1_00169_20130108_03182.wu_1 (MD: no; UTS: yes)
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] 1: 24oc12ac.25785.305539.12.10.78_1 (MD: no; UTS: yes)
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] 2: 24oc12ae.24511.22664.5.10.109_1 (MD: no; UTS: yes)
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] scheduling ap_25oc12ac_B4_P1_00169_20130108_03182.wu_1
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] scheduling 24oc12ac.25785.305539.12.10.78_1
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] scheduling 24oc12ae.24511.22664.5.10.109_1
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] 24oc12ac.25785.305539.12.10.78_1 sched state 2 next 2 task state 1
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] 24oc12ae.24511.22664.5.10.109_1 sched state 2 next 2 task state 1
09/01/2013 08:47:50 | SETI@home | [cpu_sched_debug] ap_25oc12ac_B4_P1_00169_20130108_03182.wu_1 sched state 2 next 2 task state 1
09/01/2013 08:47:50 |  | [cpu_sched_debug] enforce_schedule: end
09/01/2013 08:48:30 |  | Suspending computation - CPU is busy
09/01/2013 08:48:30 | SETI@home | [cpu_sched] Preempting 24oc12ac.25785.305539.12.10.78_1 (left in memory)
09/01/2013 08:48:30 | SETI@home | [cpu_sched] Preempting 24oc12ae.24511.22664.5.10.109_1 (left in memory)
09/01/2013 08:48:30 | SETI@home | [cpu_sched] Preempting ap_25oc12ac_B4_P1_00169_20130108_03182.wu_1 (left in memory)
09/01/2013 08:52:30 |  | [cpu_sched_debug] Request CPU reschedule: Idle state change
09/01/2013 08:52:30 |  | [cpu_sched_debug] Request CPU reschedule: network suspended
09/01/2013 08:52:30 |  | Suspending network activity - computer is in use
09/01/2013 08:54:23 |  | [cpu_sched_debug] Request CPU reschedule: application exited
09/01/2013 08:54:23 | SETI@home | Computation for task ap_25oc12ac_B4_P1_00169_20130108_03182.wu_1 finished
09/01/2013 08:54:23 |  | [cpu_sched_debug] Request CPU reschedule: handle_finished_apps

---

YJ
You may have speed, but I have momentum

OK, the monitoring seems to be in place - we can see the "preempting" at 08:48:30 (that's BOINC giving the instruction for the apps to get out of the way). Now, we just have to wait and catch it in the act, and see whether (just possibly) Astropulse gets sent the 'stop it' message, but fails to act on it. That's certainly one possibility - I've documented an Einstein application behaving that way - but it's not been reported as a common problem.

The current Astropulse application (v6) has been operational since 13 Mar 2012, and I'm pretty sure that it's not a deliberate "dark side" operation as Dagorath suggests. But I wouldn't rule out bugs in the BOINC API library that handles messaging between the BOINC client and the science applications.

Sorry, Holmes is still suffering from a caffeine under-dose this morning. Dr Watson has just pointed out the last few lines - that AP task managed to finish while computing was suspended and the task itself pre-empted.

Could you add one more line to your cc_config logging section, please?

<checkpoint_debug>1</checkpoint_debug>

That will provide more evidence if an application is active when it shouldn't be, without adding too much to the clutter. Normal SETI apps checkpoint regularly, but Astropulse more rarely - IIRC, only 111 times in the course of a run. CPDN can also run for maybe 15 minutes between checkpoints.

Ah - and another check I should have made: All tasks for computer 4499642. You're not using the standard project application as I assumed, but a '(opencl_nvidia_100)' contributed by a third-party developer - and only deployed on 21 Aug 2012. Does that sound like the right sort of starting date for your problems?

OpenCL indicates that this is a GPU app: your log only indicates suspending CPU activity, although it does attempt to preempt the AP task too. Just to be on the safe side, it would be good to ensure 'Use GPU based on preferences' is selected in the middle of the three sections of the Activity menu (BOINC Manager, advanced view).

The task in your log (2786568256) did manage to suspend/resume several times during the run:

Termination request detected. GPU device synched, awaiting termination...

but it seems to have missed the final call. I'll have a think about that one.

I killed it at 8:54

May I just ask, how do you 'kill' these tasks? Do you End Process them in Windows Task Manager, or use another method? Do you do so while BOINC runs, or with BOINC (boinc.exe) no longer in memory?

---

<checkpoint_debug>1</checkpoint_debug>

Done

You're not using the standard project application as I assumed, but a '(opencl_nvidia_100)' contributed by a third-party developer - and only deployed on 21 Aug 2012. Does that sound like the right sort of starting date for your problems?

Sounds about right, though I've not loaded anything unusual on purpose. I did download the GPU option a while ago when prompted by an email, but couldn't say when.

Just to be on the safe side, it would be good to ensure 'Use GPU based on preferences' is selected in the middle of the three sections of the Activity menu (BOINC Manager, advanced view).

Done - all activities are "based on preferences". Would turning off the GPU processing show if that's causing the problem?

---

YJ
You may have speed, but I have momentum

I killed it at 8:54

May I just ask, how do you 'kill' these tasks? Do you End Process them in Windows Task Manager, or use another method? Do you do so while BOINC runs, or with BOINC (boinc.exe) no longer in memory?

At the moment I right-click the task in WTM and End Process, though I have toyed with the idea of writing a cmd-file to kill all tasks containing "astropulse". It isn't left running all the time, so it's annoying rather than critical.

I haven't exited BOINC before killing it up till now.

---

YJ
You may have speed, but I have momentum

I haven't exited BOINC before killing it up till now.

Please try that first, then. That shows if it's a rogue application, willfully continuing despite what BOINC does.

Now it can e.g. be a preference setting that you set wrong, or update in the wrong place (on web when you use local preferences, or editing it in the default venue while the computer expects preferences to be set in the school venue, etc.).

Exiting BOINC fully should exit all science applications.

---

Would turning off the GPU processing show if that's causing the problem?

I'm pretty sure that turning off GPU processing would send exactly the same 'stop it' message to the application as the 'user active' or 'CPU busy' cases - with, presumably, the same chance of success.

It might be a quicker and more manageable way of getting to the bottom of the problem, if you had a few spare minutes to devote to testing sometime?

Hasn't happened again today.

@Ageless - I'll close BOINC next time I find it running and see what happens to the running task. It could happen soon or it could be a week, though...

@RichardH Happy to do some testing on this as I'm based at home for the next week or so. Just let me know what you want me to change...

---

YJ
You may have speed, but I have momentum

@RichardH Happy to do some testing on this as I'm based at home for the next week or so. Just let me know what you want me to change...

I was just thinking that if you weren't doing intensive work on the computer, you might try turning off the 'suspend computation when user is active' preference, and instead try suspending the GPU manually at random intervals when you happen to be passing. See if you get the same occasional run-ons.

I've changed the preference on my SETI page and on the BOINC manager, so I'll see how the PC copes. It's relatively old, and can be RAM-bound as I run 4Gb on Vista 32-bit - I understand I'd need to change to 64-bit to use any more RAM. (Reminds me of having to use QEMM to access above 640K on DOS!)

To turn off the GPU, I take it I just do it from the activity menu in BOINC rather than via the SETI online preferences?

---

YJ
You may have speed, but I have momentum