> >I apologize, but I'm just one person, and this seems to be a BOINC issue
> rather >than an Einstein@home problem.
>
> A problem that appears when the Einstein@Home app is loaded, that was absent
> before is hardly likely to be a BOINC problem. (Possible, but unlikely.)
>
> That being said, I've continued to have problems with lockups and crashes
> related to BOINC with the E@H app loaded. I've uninstalled E@H for the moment
> to see if the problems recur, or if they cease.
>
There are a hugs amount of interdependicies between the boinc client and the running science units. As bruce says the boinc client still in need of work. It is a excellent start and a good base but the quickly chaning code base leads to small issues comming up in the code, that can effect the code stability from little to large amounts.
Bruce and his team have a stable project and are working on issues with their science unit against the rapidly changing boinc platform.
Complications to the project are that the range of windows/linux/mac make the issues even more complciated from a test point of view.
As usual resources are limited and the job of keeping things on the rails in a project like this are always stressors.
BTW: This might have been noticed more quickly as a problem by the admins, if posted in the Questions & Problems section, instead of the message board section.
That's nonsense Peter. I took the devs to task for ignoring problem reports. (They have time to post on credit issues... And not problem reports?) And to task for blaiming BOINC and accepting no fault of their own. (BOINC stable before installing E@H, unstable while it's installed, stable after removing it? That tells me that E@H has problems.)
4.13 has been a stable branch for over a month. Coding for stability with a rapidly changing alpa/beta branch is nothing but a waste of time, as hours/days of work can be invalidated at a stroke. It's a better use of time to be stable against a stable branch, and work on the next step once that branch becomes stable.
@Shaktai
>BTW: This might have been noticed more quickly as a problem by the admins, if >posted in the Questions & Problems section, instead of the message board section.
On all other BOINC projects, the Q@P section has become a user-to-user section for problem solving, and the message boards are used for bug reports. (Which makes sense, as that relieves the devs of some of the 'support' aspects.)
It's worth pointing out that the Devs *ignored* a posting of a Win 98 problem over in the Q&P section, yet answered a question on credit.
Like Peter's theory, yours founders on the rocks of facts.
@Basti
>Maybe somebody would be happy, if I tell you that I have no problem on my AMD >2800 under Windows 2000 SP4
Why would we be happy you spammed a topic about W98 problems with an off-thread-topic post?
@Chris Sutton
> I believe that I found your problem.
> As it turns out, it is not an E@H problem, but a bug in BOINC.
You are confusing what appears to be two different bugs -
Bug 1 - a BOINC bug related to being unable to run the GUI.
> I have managed to repeat it, and posted a solution on the SAH boards href="https://einsteinathome.org/%3Ca%20href%3D"http://setiweb.ssl.berkeley.edu/forum_thread.php?id=6936#49957">http://setiweb.ssl.berkeley.edu/forum_thread.php?id=6936#49957">here[/url]
> in case anyone else has this problem in future.
Which would not have worked for me, as I could not run the CLI either.
(That's not to say your work is not appreciated!)
Bug 2 - a E@H bug (or bugs) leading to instability of BOINC.
Which appears to have been resolved, as the current E@H app version (4.46) is running just fine (crosses fingers) without the malbehavior that characterized earlier versions.
> You are confusing what appears to be two different bugs -
> Bug 1 - a BOINC bug related to being unable to run the GUI.
Point taken, however I feel my confusion is warranted since my post was in relation to the problem described in your initial post and represented by the thread subject "Bug: No restart on Reboot" ;-)
> Which would not have worked for me, as I could not run the CLI either.
> (That's not to say your work is not appreciated!)
Now I'm curious as to why you could not run the cli....
Granted, in the broken state and without any options "boinc_cli.exe" will produce much the same output as in your original message, but exit with output "gstate.init() failed: 1". Hence, it may appear not to run. However, if executed with the "-detach_project http:///" option, it does exactly as requested, namely detach the faulty url and exit. Execution thereafter works quite normally.
If possible, could you please explain a little more about why it didn't run. Maybe there are some other conditions that I have missed. Your explanation could help me to refine the solution to include scenarios that others may experience.
> Bug 2 - a E@H bug (or bugs) leading to instability of BOINC.
Admittedly, I only realised that you were having instability problems after this previous post and then re-read your earlier posts. My bad...
> Which appears to have been resolved, as the current E@H app version (4.46) is
> running just fine (crosses fingers) without the malbehavior that characterized
> earlier versions.
Yes, it does seem remarkably stable, doesn't it.... Calm before the storm, and all that...LOL ;-)
> I don't know why it would not run. The CLI work was done via the SETI message
> boards, see this thread;
From reviewing that detail it looks to me like the cli may have been unable to detach the good url, because it kept getting tripped up by the faulty one.
For academic purposes, I will try to emulate this, however it seems that the solution, being to detach the faulty url, would not change.
> From reviewing that detail it looks to me like the cli may have been unable to
> detach the good url, because it kept getting tripped up by the faulty one.
The faulty one was not (IIRC) present when I first tried the CLI, but showed up after my further ham-handed attempts to manually remove E@H. Compare my "13 Nov 2004 20:02:24" posting (in the S@H thread) with my "14 Nov 2004 0:21:36" posting.
> For academic purposes, I will try to emulate this, however it seems that the
> solution, being to detach the faulty url, would not change.
It's always good to try and document these things.
> >I apologize, but I'm just
)
> >I apologize, but I'm just one person, and this seems to be a BOINC issue
> rather >than an Einstein@home problem.
>
> A problem that appears when the Einstein@Home app is loaded, that was absent
> before is hardly likely to be a BOINC problem. (Possible, but unlikely.)
>
> That being said, I've continued to have problems with lockups and crashes
> related to BOINC with the E@H app loaded. I've uninstalled E@H for the moment
> to see if the problems recur, or if they cease.
>
There are a hugs amount of interdependicies between the boinc client and the running science units. As bruce says the boinc client still in need of work. It is a excellent start and a good base but the quickly chaning code base leads to small issues comming up in the code, that can effect the code stability from little to large amounts.
Bruce and his team have a stable project and are working on issues with their science unit against the rapidly changing boinc platform.
Complications to the project are that the range of windows/linux/mac make the issues even more complciated from a test point of view.
As usual resources are limited and the job of keeping things on the rails in a project like this are always stressors.
73 de Peter VK3AVE
Good points Peter. BTW:
)
Good points Peter.
BTW: This might have been noticed more quickly as a problem by the admins, if posted in the Questions & Problems section, instead of the message board section.
Team MacNN - The best Macintosh team ever.
Maybe somebody would be
)
Maybe somebody would be happy, if I tell you that I have no problem on my AMD 2800 under Windows 2000 SP4 ;-).
Greetings from Germany
Basti
Join Ad Astra
@PeterHallgarten That's
)
@PeterHallgarten
That's nonsense Peter. I took the devs to task for ignoring problem reports. (They have time to post on credit issues... And not problem reports?) And to task for blaiming BOINC and accepting no fault of their own. (BOINC stable before installing E@H, unstable while it's installed, stable after removing it? That tells me that E@H has problems.)
4.13 has been a stable branch for over a month. Coding for stability with a rapidly changing alpa/beta branch is nothing but a waste of time, as hours/days of work can be invalidated at a stroke. It's a better use of time to be stable against a stable branch, and work on the next step once that branch becomes stable.
@Shaktai
>BTW: This might have been noticed more quickly as a problem by the admins, if >posted in the Questions & Problems section, instead of the message board section.
On all other BOINC projects, the Q@P section has become a user-to-user section for problem solving, and the message boards are used for bug reports. (Which makes sense, as that relieves the devs of some of the 'support' aspects.)
It's worth pointing out that the Devs *ignored* a posting of a Win 98 problem over in the Q&P section, yet answered a question on credit.
Like Peter's theory, yours founders on the rocks of facts.
@Basti
>Maybe somebody would be happy, if I tell you that I have no problem on my AMD >2800 under Windows 2000 SP4
Why would we be happy you spammed a topic about W98 problems with an off-thread-topic post?
@DerekL I believe that I
)
@DerekL
I believe that I found your problem.
As it turns out, it is not an E@H problem, but a bug in BOINC.
I have managed to repeat it, and posted a solution on the SAH boards here in case anyone else has this problem in future.
Kind Regards
@Chris Sutton > I believe
)
@Chris Sutton
> I believe that I found your problem.
> As it turns out, it is not an E@H problem, but a bug in BOINC.
You are confusing what appears to be two different bugs -
Bug 1 - a BOINC bug related to being unable to run the GUI.
> I have managed to repeat it, and posted a solution on the SAH boards href="https://einsteinathome.org/%3Ca%20href%3D"http://setiweb.ssl.berkeley.edu/forum_thread.php?id=6936#49957">http://setiweb.ssl.berkeley.edu/forum_thread.php?id=6936#49957">here[/url]
> in case anyone else has this problem in future.
Which would not have worked for me, as I could not run the CLI either.
(That's not to say your work is not appreciated!)
Bug 2 - a E@H bug (or bugs) leading to instability of BOINC.
Which appears to have been resolved, as the current E@H app version (4.46) is running just fine (crosses fingers) without the malbehavior that characterized earlier versions.
> You are confusing what
)
> You are confusing what appears to be two different bugs -
> Bug 1 - a BOINC bug related to being unable to run the GUI.
Point taken, however I feel my confusion is warranted since my post was in relation to the problem described in your initial post and represented by the thread subject "Bug: No restart on Reboot" ;-)
> Which would not have worked for me, as I could not run the CLI either.
> (That's not to say your work is not appreciated!)
Now I'm curious as to why you could not run the cli....
Granted, in the broken state and without any options "boinc_cli.exe" will produce much the same output as in your original message, but exit with output "gstate.init() failed: 1". Hence, it may appear not to run. However, if executed with the "-detach_project http:///" option, it does exactly as requested, namely detach the faulty url and exit. Execution thereafter works quite normally.
If possible, could you please explain a little more about why it didn't run. Maybe there are some other conditions that I have missed. Your explanation could help me to refine the solution to include scenarios that others may experience.
> Bug 2 - a E@H bug (or bugs) leading to instability of BOINC.
Admittedly, I only realised that you were having instability problems after this previous post and then re-read your earlier posts. My bad...
> Which appears to have been resolved, as the current E@H app version (4.46) is
> running just fine (crosses fingers) without the malbehavior that characterized
> earlier versions.
Yes, it does seem remarkably stable, doesn't it.... Calm before the storm, and all that...LOL ;-)
@Chris I don't know why it
)
@Chris
I don't know why it would not run. The CLI work was done via the SETI message boards, see this thread; http://setiweb.ssl.berkeley.edu/forum_thread.php?id=6568
> I don't know why it would
)
> I don't know why it would not run. The CLI work was done via the SETI message
> boards, see this thread;
From reviewing that detail it looks to me like the cli may have been unable to detach the good url, because it kept getting tripped up by the faulty one.
For academic purposes, I will try to emulate this, however it seems that the solution, being to detach the faulty url, would not change.
> From reviewing that detail
)
> From reviewing that detail it looks to me like the cli may have been unable to
> detach the good url, because it kept getting tripped up by the faulty one.
The faulty one was not (IIRC) present when I first tried the CLI, but showed up after my further ham-handed attempts to manually remove E@H. Compare my "13 Nov 2004 20:02:24" posting (in the S@H thread) with my "14 Nov 2004 0:21:36" posting.
> For academic purposes, I will try to emulate this, however it seems that the
> solution, being to detach the faulty url, would not change.
It's always good to try and document these things.