???

No matter what I do, I randomly (all flavours of Linux and Win98/Win98SE) see Project Clients continue running in the Background despite being "Paused".

That greatly hogs down the Single CPU machines, now running 2 or even 3 Projects at the same time :p

The last official 2 Versions of BOINC seem to be unable to currectly Pause the various Clients, that's the only explanation I have for it.

But since I haven't read anything about it anywhere, am I the only one with this odd Problem ?!?

---

No I have also reported it. It does not actually continue, it just keeps the CPU time running, but no actual processing of WU so it should not affect your other processing, just increaes the CPU time

---

I see this but only on my linux box as far as I can tell. Scribe: I think you have your settings set to 'leave program in memory while suspended' or however they phrase it. In that case, the process will still show up in a list but it won't consume CPU time. The problem I am seeing is that it continues crunching thereby robbing the project that is supposed to be running of CPU time. They both show as using 50% of the CPU. Then when it "restarts" the work unit, it often errors out with the following reported in stderr:

<core_client_version>4.13</core_client_version>
<message>Maximum memory usage exceeded
</message>
<active_task_state>5</active_task_state>
<signal>0</signal>
<couldnt_start>-177</couldnt_start>

It doesn't happen to every work unit. Just every once in a while. I see about 6 errors in the last 40 work units from my linux box. From what I have seen, it seems to be a seti-specific problem. I have never seen it with lhc or cpdn. Possibly a seti@home bug that doesn't pause when asked to nicely by the core client?

---

A member of The Knights Who Say NI!
For rankings, history graphs and more, check out:
My BOINC stats site

> 4.13
> Maximum memory usage exceeded
>
> 5
> 0
> -177
>
> It doesn't happen to every work unit. Just every once in a while. I see
> about 6 errors in the last 40 work units from my linux box. From what I have
> seen, it seems to be a seti-specific problem. I have never seen it with lhc
> or cpdn. Possibly a seti@home bug that doesn't pause when asked to nicely by
> the core client?
>

I've seen the same thing here (also running linux)
Since I've disabled the "Leave applications in memory while preempted"
option the problem seems to have gone away.

Regards Hans

---

Hmm...

Far shot, but "right now" everything is working normal.

I have
- disabled "Suspend Applications in Memory"
- switched all Clients (9 in total running 10 CPU's) from "Always run" to "Run based on Preferences"

Technically it should make no difference IMHO (my Preferences are the default, which makes the Clients work 24/7), but latter also helped free one of those "stalled at 100.0%" SETI Units, so this one might do the magic trick.
(maybe BOINC interpretes "Always Run" different than I think?)

Seeing a Linux Box not reacting to my other workaround (momentarily switching from "Always Run" to "Suspend" and then back to normal) while having a paused SETI creep along, I took my chances with the "Run based on preferences".

Either that, or I am just lucky it works right now; I'll have to monitor it for some more time.

From personal observation, the impact on performance greatly depends on what Project is running, and what others are creeping along in Paused mode.
LHC seems to take a tremendous hit (-90% performance) when SETI is creeping along for example, while CPDN runs at about 50% in the same situation; SETI seems to lose "only" some 20-30% it the same situation.

I do have the suspicion however, that SETI Clients finishing Projects while ceeping towards 100% in "Paused" mode result in "Computing Error" when reaching 100%; I haven't observed such a case 'in flagranti' as it happened yet, however.

I do hope it stays that way now, so I can migrate more SETI Classic machinery to BOINC; got a couple of fast Systems remaining I could toss into BOINC land :)

---

Scribe: I think you
> have your settings set to 'leave program in memory while suspended' or however
> they phrase it.


That fixed mine, thanks

---