Good news: I've now observed a case which indicates that the problem lies in the BOINC application, not in any of the science applications (or else in code used in all BOINC science apps ... whatever ...).
This time I observed the behavior while attached only to S@H and Predictor.
Then, when I exit and restart BOINC, the Predictor WU starts up normally (except that it claims to already be 11% finished as it starts its clock finally) and the SETI WU is paused correctly (confirmed on Activity Monitor, too).
Machine: Mac mini (same as below)
Attached to S@H and E@H only.
Work tab:
setiathome 4.1, 8:48:17, 100.00%, ---, "Ready to report:
einstein 4.82, 00:14:24 (climbing very slowly), 3.25% (climbing very slowly), 07:08:38 (climbing!), "Running"
Alan, I had similar problems with 4.43 to all the ones you've described. While I do NOT recommend development versions for everyone, in your specific case I think you need to move to version 4.72 (not 5.x because not all projects support it yet). When I started testing 4.72, I stopped seeing all the things you're describing.
I had no problems installing just by quitting BOINC Manager then installing 4.72, although I _did_ backup the BOINC Data folder first - but I would recommend "no new work" all projects, let your cache empty, quit, backup folder, then install - just to be sure no work gets lost.
Alan, I had similar problems with 4.43 to all the ones you've described. While I do NOT recommend development versions for everyone, in your specific case I think you need to move to version 4.72 (not 5.x because not all projects support it yet). When I started testing 4.72, I stopped seeing all the things you're describing.
I had no problems installing just by quitting BOINC Manager then installing 4.72, although I _did_ backup the BOINC Data folder first - but I would recommend "no new work" all projects, let your cache empty, quit, backup folder, then install - just to be sure no work gets lost.
I've now tried both the 5.2.1 and 4.72 BOINC Manager beta releases.
So far, 4.72 seems to be what we should recommend for users experiencing the bugs in 4.43 documented in this thread.
4.72 has been running 80 hours continuously on the Mac mini (same machine as in bug reports below), while using the same project settings as those which led to problems under 4.43. In short: attached to E@H and S@H in a ratio of 3:1 time sharing, with results left in memory while preempted.
5.1.2 failed to even initiate any work units on this Mac mini. However, 5.1.2 has been running stable on the Powerbook (same one as reported below), which is likewise attached to E@H and S@H, leaving results in memory. On the other hand, it has only been running E@H WUs since S@H reports that BOINC major version 4 is required. Same with Predictor.
I don't know whether the following problem is with the E@H application, the BOINC 4.43 GUI, or Predictor. Symptom:
I am also seeing this. the common thread seems to be predictor. It looks as though P@H WU start up occur very fast during an App switch. So fast that the Variable gets zeroed out for what ever application is pausing. You can actually see this happen in the BOINC Monitor. I have now see this with E@H, Rosette@H and S@H. I can't tell if this is a BOINC issue or a P#H issue, but it seems to be related to the speed at which P@H loads during the switch. Somehow P@H is starting too fast, and grabs the variables for the wrong init_state file. It then keeps that file until the next switch.
I have even see P@H WUs start up, zero the CPU time for S@H WUs and then proceed to process normally. This of course has the effect of altering the actual processing time records for the S@H Wu.
Since the adverse effects of this only impact projects other than P@H I do not know how high on the list of things to fix this will be for the p@H team. I will duplicate this post on the other boards and we will see what happens.
Good news: I've now observed
)
Good news: I've now observed a case which indicates that the problem lies in the BOINC application, not in any of the science applications (or else in code used in all BOINC science apps ... whatever ...).
This time I observed the behavior while attached only to S@H and Predictor.
Machine info (Powerbook):
http://einsteinathome.org/host/205881
Work tab says:
Proteinp..; mfoldB125 4.29; ---, 0.00%, --- (all stats static); "Running"
SETI...; setiathome 4.18; 00:12:34, 15.26%, 01:10:02 (all stats advancing); "Paused"
Activity Monitor says:
setiathome ... ~40%, 1 thread
mfold ... ~39%, 1 thread
BOINCManager, ~10%, 1 thread
boinc, ~1, 1 thread
Overall load is mostly "Nice"
Then, when I exit and restart BOINC, the Predictor WU starts up normally (except that it claims to already be 11% finished as it starts its clock finally) and the SETI WU is paused correctly (confirmed on Activity Monitor, too).
Are you a musician? Join the Musicians team.
Meet the Musicians
Hmm, now here's a new class
)
Hmm, now here's a new class of behavior:
Machine: Mac mini (same as below)
Attached to S@H and E@H only.
Work tab:
setiathome 4.1, 8:48:17, 100.00%, ---, "Ready to report:
einstein 4.82, 00:14:24 (climbing very slowly), 3.25% (climbing very slowly), 07:08:38 (climbing!), "Running"
Activity Monitor:
boinc 25%, 1 thread
BOINCManager 5%, 1 thread
einstein ~5%, 3 threads
Most of the load is classified as "User," then about a third "System," and only a few percent "Nice."
When I then exit and restart BOINC, the E@H WU resumes normally.
Are you a musician? Join the Musicians team.
Meet the Musicians
Alan, I had similar problems
)
Alan, I had similar problems with 4.43 to all the ones you've described. While I do NOT recommend development versions for everyone, in your specific case I think you need to move to version 4.72 (not 5.x because not all projects support it yet). When I started testing 4.72, I stopped seeing all the things you're describing.
Go here: http://boinc.berkeley.edu/dl/
Download this: boinc_4.72_macOSX.zip
I had no problems installing just by quitting BOINC Manager then installing 4.72, although I _did_ backup the BOINC Data folder first - but I would recommend "no new work" all projects, let your cache empty, quit, backup folder, then install - just to be sure no work gets lost.
RE: Alan, I had similar
)
You could also try the most recent 5.2.1 development version.
Director, Einstein@Home
I've now tried both the 5.2.1
)
I've now tried both the 5.2.1 and 4.72 BOINC Manager beta releases.
So far, 4.72 seems to be what we should recommend for users experiencing the bugs in 4.43 documented in this thread.
4.72 has been running 80 hours continuously on the Mac mini (same machine as in bug reports below), while using the same project settings as those which led to problems under 4.43. In short: attached to E@H and S@H in a ratio of 3:1 time sharing, with results left in memory while preempted.
5.1.2 failed to even initiate any work units on this Mac mini. However, 5.1.2 has been running stable on the Powerbook (same one as reported below), which is likewise attached to E@H and S@H, leaving results in memory. On the other hand, it has only been running E@H WUs since S@H reports that BOINC major version 4 is required. Same with Predictor.
Are you a musician? Join the Musicians team.
Meet the Musicians
RE: I don't know whether
)
I am also seeing this. the common thread seems to be predictor. It looks as though P@H WU start up occur very fast during an App switch. So fast that the Variable gets zeroed out for what ever application is pausing. You can actually see this happen in the BOINC Monitor. I have now see this with E@H, Rosette@H and S@H. I can't tell if this is a BOINC issue or a P#H issue, but it seems to be related to the speed at which P@H loads during the switch. Somehow P@H is starting too fast, and grabs the variables for the wrong init_state file. It then keeps that file until the next switch.
I have even see P@H WUs start up, zero the CPU time for S@H WUs and then proceed to process normally. This of course has the effect of altering the actual processing time records for the S@H Wu.
Since the adverse effects of this only impact projects other than P@H I do not know how high on the list of things to fix this will be for the p@H team. I will duplicate this post on the other boards and we will see what happens.
P@H post on this subject [url='http://predictor.scripps.edu/forum_thread.php?id=2075']here[/url]
Regards
Phil
We Must look for intelligent life on other planets as,
it is becoming increasingly apparent we will not find any on our own.