I have my BOINC 5.10.30 (under Windows Vista Home Pro) set up to suspend when the notebook runs on battery, but the malariacontrol.net beta (Estimation of parameters of infeciton dynamics), opt_23_-43367_5_155730693_1, transmission_129.exe keeps on running. It keeps on running even if I suspend it via the BOINC Client it keeps on running as well. It says it\'s suspended, but runs.
/ 
I have my BOINC 5.10.30 (under Windows Vista Home Pro) set up to suspend when the notebook runs on battery, but the malariacontrol.net beta (Estimation of parameters of infeciton dynamics), opt_23_-43367_5_155730693_1, transmission_129.exe keeps on running. It keeps on running even if I suspend it via the BOINC Client it keeps on running as well. It says it\'s suspended, but runs.
If you go into Task Manager how much cpu % is it using? Still open but suspended does not mean the icon goes away. I guess I am asking how do you know it is still running?
____________
/
If you go into Task Manager how much cpu % is it using? Still open but suspended does not mean the icon goes away. I guess I am asking how do you know it is still running?
Up to 50%. It was jumping all the way between 5 and 50%.
I have dual core, normally two (often different) projects run at the same time so each of them uses up to 50%.
So it was still running. In the BOINC Client the status was \"Suspended - on bateries\", but the CPU Time was chaning that the Progress was well.
It doesn\'t happen now with malariacontrol.net 5.56, wu_122_501_100038_0_1203546075_2.
/
It could well be a side-effect of the wrapper that the optimizer application is using to communicate with BOINC. But it could also be that it is Vista. The present versions 5.10 of BOINC are not completely compatible with Windows Vista. All kinds of strange things can happen.
A compatible version is being made, but it\'ll take a while before that one surfaces.
____________
Jord.
BOINC FAQ Service
/
It could well be a side-effect of the wrapper that the optimizer application is using to communicate with BOINC. But it could also be that it is Vista. The present versions 5.10 of BOINC are not completely compatible with Windows Vista. All kinds of strange things can happen.
A compatible version is being made, but it\'ll take a while before that one surfaces.
OK. No big deal.
(It happens again just now, transmission_129.exe takes around 50% CPU while I\'m running on batteries. The other type of tasks from malariacontrol.net doesn\'t do that.)
Thanks, Jenda
/
I\'ve got the same problem on a uniprocessor x86 system running under Windows XP SP2. \"Transmission_129.exe\" is running at 98% CPU even when the preferences are set to suspend. The BOINC Manager reports that there are 3 malariacontrol tasks running:
1. malariacontrol.net 5.56 is \"ready to report\"
2. malariacontrol.net, application \"Estimation of parameters of infection dynamics (no progress bar, max 2h) 1.29\", name \"opt_16_-6850_5_851935443_0\", is \"suspended - user active\"
3. malariacontrol.net 5.56 is \"suspended - user active\"
#2 of the above seems to be the one that is running; its title is the one shown if I let the screen saver start up.
/
Follow-up to my last post; here\'s a timeline:
1. Reboot PC. Windows XP starts up, BOINC starts up. No BOINC tasks run because my preferences say to not run when computer is in use.
2. I wait 2 minutes, not moving the mouse. This exceeds the \"in use\" time limit, so the optimizer task starts up: first optimizer_1.29_windows_intelx86 starts running, then transmission_129.exe starts running. They stabilize with optimizer_1.29 at 2% or less CPU time, and transmission_129.exe at 98% CPU time.
3. I move my mouse. The BOINC status for the optimizer task changes from \"running\" to \"suspended-user active\", but transmission_129.exe continues at 98% CPU time.
Perhaps the BOINC message to suspend activity is getting to optimizer_1.29, but not to transmission_129.exe once it starts up? You did say in other posts that the task doesn\'t checkpoint or report progress, so I\'m guessing it doesn\'t check for suspend signals either. You need to fix that.
/
Oh, and I\'m running BOINC Manager 5.10.30.
/
FYou did say in other posts that the task doesn\'t checkpoint or report progress, so I\'m guessing it doesn\'t check for suspend signals either. You need to fix that.
That you don\'t see the progress bar increase or checkpoint messages in BOINC Manager is an effect of the wrapper between BOINC and the optimizer application. The application itself cannot communicate directly with BOINC, so that\'s why this wrapper application is used. The application will progress normally and does checkpoint, you just don\'t see it.
____________
Jord.
BOINC FAQ Service
/
Perhaps the BOINC message to suspend activity is getting to optimizer_1.29, but not to transmission_129.exe once it starts up? You did say in other posts that the task doesn\'t checkpoint or report progress, so I\'m guessing it doesn\'t check for suspend signals either. You need to fix that.
You\'re probably correct.
Given that the wrapper approach is used for legacy applications that cannot be easily ported to full BOINC compliance, it\'s likely that such applications also cannot suspend (or report checkpoint status, or report progress, or <insert your favourite new computing technique>) as easily as a native BOINC application would.
I just don\'t think it\'s that easy to fix though. It\'s the nature of the wrapper technique. If the developers could rewrite the application to be fully BOINC compliant, thus fixing the suspend behaviour, then they wouldn\'t have need of the wrapper in the first place.
Could be that the wrapper app will suspend, but needs to get to a certain point in the application iteration before it can do so. i.e. finish a certain task and suspend before starting the next one.
Perhaps the devs could comment on this here, or you could raise the question here where there is a discussion thread regarding the optimizer application.
In the interim, if the non-suspending behaviour is a serious problem, you can also elect not to run the optimizer wu\'s through your preference settings.
/
hi everybody,
thanks for posting it in the optimizer thread.. please do that whenever you have an issue relating to this application.. it\'s hard to subscribe to threads that don\'t exist yet.. :)
Perhaps the BOINC message to suspend activity is getting to optimizer_1.29, but not to transmission_129.exe once it starts up? You did say in other posts that the task doesn\'t checkpoint or report progress, so I\'m guessing it doesn\'t check for suspend signals either. You need to fix that.
It should suspend I think, at least I remember that it did, at least on my computer, and we have not changed anything on the wrapper part since then.. would be interesting if there are some people where suspend works.. will check again 2morrow on my computer if it does..
I just don\'t think it\'s that easy to fix though. It\'s the nature of the wrapper technique. If the developers could rewrite the application to be fully BOINC compliant, thus fixing the suspend behaviour, then they wouldn\'t have need of the wrapper in the first place.
could be very true that it\'s not easy to fix.. could be anything, and I\'m not the expert in windows process handling issues.. to make the application implement the boinc api, one would need use java native interface, since the application is in java.. this is planned in the boinc world..
Could be that the wrapper app will suspend, but needs to get to a certain point in the application iteration before it can do so. i.e. finish a certain task and suspend before starting the next one.
not true, the application doesn\'t know that much about its environment.. suspending probably works entirely via windows api, and should happen immediately..
In the interim, if the non-suspending behaviour is a serious problem, you can also elect not to run the optimizer wu\'s through your preference settings.
that\'s what I would recommend too, especially since even if \"suspend\" worked, for a wrapper application it would mean that it has to start from scratch after suspending.. that\'s inherent in the wrapper approach, and can only be fixed in implementing the boinc api, as stated above. so having your project settings in a way that when the user is active the project gets suspended, and then if the user is inactive for 1 second it starts again, doesn\'t make much sense.. some workunits of the optimizer app (actually by far most) are quiet short, maybe 10 mins, then a short period of inactivity is enough.. but if you get a 2hour one, it will retry forever..
I will look into the suspend issue and update you asap
Michael
____________
Michael
/
I think the suspend issue is solved now, this bug will be fixed in version 1.32. We\'re currently testing it in-house and hope to release it later today..
The reason for this was that the java app became multi-threaded in the meantime, and the wrapper was not made for this.. it would only suspend the main thread.. (which didn\'t do much anymore in our app).
The solution was found here. I\'m posting this here, because other boinc projects might run into the same problem, and since you\'ve already provided all the keywords for google I think it\'s not a bad place..
Just download the source code of that application, the function which suspends all threads can almost be used as is.. with some minor changes, e.g. get PID from the process handle, and that\'s it... might even be worth to include in the standard wrapper..
____________
Michael
/
here. I\'m posting this here, because other boinc projects might run into the same problem, and since you\'ve already provided all the keywords for google I think it\'s not a bad place..
I think you should post about it on the BOINC_Dev email list, or BOINC_Projects email list, and/or alternatively make it a Trac Enhancement ticket.
I will at least email David Anderson about it.
____________
Jord.
BOINC FAQ Service
/
might even be worth to include in the standard wrapper..
David Anderson modified the wrapper.
From the BOINC_Projects email list:
I modified the wrapper (Windows version) so that is suspends/resumes
all threads in the application process, not just the initial one.
Any projects using the wrapper with multi-thread applications should
try this out.
This makes me wonder: on Unix and Mac, when you send a SIGSTOP to
a process, does it suspend all its threads?
-- David
See also [14862] and [14863].
____________
Jord.
BOINC FAQ Service
/