I was able to reproduce the problem. It seems to be bound to the latest system update to 10.4.2, it works correctly with 10.4.1 and before. I'll continue to investigate this.
does your preference setting of "Leave applications in memory while preempted?" make any difference to that strange behavior? Please try changing it (don't forget to update the project) and report.
Bernd and Bruce: I checked my 1.33 GHz iBook G4, 10.3.9, MenuBar with 4.44 Super and E@H .05, and found the same problem as I found on my PowerBook: namely that the "user" and "system" were taking large parts of the CPU time as compared to E@H, in the Dock graphic. This time I made screen shots of it all. You can see them at
in a folder called "boinc screenshots" .
menubarlog.rtf shows the menubar log.
Picture 1 shows Activity Monitor
Pictures 2-4 show details for the E@H process
Pictures 5, 6, 10 show details for the BOINC MenuBar process
Pictures 11-13 show details for the boinc process
I went to the Menu pull-down for menubar and quit menubar. Picture 14-17 show the result - boinc and menubar quit, but E@H continued to run. I then forced E@H process to quit, then restarted Menubar.
Pictures 18-20 show details for E@H after I restarted Menubar - I didn't take a screenshot, but the Dock icon showed that 90% of the CPU was being used for "nice" with almost nothing for "user" or "system".
I don't know if these will be of help or not, but thought I'd take them just in case.
At some point, when the BOINC manager is not correctly reporting the cpu time and/or progress, could you please look into the client_state.xml file and see if the cpu time and/or progress are correct there or are incorrect?
If client_state.xml is correct and the BOINC manager display is incorrect, then the problem is in BOINC manager. If client_state.xml is incorrect, then the problem is in the boinc core client.
You can find this client_state.xml in /Library/Application\ Data/BOINC/
Not sure what is happening on my computer (BOINC 4.44 MacNN, 10.3.9). Ever since I installed Einstein client 0.08 (which was yesterday night), things have gotten way too slow. In 19+ hours, the client claims it has completed only 2.3% of this WU . On average, Einstein has been using 92% of the CPU for the last 19 hours. The unoptimized client used to take 20 hours for a WU, while the beta versions (0.02 and 0.05) used to take slightly more than 10 hours/WU.
Has any body else noticed this with 0.08? If not, is someone willing to help me figure out the problem? Currently, the computer is not attached to any other project. Thanks.
Hmmm, weird. The 0.08 app has only a single tiny difference from 0.05, which should not have this effect. So I have no idea what's wrong. Could you start up the 'Activity Monitor' and look carefully at the process list to be sure that there is nothing else running on your system? Eg extra copies of BOINC or of the BOINC manager, for example?
It looks as if the problem is due to my dialup modem and BOINC/E@H: after BOINC contacts E@H to download files/upload results, if I don't hang up the modem manually (I let the computer download the huge 6-8 MB work files such as w1_0673.0 while I run errands; the computer is set to hang up the modem automatically after 15 minutes of idle time), the client does not do any computation (it still uses 90 - 95% CPU) after the automatic modem hang up. The client runs fine if I manually hang up before the computer does it by itself or if the modem hangs up automatically and the client does not contact the server during the online session. My general preferences on the main page request BOINC to leave my modem alone - ignore requests from the client for connecting & disconnecting automatically. I haven't had this issue with other BOINC projects, but that does not mean anything. I can work around the issue, but is there a way to find out what causes the issue in the first place (assuming it is due to BOINC or the Einstein client, and is something that is worth fixing since not many BOINCers use dialup). Thanks.
Bruce:
It happened again - system is allegedly taking most of the CPU time, and E@H is getting around 10% according to the Dock Icon from MenuBar on my iBook, although Activity Monitor shows E@H getting most of the CPU time. Menubar pull-down said 49.97% complete, and the log showed it running for a total of just over 6 hours and 18 minutes. Normal run time for a WU is around 7.7 hours. I made a copy of the client_state_prev.xml and client_state.xml files and put them here and here . Also, this is the MenuBar log.
Had a strange occurance on my 1.0 GHz PowerBook G4 that I haven't see before. Running SETI optimized, E@H .08, CPDN as 10/100/10 under BOINC 4.44 as CLI. I checked the computer this morning and discovered through Activity Monitor that nothing was running in BOINC - no "nice" processes at all. Looked at the terminal log and saw nothing amiss. I've placed copies of the client_state.xml , the client_state_prev.xml , and the Terminal log files so you can see them. Before copying the Terminal Log, I stopped BOINC with cmd-C, then restarted it.
Alan, I was able to
)
Alan,
I was able to reproduce the problem. It seems to be bound to the latest system update to 10.4.2, it works correctly with 10.4.1 and before. I'll continue to investigate this.
BM
BM
Alan, does your preference
)
Alan,
does your preference setting of "Leave applications in memory while preempted?" make any difference to that strange behavior? Please try changing it (don't forget to update the project) and report.
BM
BM
Under einstein 0.08, I have a
)
Under einstein 0.08, I have a unit that ran to 99% but, whille still "Running", has stopped making progress. No such problem before.
Bernd and Bruce: I checked
)
Bernd and Bruce: I checked my 1.33 GHz iBook G4, 10.3.9, MenuBar with 4.44 Super and E@H .05, and found the same problem as I found on my PowerBook: namely that the "user" and "system" were taking large parts of the CPU time as compared to E@H, in the Dock graphic. This time I made screen shots of it all. You can see them at
http://homepage.mac.com/WebObjects/FileSharing.woa/22/wo/CFiohYJJhp3nFMFK.1/0.2.1.2.26.31.97.2.35.0.1.1.1user=beadman&fpath=boinc%20screenshots&templatefn=FileSharing3.html
in a folder called "boinc screenshots" .
menubarlog.rtf shows the menubar log.
Picture 1 shows Activity Monitor
Pictures 2-4 show details for the E@H process
Pictures 5, 6, 10 show details for the BOINC MenuBar process
Pictures 11-13 show details for the boinc process
I went to the Menu pull-down for menubar and quit menubar. Picture 14-17 show the result - boinc and menubar quit, but E@H continued to run. I then forced E@H process to quit, then restarted Menubar.
Pictures 18-20 show details for E@H after I restarted Menubar - I didn't take a screenshot, but the Dock icon showed that 90% of the CPU was being used for "nice" with almost nothing for "user" or "system".
I don't know if these will be of help or not, but thought I'd take them just in case.
C
I
Join Team MacNN
Alan, C, At some point,
)
Alan, C,
At some point, when the BOINC manager is not correctly reporting the cpu time and/or progress, could you please look into the client_state.xml file and see if the cpu time and/or progress are correct there or are incorrect?
If client_state.xml is correct and the BOINC manager display is incorrect, then the problem is in BOINC manager. If client_state.xml is incorrect, then the problem is in the boinc core client.
You can find this client_state.xml in /Library/Application\ Data/BOINC/
Director, Einstein@Home
RE: Under einstein 0.08, I
)
Robert,
can you name the Workunit or Result in question? This might be rather related to the data than to the App.
BM
BM
No, it is gone. After
)
No, it is gone. After logging out, back in, it was completed.
RE: RE: Not sure what is
)
It looks as if the problem is due to my dialup modem and BOINC/E@H: after BOINC contacts E@H to download files/upload results, if I don't hang up the modem manually (I let the computer download the huge 6-8 MB work files such as w1_0673.0 while I run errands; the computer is set to hang up the modem automatically after 15 minutes of idle time), the client does not do any computation (it still uses 90 - 95% CPU) after the automatic modem hang up. The client runs fine if I manually hang up before the computer does it by itself or if the modem hangs up automatically and the client does not contact the server during the online session. My general preferences on the main page request BOINC to leave my modem alone - ignore requests from the client for connecting & disconnecting automatically. I haven't had this issue with other BOINC projects, but that does not mean anything. I can work around the issue, but is there a way to find out what causes the issue in the first place (assuming it is due to BOINC or the Einstein client, and is something that is worth fixing since not many BOINCers use dialup). Thanks.
Bruce: It happened again -
)
Bruce:
It happened again - system is allegedly taking most of the CPU time, and E@H is getting around 10% according to the Dock Icon from MenuBar on my iBook, although Activity Monitor shows E@H getting most of the CPU time. Menubar pull-down said 49.97% complete, and the log showed it running for a total of just over 6 hours and 18 minutes. Normal run time for a WU is around 7.7 hours. I made a copy of the client_state_prev.xml and client_state.xml files and put them here and here . Also, this is the MenuBar log.
C
Join Team MacNN
Bruce and Bernd: Had a
)
Bruce and Bernd:
Had a strange occurance on my 1.0 GHz PowerBook G4 that I haven't see before. Running SETI optimized, E@H .08, CPDN as 10/100/10 under BOINC 4.44 as CLI. I checked the computer this morning and discovered through Activity Monitor that nothing was running in BOINC - no "nice" processes at all. Looked at the terminal log and saw nothing amiss. I've placed copies of the client_state.xml , the client_state_prev.xml , and the Terminal log files so you can see them. Before copying the Terminal Log, I stopped BOINC with cmd-C, then restarted it.
C
Join Team MacNN