I'll ask folks on the team to provide more clear feedback if they are running the Beta App.
Another update. My first is above at http://einsteinathome.org/goto/comment/15357
and I'm one of the people running the 4.44 Team MacNN optimized BOINC under MenuBar. Again, both Einstein and SETI continue to run simultaneously on the same processor, as Einstein won't pause when it says it is doing so.
Out of 18 WU actually worked on, one was client error computer (probably when I switched from BOINC Manager to MenuBar, 2 WU are listed as Success Done, but are invalid with zero credit, and the remaining 15 seem to be fine, averaging around 27,000 CPU-secs each. The SETI WU completed during the same time period appear to be fine - no invalid WU.
All my Einstein@Home Beta test WUs have completed and received credit or are currently pending, except a few for which I got 0 - 1437390, 1419718, 1448587. Maybe those are in the 4%
I am running the Team MacNN Boinc_4.44superoptimazed client.
So the beta appears to be a great success to me.
For everyone running the 4.44 client and having control issues like Shaktai, the chances are very good that you are overcommitted and the client has taken over control and is finishing project with WUs imminently due first, so it isn't honoring your preferences, or switching between projects when it normally would.
In your log you might see something like this:
2005-07-03 05:38:06 [---] Computer is overcommitted
2005-07-03 05:38:06 [---] Nearly overcommitted.
2005-07-03 05:38:06 [---] New work fetch policy: no work fetch allowed.
2005-07-03 05:38:06 [---] New CPU scheduler policy: earliest deadline first.
On machines with this issue, you should probably run the TeamMacNN regular Boinc_4.44 client.
Boinc_4.44 supports auto-rescheduling when the machine has too much work to complete, this is why the superoptimized version should only be run on dedicated crunch boxes with boatloads of RAM, or on machines that aren't attached to many projects.
There is a way to remotely correct this, and that is to set your General Preferences:Connect to network about every: setting to something higher than .1 or even .5 and wait for your WUs cache to run down.
This way you can reduce the amount of WUs you cache, and potentially avoid acquiring too many WUs for the machine to possibly complete. Really, that machine should either run the other client or be attached to less projects.
I'm not sure if any of the Boinc GUI programs are aware of the new client's CPU scheduler policy, and if not, that might explain their incorrect feedback.
I just found a problem in the boinc library that I think is responsible for the "not properly suspending" issue. If I'm right, this at least is not a problem of the client, but of the App.
I tried this, using the trackpad, but it does not work with Einstein 0.02
Really weird, works perfeclty for me, with 0.02 on 10.3.9 and 10.4.1. One last thought - are you using an uncommon keymap? Or maybe a hotkey tool? Anyone else seen this or has an idea?
Quote:
Let us not get too excited about this detail{/quote]
Well, this is a real puzzle. it might not be important for you, but it may not be limited to your machine and may point to a deeper problem.
BM
Now, I have a partial answer to my problem of not being able to zoom the viewpoint of the figure in Einstein 0.02 . The problem seems to reside in my computer, or in OSX.3.9, NOT in Einstein 0.02.
My PowerBook G4 is connected to a small USB hub, connected itself to a Microsoft USB mouse, a HP USB printer, and a USB/Bluetooth interface leading to an Apple Bluetooth AZERTY keyboard.
When I start my PowerBook with the USB hub connected to it, then I encounter the problem that I cannot zoom the viewpoint with the mouse with the ctrl key depressed.
However, when I start my PowerBook with the USB hub disconnected, then I recover normal control of the zoom. This favorable condition persists after I reconnect the USB hub.
Thank you again, Bernd, for your help. It is a pleasure to run Einstein 0.02. Best regards, JJ
I tried this, using the trackpad, but it does not work with Einstein 0.02
Really weird, works perfeclty for me, with 0.02 on 10.3.9 and 10.4.1. One last thought - are you using an uncommon keymap? Or maybe a hotkey tool? Anyone else seen this or has an idea?
Quote:
Let us not get too excited about this detail{/quote]
Well, this is a real puzzle. it might not be important for you, but it may not be limited to your machine and may point to a deeper problem.
BM
Now, I have a partial answer to my problem of not being able to zoom the viewpoint of the figure in Einstein 0.02 . The problem seems to reside in my computer, or in OSX.3.9, NOT in Einstein 0.02.
My PowerBook G4 is connected to a small USB hub, connected itself to a Microsoft USB mouse, a HP USB printer, and a USB/Bluetooth interface leading to an Apple Bluetooth AZERTY keyboard.
When I start my PowerBook with the USB hub connected to it, then I encounter the problem that I cannot zoom the viewpoint with the mouse with the ctrl key depressed.
However, when I start my PowerBook with the USB hub disconnected, then I recover normal control of the zoom. This favorable condition persists after I reconnect the USB hub.
Thank you again, Bernd, for your help. It is a pleasure to run Einstein 0.02. Best regards, JJ
Now I did read something about 4% being no good. But I am at over 71% being crap and not even being turned down. They are just crap from the start. Before the upload. My Boinc is saying they are crap.
The 4% are Results that finish successful, but are marked as invalid (thus granted no credit) because of a problem with the validation. This has nothing to do with Results that crash during computation with a "client error".
In the two Results with client errors I've seen from your machines the core client version is reported as 4.44. Where did you get that from? The one that's on our download page and we tested the App with is still 4.43.
BM
I was running v4.44 with the javalizard Seti and the beta Einstein. I was thinking the same as you guys. that it may be a problem with the Boinc 4.44. I am waiting to finish up this batch of Seti WUs, then I was going to reinstall Boinc 4.43 and try the Einstein again. Should have some results by the beginning of next week.
Okay, finally got back home for a couple of days and got the iMac G5 1.6 back up and running. Not sure what happened, but it quit running both Einstein and Predictor, but kept asking Orbit@home (which has no work yet) for work.
Anyway, succesfully completed 4 units at 5.6 hours per unit with credit pending in less then 24 hours. No problems, but I suspended Predictor so it is isn't switching back and forth with that project, as I have to head out of town again on Sunday. No rest for the weary wanderer.
Since July 8th, when I restarted it, I have completed 36 work units with no obvious errors. Only 9 have been granted credit, but the other 27 are pending and looks like most if not all will eventually be granted credit. Average time per work unit is about 5.5 to 5.7 hours. 4 .5 units per day. I am running Einstein exclusively on the iMac G5 until I am sure that I am not going to have to travel any time soon again, then I may try to mix it up again with some other projects.
The current beta App definitely has a problem with proper suspending. If you want to mix E@H with other projects, run the official App or wait for the next Beta version. Should be up soon.
The current beta App definitely has a problem with proper suspending. If you want to mix E@H with other projects, run the official App or wait for the next Beta version. Should be up soon.
RE: I'll ask folks on the
)
Another update. My first is above at http://einsteinathome.org/goto/comment/15357
and I'm one of the people running the 4.44 Team MacNN optimized BOINC under MenuBar. Again, both Einstein and SETI continue to run simultaneously on the same processor, as Einstein won't pause when it says it is doing so.
Out of 18 WU actually worked on, one was client error computer (probably when I switched from BOINC Manager to MenuBar, 2 WU are listed as Success Done, but are invalid with zero credit, and the remaining 15 seem to be fine, averaging around 27,000 CPU-secs each. The SETI WU completed during the same time period appear to be fine - no invalid WU.
beadman
Join Team MacNN
All my Einstein@Home Beta
)
All my Einstein@Home Beta test WUs have completed and received credit or are currently pending, except a few for which I got 0 - 1437390, 1419718, 1448587. Maybe those are in the 4%
I am running the Team MacNN Boinc_4.44superoptimazed client.
So the beta appears to be a great success to me.
For everyone running the 4.44 client and having control issues like Shaktai, the chances are very good that you are overcommitted and the client has taken over control and is finishing project with WUs imminently due first, so it isn't honoring your preferences, or switching between projects when it normally would.
In your log you might see something like this:
2005-07-03 05:38:06 [---] Computer is overcommitted
2005-07-03 05:38:06 [---] Nearly overcommitted.
2005-07-03 05:38:06 [---] New work fetch policy: no work fetch allowed.
2005-07-03 05:38:06 [---] New CPU scheduler policy: earliest deadline first.
On machines with this issue, you should probably run the TeamMacNN regular Boinc_4.44 client.
Boinc_4.44 supports auto-rescheduling when the machine has too much work to complete, this is why the superoptimized version should only be run on dedicated crunch boxes with boatloads of RAM, or on machines that aren't attached to many projects.
There is a way to remotely correct this, and that is to set your General Preferences:Connect to network about every: setting to something higher than .1 or even .5 and wait for your WUs cache to run down.
This way you can reduce the amount of WUs you cache, and potentially avoid acquiring too many WUs for the machine to possibly complete. Really, that machine should either run the other client or be attached to less projects.
I'm not sure if any of the Boinc GUI programs are aware of the new client's CPU scheduler policy, and if not, that might explain their incorrect feedback.
I just found a problem in the
)
I just found a problem in the boinc library that I think is responsible for the "not properly suspending" issue. If I'm right, this at least is not a problem of the client, but of the App.
BM
BM
RE: RE: I tried this,
)
RE: RE: I tried this,
)
RE: RE: Now I did read
)
I was running v4.44 with the javalizard Seti and the beta Einstein. I was thinking the same as you guys. that it may be a problem with the Boinc 4.44. I am waiting to finish up this batch of Seti WUs, then I was going to reinstall Boinc 4.43 and try the Einstein again. Should have some results by the beginning of next week.
G4 DP 1GHZ 1.5GB Ram, Mac OSX 10.3.9...
MacStef
Okay, finally got back home
)
Okay, finally got back home for a couple of days and got the iMac G5 1.6 back up and running. Not sure what happened, but it quit running both Einstein and Predictor, but kept asking Orbit@home (which has no work yet) for work.
Anyway, succesfully completed 4 units at 5.6 hours per unit with credit pending in less then 24 hours. No problems, but I suspended Predictor so it is isn't switching back and forth with that project, as I have to head out of town again on Sunday. No rest for the weary wanderer.
Team MacNN - The best Macintosh team ever.
Since July 8th, when I
)
Since July 8th, when I restarted it, I have completed 36 work units with no obvious errors. Only 9 have been granted credit, but the other 27 are pending and looks like most if not all will eventually be granted credit. Average time per work unit is about 5.5 to 5.7 hours. 4 .5 units per day. I am running Einstein exclusively on the iMac G5 until I am sure that I am not going to have to travel any time soon again, then I may try to mix it up again with some other projects.
Team MacNN - The best Macintosh team ever.
The current beta App
)
The current beta App definitely has a problem with proper suspending. If you want to mix E@H with other projects, run the official App or wait for the next Beta version. Should be up soon.
BM
BM
RE: The current beta App
)
I'll keep an eye out for it.
Team MacNN - The best Macintosh team ever.