I've observed the following behaviour when running several Projects on one machine (Single CPU, various flavours of Linux, BOINC V4.19) :
Description :
- EAH, when paused by BOINC's normal Scheduling and followed by PAH running as the next Project in the cycle, EAH does not properly shutdown in a small number (~5%) of occasions
- effectively, EAH and PAH are then running parallel on one CPU, where actually only PAH should run. EAH gets the majority of CPU cycles in this mode of undesired operation.
Symptoms :
- both Projects continue to consume CPU time
- PAH with status "running" is slowed down by upto 80% or more
- effect has been observed on Dual CPU machines as well, resulting in EAH running alongside the 2 normally running Projects, causing massive Slowdown (90% or more) of the one CPU running PAH
Workaround :
- Momentarily suspend BOINC, then set to "Run always" or "Run based on preferences" again
This causes EAH to be properly shutdown until the next scheduled timeslice in most cases.
- if parallel running persists : repeat procedure
- if problem still persists : shutdown and restart BOINC
Copyright © 2024 Einstein@Home. All rights reserved.
Einstein & Predictor doesn't mix well under Linux
)
Hi, FalconFly.
Sorry to say, I've had the same problem on my Mac running OS X 10.3.8 in Terminal mode. You can read about it here.
The only solution I've found is to detach E@H - I was half way through Phase 3 on a CPDN WU and didn't want to mess it up by accident. There have been a couple of others reporting this about Macs as well, but I think you may be the first using Linux. This appears to be low on the priority list for the E@H folks to fix, but maybe now that it's also happening with Linux, they'll up the priority a bit.
C
[/url]
Join Team MacNN
> There have been a > couple
)
> There have been a
> couple of others reporting this about Macs as well, but I think you may be the
> first using Linux. This appears to be low on the priority list for the E@H
> folks to fix, but maybe now that it's also happening with Linux, they'll up
> the priority a bit.
It's on the bug report, and it occurs in all OSs. I think it's still being debated as to exactly which part is causing it - einstein or boinc. I've also had it happen in which seti stays active when it should have changed to cpdn - so there may be some validity to it being a general boinc problem.